Network often not responding

[Pyun YongHyeon]

On Thu, Aug 10, 2006 at 08:18:23AM +0700, Akhmad Sakirun wrote:
 > Hello,
 > 
 > right now, i'm using 3com ethernet:
 > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xa880-0xa8ff mem 0xfeafec00-0xfeafec7f irq 19 at device 7.0 on pci2
 > miibus0: <MII bus> on xl0
 > xlphy0: <3Com internal media interface> on miibus0
 > xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > xl0: Ethernet address: 00:10:5a:0d:c1:45
 > 
 > onboard ethernet which disabled via BIOS was:
 > Intel 82541E1 GbE
 > 
 > Average traffic is 10-15Mbps on bussy hours,
 > 
 > and connected client average < 1000
 > #netstat -n | grep EST | wc -l
 > #     780
 > 
 > I really confused, i don't have any other Freebsd AMD64 system installed, but other
 > with i386 system never got any problem like this.
 > 
 > Best regards,
 > 
 > Wednesday, August 9, 2006, 9:10:01 PM, Dominic wrote:
 > > Googling for the second line I found this:
 > 
 > > http://lists.freebsd.org/pipermail/freebsd-doc/2005-November/009273.html
 > 
 > > It quotes this part of the manual page for dc, another network card:
 > 
 > > "This is from the dc(4) man page:
 > 
 > >       dc%d: TX underrun -- increasing TX threshold  The device generated a
 > >       transmit underrun error while attempting to DMA and transmit a packet.
 > >       This happens if the host is not able to DMA the packet data into the
 > >       NIC's FIFO fast enough.  The driver will dynamically increase the
 > > trans-
 > >       mit start threshold so that more data must be DMAed into the FIFO
 > > before
 > >       the NIC will start transmitting it onto the wire."
 > 
 > > So it would seem like the card cannot keep pace with the system. What NICs
 > > have you tried?
 > 
 > > Dom
 > 

[CCed to wpaul, the author of xl(4)]

I'm not familiar with 3Com 90x NICs but the datasheet says the
following.
"Tx underrun halts the the transmitter and the transmit FIFO. The
TxReset and TxEnable commands must be issued before any new packets
are submitted to the NIC."
But I can't find the above programming sequence in xl_txeoc() so your
NIC may have been stuck in wedged state if it didn't work anymore
after seeing "tx underrun, increasing tx start threshold to xx bytes"
message.
Normally xl(4) should activate watchdog timeout for above case but
xl(4) has a bug which blindly clears armed watchdog in xl_txeof/
xl_txeof_90xB(). I think you can set the threshold to a higher value
so make xl(4) not see the Tx underrun issue(simple patch attached,
you may need to increase xl_tx_thread to higher value). The correct
solution should follow the procedure outlined in datasheet and
remember the threshold caused the underrun instead of resetting it
in xl_init_locked() but it's hard to reset Tx path only and need
knowledge of internals of the NIC so it's more easy to reset entire
NIC if it see Tx underruns, I guess.

-- 
Regards,
Pyun YongHyeon
-------------- next part --------------
--- if_xl.c.orig	Tue Feb 14 21:44:56 2006
+++ if_xl.c	Thu Aug 10 12:54:45 2006
@@ -2848,7 +2848,12 @@
 	CSR_WRITE_1(sc, XL_TX_FREETHRESH, XL_PACKET_SIZE >> 8);
 
 	/* Set the TX start threshold for best performance. */
+#if 0
 	sc->xl_tx_thresh = XL_MIN_FRAMELEN;
+#else
+	/* set higher Tx threshold: 120, 180, 230, 300 etc */
+	sc->xl_tx_thresh = 120;
+#endif
 	CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_SET_START|sc->xl_tx_thresh);
 
 	/*