Jan Kiszka wrote: > Philippe Gerum wrote: >> On Wed, 2007-04-18 at 20:13 +0200, Jan Kiszka wrote: >>> Hi Philippe, >>> >>> here is an explanation of the scalable scheduler issue I face on x86_64 >>> under different gcc compilers: >>> >>> unsigned long x = 0; >>> int n = 32; >>> >>> x |= 1 << n; >>> >>> The last instruction translates to: >>> >>> mov 0xfffffffffffffffc(%rbp),%ecx >>> mov $0x1,%eax >>> shl %cl,%eax >>> cltq >>> or %rax,0xfffffffffffffff0(%rbp) >>> >> Blast. Good spot. >> >>> That means we only shift with 32-bit precision although the target type >>> is 64 bit. We find such code for setting the queue usage bits in >>> addmlq(), but probably elsewhere too. This variant lets gcc generate the >>> desired code: >>> >>> x |= (unsigned long)1 << n; >>> >>> Compiler issue, x86_64-specific oddity, or generic 64-bit problem we may >>> have across the ipipe and Xenomai code (ppc64, ia64?)? >>> >> A brief look at the I-pipe code base shows that most shift expressions >> have righthand sides limited to small values (at least always < 32), and >> when they don't, the lefthand side is properly cast to long long values, >> so this should be ok. >> >> BUT, it's a general 64bit port issue for Xenomai, which is not specific >> to the multi-level queue implementation. We have the same issue going on >> with at least: >> >> - the posix registry >> - the message pipe support from the nucleus >> - the vrtx id generator >> >> Gentlemen, it's time for bug hunting. >> >>> After patching nucleus/queue.h appropriately, my oopses disappear, but >>> RT threads still do not run (no CSW to the threads latency creates). >>> Jan >>> >>> >>> PS: If you are interested, I could post a modified qemu patch that >>> enables gdb kernel debugging under x86_64. >>> >> Yes please. I would have a look to the remaining issue I have here >> exclusively over qemu, which seems unrelated to the multi-level queue >> issue though. >> > > Attached. A post to qemu-devel is also on the way. I wonder way the > original patch by Jason Wessel, posted last September, or a variant of > it still didn't make it into a qemu release or at least its CVS. Anyway. >
A few iteration later, a new version of my qemu patch (now with more registers...): http://article.gmane.org/gmane.comp.emulators.qemu/17315 BTW, with latest SVN trunk and scalable sched, the oopses are gone but latency still doesn't start up: [EMAIL PROTECTED] :/root# cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME 0 0 -1 0 0 master R ROOT 0 930 0 0 0 master R display-928 0 931 99 0 0 master R sampling-928 [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 0 0 00500080 100.0 ROOT 0 930 0 0 0 00300188 0.0 display-928 0 931 0 0 0 00300188 0.0 sampling-928 0 0 0 207 0 00000000 0.0 IRQ296: [timer] This doesn't happen with !CONFIG_XENO_OPT_SCALABLE_SCHED. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
