Beyer Philipp wrote: > > >> You could try rtroute solict as well, first from master to slave, then >> the other way around. This also indicates if there is any communication >> at all (one direction should work as we saw). Check /proc/xenomai/irq if >> something happens, and on which side. >> >> >> > If I have understand you right, I shall look whether an interrupt was > triggert at the other target after a arp request with rtroute solicit? > > > This is Target #2 > > > BusyBox v1.01 (Slind 1:1.01-2.slind1) Built-in shell (ash) > Enter 'help' for a list of built-in commands. > > kontron_xenomai:~# start_rtnet.sh > Using /usr/local/rtnet/modules/rtnet.ko > Using /usr/local/rtnet/modules/rtipv4.ko > Using /usr/local/rtnet/modules/rtpacket.ko > Using /usr/local/rtnet/modules/rt_loopback.ko > Using /usr/local/rtnet/modules/rt_tulip.ko > rtlo Medium: Local Loopback > IP address: 127.0.0.1 > UP LOOPBACK RUNNING MTU: 1500 > > rteth1 Medium: Ethernet Hardware address: 00:E0:4B:0E:3D:2B > IP address: 10.0.0.1 Broadcast address: 10.255.255.255 > UP BROADCAST RUNNING MTU: 1500 > > kontron_xenomai:~# cat /proc/xenomai/irq > IRQ CPU0 > 0: 9515 > 11: 1 > 34: 2 > kontron_xenomai:~# > ----------------------------------------------------------------------------------- > This is Target #1 > > > > BusyBox v1.01 (Slind 1:1.01-2.slind1) Built-in shell (ash) > Enter 'help' for a list of built-in commands. > > kontron_xenomai:~# start_rtnet.sh > Using /usr/local/rtnet/modules/rtnet.ko > Using /usr/local/rtnet/modules/rtipv4.ko > Using /usr/local/rtnet/modules/rtpacket.ko > Using /usr/local/rtnet/modules/rt_loopback.ko > Using /usr/local/rtnet/modules/rt_tulip.ko > rtlo Medium: Local Loopback > IP address: 127.0.0.1 > UP LOOPBACK RUNNING MTU: 1500 > > rteth1 Medium: Ethernet Hardware address: 00:E0:4B:0E:3D:29 > IP address: 10.0.0.2 Broadcast address: 10.255.255.255 > UP BROADCAST RUNNING MTU: 1500 > > kontron_xenomai:~# cat /proc/xenomai/irq > IRQ CPU0 > 0: 22195 > 11: 1 > 34: 2 > kontron_xenomai:~# rtroute solicit 10.0.0.1 dev rteth1 > kontron_xenomai:~# cat /proc/xenomai/irq > IRQ CPU0 > 0: 30061 > 11: 2 > 34: 3 > kontron_xenomai:~# > > ------------------------------------------------------------------------------- > > This is Target #2 > > > kontron_xenomai:~# cat /proc/xenomai/irq > IRQ CPU0 > 0: 33878 > 11: 1 > 34: 2 > > > > -> No interrupt was triggert at the other target. The other way around > the same. > > But local there is one on rx and tx after rtroute - see above. Did I > understand something wrong?
Nope, that's exactly what I meant. I'm currently paving my way through the tulip jungle. It's now clear to me why that driver never worked reliably on all setups. Its media negotiation is a fairly complex, non-RT-safe process. Parts of it like the link change detection were simple disabled for that reason (they run in RT context, containing udelay(100) and stuff like this...). Even moving such stuff to non-RT (some Linux bottom-half handler e.g.) would not solve this as some potential long critical regions remain that cannot run while the RT part is active. I'm going to commit some cleanup patch that also adds a mdelay to the init code that the original driver contains. There is the slight hope that this improves something. If not, we need to dig deeper. Jan PS: If you could subscribe to this list, you would save me some moderation work... :)
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
