On Fri, 2010-09-03 at 17:30 +0100, edward.robb...@oxfordtechnologies.co.uk wrote: > I have now installed the i-pipe tracer and run some tests. Yesterday I > thought I had gotten a high latency without X running, while compiling the > kernel to stress the system, but now I think I might have been mistaken. > Either way I was using a kernel whose configuration I couldn't remember, and > didn't have the I-Pipe tracer installed at that time, so the observation > wasn't particularly useful. > > Today I have tried using the intel video driver with the option "NoAccel", > and that seems to stop the high latencies; with this option I can kill X, > restart it, and run glxgears without issues, all while compiling the linux > kernel and having xeno-test or latency running. The highest latency I have > gotten so far is 18uS. > > However, if anyone is interested I have made a trace without the NoAccel > option, when the latency jumped to 1113uS upon starting X, attached. > > A couple of other things: > > Yesterday when running xeno-test, I got a few of these messages: > "INFO: task sync:20539 blocked for more than 120 seconds...." > I have not seen this again today, and I don't know if it could be related, > but I was also getting lots of strange USB disconnect sort of messages > yesterday... I haven't seen any more today, and as I said before that kernel > may have been useless anyway. > > I am also getting this message from xeno-test: > "FATAL: module xeno-nucleus not found" > > And: > "Warning Linux is compiled to use FPU in kernel space > For this reason, switch test can not test using FPU in Linux Kernel-space" > > I presume these last two are because I did something wrong at kernel compile > time? > > Also, I tried to compile Xenomai 2.5.4 with a 2.6.34 kernel because it has a > network driver that I really need, but the build failed. I think this has > been resolved previously (as I have seen some information in the mailing list > about a problem in the debian kernel patch script), but am not sure how to > use the corrected script with my system. Can anyone help? > > I will keep testing.
Please try this patch. Your trace log reveals that we are only virtually masking interrupts while flushing the TLB, which is quite wrong. diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index 7f3eba0..b0a4112 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -30,7 +30,7 @@ static inline void __native_flush_tlb_global(void) * from interrupts. (Use the raw variant because this code can * be called from deep inside debugging code.) */ - raw_local_irq_save(flags); + local_irq_save_hw(flags); cr4 = native_read_cr4(); /* clear PGE */ @@ -38,7 +38,7 @@ static inline void __native_flush_tlb_global(void) /* write old PGE again and flush TLBs */ native_write_cr4(cr4); - raw_local_irq_restore(flags); + local_irq_restore_hw(flags); } static inline void __native_flush_tlb_single(unsigned long addr) -- Philippe. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help