On Fri, 2010-09-03 at 17:30 +0100,
[email protected] 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
[email protected]
https://mail.gna.org/listinfo/xenomai-help
