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, Xenomai trunk, ipipe-1.5-00, CONFIG_M586TSC,

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.


Attachment: dump.gz
Description: GNU Zip compressed data

Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to