[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061214153146.52d5de40@freekitty>
Date: Thu, 14 Dec 2006 15:31:46 -0800
From: Stephen Hemminger <shemminger@...l.org>
To: Alex Romosan <romosan@...orax.lbl.gov>
Cc: netdev@...r.kernel.org
Subject: Re: 2.6.20-rc1 sky2 problems (regression?)
On Thu, 14 Dec 2006 15:21:00 -0800
Alex Romosan <romosan@...orax.lbl.gov> wrote:
> Stephen Hemminger <shemminger@...l.org> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists