I use syscall SYS_time, but its resolution is 1 second.
Is there any other solution?
Try clock_gettime(3R) (same for Linux). I have to dig up the assembly version for the calls.
Related
I recently tried to start the yocto build task with leaving PARALLEL_MAKE and BB_NUMBER_THREADS blank, e.g. commented out and starting the Build on a Host with 48 or 64 vCPU's. The build was failing. With 32 vCPU's it still works. Yocto is still old Krogoth and cannot be updated currently. Does anybody knows if there is a limitation going further than 32 vCPU's? Is this just for older Yocto versions or generally an Issue?
Update: The error is related to a custom recipe for compiling a rnnoise-plugin:
../rnnoise-plugin/1.0-r0/temp/log.do_compile.1449627
rnnoise-plugin/1.0-r0/asound-pcm-plugin-rnnoise.c:16:28: fatal error: alsa/asoundlib.h: No such file or directory
#include <alsa/asoundlib.h>
^
As mentioned above, i only get this error when compiling on a 48 or 64 vCPU Host with PARALLEL_MAKE and BB_NUMBER_THREADS left blank. If i set PARALLEL_MAKE="-j 32" and BB_NUMBER_THREADS="32" it compiles without any error.
It seems you run into race conditions when compiling with that many threads.
The yocto reference recommends setting PARELLEL_MAKE so make uses a maximum of 20 threads when using more than one physical CPU. If your system only has a single CPU this might be a virtualization problem.
For single socket systems (i.e. one CPU), you should not have to override this variable to gain optimal parallelism during builds. However, if you have very large systems that employ multiple physical CPUs, you might want to make sure the PARALLEL_MAKE variable is not set higher than "-j 20".
Yocto Project - PARALLEL_MAKE
For increased building speed you can try to fix this dependency issue by patching the appropriate Makefile (Debugging Parallel Make Races)
Edit:
It is possible to set PARALLEL_MAKE for a particular package when overwriting in its recipe which allows to compile one particular package with make -j 2 e.g. while other packages use maximum parallelism.
So it might be a suitable workaround to set PARALLEL_MAKE to a lower value in the recipe of the package where the dependency issue occurs.
But keep in mind that the yocto reference also recommends to limit BB_NUMBER_THREADS (no package-specific parameter) to 20 on large systems with multiple CPU's which might be the case when using hardware virtualization.
After unpacking the 6.3 jar. I can find below commands takes too much time to execute.
java -Xmx4096m -jar AEM_6.3-author-p4502.jar -v -x crx2oak -xargs -- --load-profile segment-no-ds --disable-mmap --exclude-paths /content/dam
Any Idea where I am failing. Moreover, there will be need to remove /content/dam to include assets as well. Its upgrade from 6.0 to 6.3
Thanks
You could try increasing the maximum memory in the xmx parameter, if there is more available.
Maybe opt for an offline compaction before the promote (which might take even more time though)?
I would really look at the error.log and upgrade.log because if I'm not mistaken this should take about 20 minutes according to Adobe Engineering. Maybe change the logging level of crx2oak.
Other than that, I'm guessing you're on windows (because of the --disable-mmap) so it's going to be slow.
I am facing problem for accessing my serial port device from Control::CLI( ver 2.03) on Perl 5.22. Issue is connection gets established but I can't write on the port.
The same code was working well with Control::CLI( ver 1.03) on Perl 5.14
Please help.
Thanks.
Unfortunately there isn't more of information to go on but the problem sounds like it might be one of two areas:
1) there might be issues with the newer version of Control::CLI that you are using. This would be something to ask the maintainer of Control::CLI about.
Chances are you might need to modify your existing code.
2) the OS that you are running 5.22 on. What's not clear is if you ran 5.14 on an older version of Windows (ie, Win 7, Win XP) and are trying to run your script with 5.22 on a newer version (ie, Win 10).
Sorry that I can't give an exact answer but these would be areas I would advise looking into to begin troubleshooting.
I am getting a core dump when I use the Cmenu module on Solaris 8. The script works fine on Solaris 10. Could somebody please suggest a possible workaround for this? Using dbx shows the following:
terminated by signal SEGV (no mapping at the fault address)
Current function is Perl_safesysmalloc
92 Ptr = (Malloc_t)PerlMem_malloc(size?size:1)
Perl_safesysmalloc(size = 4U), line 92 in "util.c"
I built version 5.10 of Perl using gcc on this machine. Please let me know if you have need any other information.
That's probably a bug on the module. Send a bug report to the author!
... though, the last release is from 2001, probably not being maintained anymore :-(
Cmenu is a pure perl module that uses Curses.pm which is based on a C library. So mosts probable place for core dump is Curses.pm. Try upgrading it to latest version. Also try upgrading curses library.
If this does not help, try minimizing your program to get a minimal program that would still result a core dump. Report it to Cmenu bug tracker.
I’m using the gcc in MinGW that comes with Strawberry Perl, on Windows XP. I’d like to have ddd (the Data Display Debugger) as well but apparently on Windows the simplest way to get ddd is by running Cygwin. So what's the bare minimum of Cygwin I can install to get ddd up and running? I'd prefer if I could run ddd natively on Win32 but that doesn't seem to be an option.
As far as I can tell so far, only the following (with Cygwin DLL release version 1.5.25-15), and allowing setup to install any other packages to meet dependencies.
Base: base-files, grep
Develop: ddd, gdb
Math: gnuplot
Example to get grep working: Just drop the following files from a cygwin bin directory into an appropriate directory...
cyggcc_s-1.dll
cygiconv-2.dll
cygintl-8.dll
cygpcre-0.dll
cygwin1.dll
grep.exe
The Cygwin setup.exe installer resolves dependencies for you. Just run the installer, find and enable ddd, and click Next. It might install some packages you doun't strictly need, but figuring out which ones you can safely omit is probably a waste of time.
Disclaimer: I haven't tried this; I just install eveything.
If you're going for minimalism, you might want a smaller X server than cygwin-x11 (though it's what I use, and I'm quite fond of it). Starwin X-Win32 is actively maintained (though it costs $$ beyond the trial period), and avoids the overhead of installing Cygwin proper; there are other, zero-cost minimal X servers for win32 available, but I don't have linkage immediately available.
As the documentation at x.cygwin.com indicates, the xorg-x11-base package is the bare minimum needed.