Looking at the em_watchdog, there is a test that could cause the watchdog to do nothing. Comparing to the similar fxp driver, fxp watchdog just go ahead to restart the driver.
Ming
Pierre Beyssac wrote:
Hello,
I'm having a problem (under 5.3-BETA, but I don't think it matters much) with the if_em driver on bursty outbound traffic: the card is stuck in a state where it only returns ENOBUFS. No buffers ever become available again, but ifconfig down+up fixes the problem.
From a quick analysis it looks like the TX descriptor cleanup routineem_clean_transmit_interrupts() as called by em_encap() in such cases doesn't manage to find anything free with E1000_TXD_STAT_DD set. The card seems stuck in this state. A simple albeit dirty fix would be to cancel some or all untransmitted packets in such cases.
Perhaps this is related to my using the card on a 100Mbps switch. I have a small program to exercise the hang in case someone would like to have a look at it.
See below for the result of "sysctl hw.em0.debug_info=1" (notice the not avail1 = 12 and not avail2 = 0 hinting at em_clean_transmit_interrupts).
em0: [MPSAFE]
em0: bpf attached
em0: Ethernet address: 00:0d:56:d0:5c:15
em0: Speed:N/A Duplex:N/A
em0: Link is up 100 Mbps Full Duplex
em0: Adapter hardware address = 0xc3570b34 em0:tx_int_delay = 66, tx_abs_int_delay = 66
em0:rx_int_delay = 0, rx_abs_int_delay = 66
em0: fifo workaround = 0, fifo_reset = 0
em0: hw tdh = 238, hw tdt = 238
em0: Num Tx descriptors avail = 256
em0: Tx Descriptors not avail1 = 12
em0: Tx Descriptors not avail2 = 0
em0: Std mbuf failed = 0
em0: Std mbuf cluster failed = 0
em0: Driver dropped packets = 0
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
