Anders Blomdell wrote:
> 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:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to use rt_eepro100, for sending raw ethernet packets,
>>>>>>> but I'm
>>>>>>> experincing occasionally weird behaviour.
>>>>>>>
>>>>>>> Versions of things:
>>>>>>>
>>>>>>>   linux-2.6.34.5
>>>>>>>   xenomai-2.5.5.2
>>>>>>>   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
>>>>> http://sourceforge.net/mailarchive/message.php?msg_name=4CC82C8D.3080808%40control.lth.se
>>>>> )
>>>>>
>>>>> 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.
>>> 2.6.35.7 ?
> Well, 2.6.35.7/xenomai/rtnet without ftrace patch freezes after approx 
> 8000 rounds (16000 packets). Time freshen up find serial port console 
> debugging I guess (under the assumption that this is the same bug, but 
> easier to reproduce).
Dropping rtnet-developer.

Current results:

1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after 
some time:

BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
Process raw_test (pid: 2924, ti=f18bc000 task=f1bdab00 task.ti=f18bc000)
I-pipe domain Xenomai
Stack:
Call Trace:
Code: d0 85 d8 74 0f ba 71 00 00 00 b8 78 a7 8f c0 e8 3b 03 02 00 a1 28 
f6 9f c0 89 f2 8b 48 20 89 d8 e8 ad fd ff ff 57 9d 8d 65 f4 5b <5e> 5f 
5d c3 90 55 89 e5 0f 1f 44 00 00 8b 0d 28 f6 9f c0 ba 00

2. 2.6.35.7, maxcpus=4; no packets sent, this on console:

e1000: rteth0: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <0>
  TDT                  <10>
  next_to_use          <10>
  next_to_clean        <0>
buffer_info[next_to_clean]
  time_stamp           <362d2>
  next_to_watch        <0>
  jiffies              <368f8>
  next_to_watch.status <0>

Anders