> Please let me know if you experience any problems, so I can
> update the driver...
Ok, thank you. I *do* experience problems, hence here is a report
as complete as possible.
I have tried to use one of my 8169 interfaces as a capture
interface on a 100Mbps network, for testing, with rtnet capture.
Only one of my 8169 interfaces is activated in rtnet.conf
(RT_DRIVER_OPTIONS="cards=1,0,0,0").
After starting rtnet capture, the console periodically outputs a
lot of times (15 to 30 times) the following line:
r8169: rtl8169_rx_interrupt: Allocate n_skb failed!
(priv->rx_buf_size = 1536)
...
followed by:
r8169: Leaving Interrupt Unhandled
When capturing packets (e.g. starting tethereal -i rteth0), it
captures a few packets, then nothing for 30 seconds, then
capture a few packets again, then nothing for 30 seconds, etc.
(although there are constantly many broadcast packets sent on
this network)
I also see sometimes the line:
rteth0: Too much work at interrupt!
In addition, the RT driver seems to block the interrupts of
another ethernet interface, that is non-realtime and that is
managed by the standard Linux 3Com 3c905 driver. I get
periodically messages on the console from that driver, such as:
NETDEV WATCHDOG: eth2: transmit timed out
eth2: transmit timed out, tx_status 00 status e681.
diagnostics: net 0ccc media 8880 dma 0000003a fifo 8000
eth2: Interrupt posted but not delivered -- IRQ blocked by
another device?
flags: bus-master 1, dirty 5419(11) current 5419(11)
Transmit list 00000000 vs. f719f8e0
0: @f719f200 length 8000002a status 0001002a
1: @f719f2a0 length 8000002a status 0001002a
(etc. 16 lines like those)
(in fact, I have 3 interfaces on that PC: eth2 is a 3Com 3C905,
and rteth0 and rteth1 are 8169-based interfaces)
And effectively, the traffic on the non-RT interface is stopped:
if I had opened a ssh connection, it becomes no more responsive
once I have started rtnet and rtcap.
If I stop rtnet, i.e. if I put the RT interface down (no need to
unload the RT driver module), it depends on the state of RTAI:
- if RTAI becomes completely broken (i.e. /proc/rtai/sched says:
"Cannot allocate memory"), then unloading rtnet is not
sufficient: the non-RT network card interrupts are still
blocked, and I need to rmmod and insmod the rt_rtdm module again
to unblock the non-RT interface, and recover a
normal /proc/rtai/sched output.
- if RTAI is still not completely broken, it is sufficient to
stop rtnet.
Just after starting rtnet capture, here is the content of
my /proc/rtai/sched:
CPU PID PRI TIMEOUT STAT NAME
0 0 0 0 R ROOT
0 0 98 0 W f8b5b9c0
0 0 1 0 W f8b5c120
But after a while, the content of /proc/rtai/sched becomes:
/proc/rtai/sched: Cannot allocate memory
(the only way to solve this is to rmmod rtai_rtdm module, and
insmod again)
My RT interface and my non-RT interface share the same IRQ 16.
Cf the content of /proc/rtai/irq:
IRQ CPU0
16: 56
216: 1
and the content of /proc/interrupts:
CPU0
0: 2751710 IO-APIC-edge timer, rthal_broadcast_timer
1: 3784 IO-APIC-edge i8042
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 1 IO-APIC-level acpi
14: 6025 IO-APIC-edge ide0
15: 26 IO-APIC-edge ide1
16: 18795 IO-APIC-level eth2
17: 0 IO-APIC-level uhci_hcd:usb1
18: 0 IO-APIC-level Intel ICH2
19: 0 IO-APIC-level uhci_hcd:usb2
NMI: 0
LOC: 2751621
ERR: 0
MIS: 0
So, as a conclusion: the good news is that the driver is somewhat
working (I can capture some packets with it...), but 1)
interrupt handling seems to be broken, and 2) there seems to be
a memory leak in RTAI/RTDM or in RTnet.
Probably those two bugs are related.
--
Romain Lenglet
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
RTnet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-users
