need contact of via-rhine developers
A message that is not in the archive (sent off-list or not yet received): 1029854455.10084.136.camel@ransom
Quoted 6 lines
here is the driver i'm using that works on my vt6103 (from 2.4.20-pre2-ac3). i have not done throughput benchmarks, but i have put many gb's through them with no ill effects so far.
it looks like the patch adds the ability for the driver to restart the confused chip...
thanks! that fixed the transmit-timeouts! they happened quite frequently. the more traffic you'd submit, the more timeouts. e.g. , when viewing icture over the net (e.g. xv running on a different host), I'd see about 12 timeouts per minute(raw estimation).
any idea what's confusing the chip in the first place?
regards,
h.rosmanith
Quoted 6 lines · H.Rosmanith (Kernel Mailing List)
thanks! that fixed the transmit-timeouts! they happened quite frequently. the more traffic you'd submit, the more timeouts. e.g. , when viewing icture over the net (e.g. xv running on a different host), I'd see about 12 timeouts per minute(raw estimation).
any idea what's confusing the chip in the first place?
After a transmission error (e.g. excessive collisions) the chip stops to let the driver handle it. The driver does its thing and restarts the transmission engine. Problem is, the ring buffer pointer on the chip skidded too far and hence takes up work from the wrong entry.
If an error occured on entry n, the chip continues on n+2. The driver stops harvesting transmitted buffers because the next entry in the ring (n+1) remains marked as owned by the driver. A few more packets may be sent after the restart, then the card stalls. After a while the watchdog kicks in to resets chip and buffers. Transmission continues.
You can verify this easily by dumping ring pointer information and the status bits associated with the ring buffer.
The fix is to have the interrupt handler set the ring buffer pointer to what the driver knows to be the current entry.
Btw: The stalling you've seen, was that at 10 or 100 Mbps? Hub or Switch? With debug level 2 (and fixed driver), do you find Abort or Underrun errors in your log in situations where stalling occured with the old driver?
Roger
Quoted 2 lines
Quoted 2 lines
thanks! that fixed the transmit-timeouts!
ouch, that was too soon. the new driver performs better, but not 100% without timeouts.
Quoted 2 lines
Btw: The stalling you've seen, was that at 10 or 100 Mbps? Hub or Switch?
a 10 Mbps hub, half duplex connection. I tried with a Surecom and an Asante hub. I also tried connection the two machines I've been testing with with a crossover-cable, but things went worse then.
Quoted 2 lines
With debug level 2 (and fixed driver), do you find Abort or Underrun errors in your log in situations where stalling occured with the old driver?
old driver, kernel 2.4.19, debug level 2:
: via-rhine.c:v1.10-LK1.1.13 Nov-17-2001 Written by Donald Becker
: http://www.scyld.com/network/via-rhine.html
: via-rhine: reset finished after 5 microseconds.
: eth0: VIA VT6102 Rhine-II at 0xe800, 00:40:63:c0:b4:8c, IRQ 11. : eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 0021. : eth0: via_rhine_open() irq 11.
: eth0: reset finished after 5 microseconds.
: eth0: Transmit error, Tx status 00008100.
: NETDEV WATCHDOG: eth0: transmit timed out
: eth0: Transmit timed out, status 0000, PHY status 786d, resetting... : eth0: reset finished after 5 microseconds.
new driver with 2.4.19, debug level 2:
: via-rhine.c:v1.10-LK1.1.14 May-3-2002 Written by Donald Becker
: http://www.scyld.com/network/via-rhine.html
: via-rhine: reset finished after 5 microseconds.
: eth0: VIA VT6102 Rhine-II at 0xe800, 00:40:63:c0:b4:8c, IRQ 11. : eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 0021. : eth0: via_rhine_open() irq 11.
: eth0: reset finished after 5 microseconds.
: eth0: no IPv6 routers present
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: NETDEV WATCHDOG: eth0: transmit timed out
: eth0: Transmit timed out, status 0000, PHY status 786d, resetting... : eth0: reset finished after 5 microseconds.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: NETDEV WATCHDOG: eth0: transmit timed out
: eth0: Transmit timed out, status 0000, PHY status 786d, resetting... : eth0: reset finished after 5 microseconds.
: eth0: Transmit error, Tx status 00008100.
: eth0: Abort 2008, frame dropped.
: NETDEV WATCHDOG: eth0: transmit timed out
: eth0: Transmit timed out, status 0000, PHY status 786d, resetting... : eth0: reset finished after 5 microseconds.
: NETDEV WATCHDOG: eth0: transmit timed out
: eth0: Transmit timed out, status 0000, PHY status 786d, resetting... : eth0: reset finished after 5 microseconds.
shall we continue this via private email?
regards,
h.rosmanith
hi,
the following comment in the header of via-rhine.c made me suspicious:
: The send packet thread has partial control over the Tx ring. It locks : the dev->priv->lock whenever it's queuing a Tx packet. If the next slot : in the ring is not available it stops the transmit queue by calling : netif_stop_queue.
okay so far. reading through net/sched/sched_generic.c shows that "NETDEV WATCHDOG" will bark when (among other conditions) the netif queue is stoppped and the timer expires. so, what if the queue is stopped, but never started again by the driver? the only call to netif_start_queue is in via_rhine_open. shouldn't there be another netif_start_queue if netif_queue_stopped(dev) && a packet has left the queue? where's the proper place to insert that?
regards,
h.rosmanith