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 -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
