Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:

I'm trying to use rt_eepro100, for sending raw ethernet packets,
but I'm
experincing occasionally weird behaviour.

Versions of things:


The testprogram runs on two computers with "Intel Corporation
82557/8/9/0/1 Ethernet Pro 100 (rev 08)" controller, where one
acts as a mirror sending back packets received from the ethernet (only
those two computers on the network), and the other sends packets and
measures roundtrip time. Most packets comes back in approximately 100
us, but occasionally the reception times out (once in about 100000
packets or more), but the packets gets immediately received when
reception is retried, which might indicate a race between
and interrupt, but I might miss something obvious.
Changing one of the ethernet cards to a "Intel Corporation 82541PI
Gigabit Ethernet Controller (rev 05)", while keeping everything else
constant, changes behavior somewhat; after receiving a few 100000
packets, reception stops entirely (-EAGAIN is returned), while
transmission proceeds as it should (and mirror returns packets).

Any suggestions on what to try?
Since the problem disappears with 'maxcpus=1', I suspect I have a SMP
issue (machine is a Core2 Quad), so I'll move to xenomai-core.
(original message can be found at

Xenomai-core gurus: which is the corrrect way to debug SMP issues?
Can I run I-pipe-tracer and expect to be able save at least 150 us of
traces for all cpus? Any hints/suggestions/insigths are welcome...
The i-pipe tracer unfortunately only saves traces for a the CPU that
triggered the freeze. To have a full pictures, you may want to try my
ftrace port I posted recently for 2.6.35. ?

Finally managed to get the ftrace to work
(one possible bug: had to manually copy include/xenomai/trace/xn_nucleus.h to include/xenomai/trace/events/xn_nucleus.h), and it looks like it can be very useful...

But I don't think it will give much info at the moment, since no xenomai/ipipe interrupt activity shows up, and adding that is far above my league :-(

My current theory is that the problem occurs when something like this takes place:

  CPU-i         CPU-j           CPU-k           CPU-l

rt_dev_recvmsg                  recv_irq

So now I'll try to instrument the code to see if the assumtion holds. Stay tuned...



Xenomai-core mailing list

Reply via email to