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 126.96.36.199, 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. -- Gilles Chanteperdrix. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core