On Sun, 2006-10-22 at 15:39 +0200, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Hi, > > > > while actually cross-checking some user's problem with RTnet (not on > > Xenomai), I happen to stumble over another weirdness. Scenario: > > > > RTnet under high load (>5 KHz network IRQ rate, large packets), "latency > > -p1000" as additional load, Pentium 266 MHz (tried boards from different > > vendors), kernel 2.6.17.13, Xenomai trunk, ipipe-1.5-00, CONFIG_M586TSC, > > !CONFIG_X86_UP_APIC > > > > Main protagonists: > > - "display-" (user, PID 909, prio 0/-1) > > - "samplin" (user, PID 910, prio 99) > > - stack manager (kernel, PID -1, prio 98) > > - "client", the RTnet test (user, PID 903, prio 10) > > > > So the sampling task is definitely the chief and should only be delayed > > by IRQ handlers. Generally it is (~120 us with i-pipe tracer enabled), > > but there happen to be delays of more than 500 us. Attached is such a > trace. > > > > Specifically suspicious is the fact that the timer IRQ, which should > > have popped up around -500, is not blocked by some hard IRQ lock. Rather > > it takes someone else (the RTnet test) to start another timer, and then > > the delayed event gets raised immediately. Hardware issue? Bug in > > Xenomai? With the same boot image on a P-III, this does not happen. > > > > Any ideas what to check first are welcome. > > I got similar behaviour on hardware where programming the timer for a > too short delay did not work. The way to check this was to add : > if (delay < 100) > printk("\n!!!! Short delay !!!!\n"); > > on the timer programming path.
Actually, there was a bug in the pipeline log syncer which has been fixed in the latest patches for ppc and x86. This is a multi-arch issue (__ipipe_sync_stage). > -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core