On Thu, 14 Dec 2006 15:21:00 -0800 Alex Romosan <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> writes: > > > Another useful bit of information is the statistics (ethtool -S eth0). > > When there were flow control bugs, they would show up as count of 1. > > the driver locked up again, even with msi interrupts disabled and > idle_timeout=10. the console message was pretty much as before: > > kernel: NETDEV WATCHDOG: eth0: transmit timed out > kernel: sky2 eth0: tx timeout > kernel: sky2 eth0: transmit ring 336 .. 296 report=336 done=336 > kernel: sky2 hardware hung? flushing > kernel: NETDEV WATCHDOG: eth0: transmit timed out > kernel: sky2 eth0: tx timeout > kernel: sky2 eth0: transmit ring 296 .. 255 report=336 done=336 > kernel: sky2 status report lost? > > and this is the output from ethtool -S: > > NIC statistics: > tx_bytes: 3092123897 > rx_bytes: 546577898 > tx_broadcast: 20 > rx_broadcast: 4376 > tx_multicast: 0 > rx_multicast: 459 > tx_unicast: 2585993 > rx_unicast: 1550758 > tx_mac_pause: 1 If this is repeatable... and mac_pause is always one then the problem is hardware flow control. I saw bugs before in the bus interface where it would not resume on unaligned buffer, but that was on receive. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
