Am 28.10.2010 09:34, Anders Blomdell wrote:
> Anders Blomdell wrote:
>> Anders Blomdell wrote:
>>> Hi,
>>> I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
>>> experincing occasionally weird behaviour.
>>> Versions of things:
>>>   linux-
>>>   xenomai-
>>>   rtnet-39f7fcf
>>> The testprogram runs on two computers with "Intel Corporation
>>> 82557/8/9/0/1 Ethernet Pro 100 (rev 08)" controller, where one computer
>>> 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 rt_dev_recvmsg
>>> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to