Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Anders Blomdell
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 10
 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 10 
 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...

Regards

Anders Blomdell

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
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 10
 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 10 
 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.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Anders Blomdell
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 10
 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 10 
 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 ?

/Anders

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [RTnet-users] Potential problem with rt_eepro100

2010-10-28 Thread Jan Kiszka
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 10
 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 10
 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 ?
 

Exactly.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core