Philippe Gerum a écrit : > On Thu, 2007-10-18 at 14:38 +0200, CHABAL David wrote: >> Philippe Gerum a écrit : >>> On Wed, 2007-10-17 at 17:46 +0200, CHABAL David wrote: >>>> Philippe Gerum a écrit : >>>>> On Wed, 2007-10-17 at 16:52 +0200, CHABAL David wrote: >>>>>>> Grmmff... I think the PIC on this box has some deep troubles; please try >>>>>>> this patch, in replacement of the previous ipipe_trace_special >>>>>>> instrumentation: >>>>>>> >>>>>> RTD| 8.348| 10.387| 43.647| 0| 6.098| >>>>>> 80.440 >>>>>> ---|------------|------------|------------|--------|------------------------- >>>>>> RTS| 6.098| 10.020| 80.440| 0| 00:17:20/00:17:20 >>>>>> [EMAIL PROTECTED] bin]# >>>>>> >>>>>> >>>>>> IRQ handling takes 17µs in the worst case. >>>>>> >>>>>> It takes a long time to write 3 poor bytes... >>>>>> >>>>> Indeed. Each outb to the ISA bus should be somewhere in the 1-2.5 us >>>>> range depending on the hw, maybe a bit higher in case of contention, but >>>>> not that much. >>>>> >>>>>> May be is it a SMI problem ??? (Globally disable SMI is on) >>>>>> >>>>> It's less likely with an ICH-2 chipset. >>>>> >>>>> I see that CONFIG_IDEDMA_PCI_AUTO is disabled. Any reason not to use PCI >>>>> DMA when available for IDE drives with your hw? >>>>> >>>> I read this about DMA: >>>> http://www.rtai.dk/cgi-bin/gratiswiki.pl?DMA_And_Jitter >>>> >>> As usual, usage of DMA in real-time situations is a trade-off, and >>> should be evaluated within the context of the hw at hand. DMA does bus >>> mastering, but OTOH, forcing PIO raises native Linux latencies, which >>> also has some drawbacks for real-time kernels implementing RT/non-RT >>> mode transitions for tasks like Xenomai and RTAI do. For this reason, >>> you may want to try switching PCI DMA on for your platform, until it >>> does prove bad latency-wise. >>> >> I tested it but the results are almost the same. >> > > Good, at least you get PCI DMA back. > >> I will try to upgrade my kernel to the 2.6.22 and to test again. >> > > At this point, it seems reasonable to think that your hw has some > problems. You may want to confirm this by measuring the time spent in > acknowledging interrupts on the slave i8259A in mask_and_ack_8259A(), on > an unpatched 2.6.20 kernel (e.g. using a couple of rdtscll() within a > single interrupt-free section). If you still reach peaks beyond 20us, > then the odds of having the very same issue with newer kernels are high. > >> David
Right. Adeos and Xenomai are innocents. Without then and with rdtscll, I get until 35 µs for an IRQ handling (!). So, I will change my HW. Thanks for your help. David _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
