* sky2 0000:02:00.0: error interrupt status=0x8
@ 2008-02-27 2:30 Nathan Grennan
2008-02-27 3:48 ` Stephen Hemminger
0 siblings, 1 reply; 3+ messages in thread
From: Nathan Grennan @ 2008-02-27 2:30 UTC (permalink / raw)
To: netdev
I am using the sky2 driver in kernel-2.6.23.15-137.fc8.x86_64 with
my Marvell 88E8056 to do iSCSI. I have many errors in dmesg like the
ones below. If I count just the lines that match the first one, there
are over 1500. If I include the suppressed lines it is over 100k. At
first I got three of these doing something and then didn't see it for a
while. I suspect the 100k came from a download of an 8gb file from the
internet that was being written to the remote machine via iSCSI. The
download took about an hour and fifteen minutes. I would ignore just
three of these, but 100k of them suggests a real problem to me.
sky2 0000:02:00.0: error interrupt status=0x8
printk: 77 messages suppressed.
I am using a MTU of 9000. Between the two computers is a D-Link
*DGS-2208 *switch that supports jumbo frames. The remote card uses the
forcedeth driver.
This from the kernel package changelog seems like it might apply.
* Mon Jul 09 2007 Chuck Ebbert <cebbert@redhat.com>
- sky2: restore workarounds for lost interrupts
Local dmesg:
sky2 0000:02:00.0: v1.18 addr 0xfe8fc000 irq 17 Yukon-EC Ultra (0xb4) rev 2
Local lspci:
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E
Gigabit Ethernet Controller (rev 12)
Local iSCSI Initiator software:
iscsi-initiator-utils-6.2.0.865-0.2.fc8.x86_64
Remote dmesg:
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01462:7125 bound to 0000:00:0a.0
Remote lspci:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Remote iSCSI Target software:
scsi-target-utils-0.0-4.20071227snap.fc8.x86_64
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: sky2 0000:02:00.0: error interrupt status=0x8
2008-02-27 2:30 sky2 0000:02:00.0: error interrupt status=0x8 Nathan Grennan
@ 2008-02-27 3:48 ` Stephen Hemminger
2008-02-27 4:37 ` Nathan Grennan
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2008-02-27 3:48 UTC (permalink / raw)
To: Nathan Grennan; +Cc: netdev
On Tue, 26 Feb 2008 18:30:47 -0800
Nathan Grennan <linux-netdev@cygnusx-1.org> wrote:
> I am using the sky2 driver in kernel-2.6.23.15-137.fc8.x86_64 with
> my Marvell 88E8056 to do iSCSI. I have many errors in dmesg like the
> ones below. If I count just the lines that match the first one, there
> are over 1500. If I include the suppressed lines it is over 100k. At
> first I got three of these doing something and then didn't see it for a
> while. I suspect the 100k came from a download of an 8gb file from the
> internet that was being written to the remote machine via iSCSI. The
> download took about an hour and fifteen minutes. I would ignore just
> three of these, but 100k of them suggests a real problem to me.
>
> sky2 0000:02:00.0: error interrupt status=0x8
> printk: 77 messages suppressed.
That status comes from the MAC getting an error.
Most likely the receive FIFO is getting overrun. Look at the receive
errors, RX fifo is probably non-zero.
$ ip -s -s li show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:5a:9b:0e:76 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
199873594 240394 0 0 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
^
Make sure and use hardware flow control if you are using jumbo frames because
it is real easy to get the ram buffer full, and frames lost.
The message should just be turned into a debug message since the
functions called by sky2_err_intr() all print a more informative message anyway.
--- a/drivers/net/sky2.c 2008-02-26 19:45:26.000000000 -0800
+++ b/drivers/net/sky2.c 2008-02-26 19:45:43.000000000 -0800
@@ -2587,8 +2587,7 @@ static void sky2_watchdog(unsigned long
/* Hardware/software error handling */
static void sky2_err_intr(struct sky2_hw *hw, u32 status)
{
- if (net_ratelimit())
- dev_warn(&hw->pdev->dev, "error interrupt status=%#x\n", status);
+ dev_dbg(&hw->pdev->dev, "error interrupt status=%#x\n", status);
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: sky2 0000:02:00.0: error interrupt status=0x8
2008-02-27 3:48 ` Stephen Hemminger
@ 2008-02-27 4:37 ` Nathan Grennan
0 siblings, 0 replies; 3+ messages in thread
From: Nathan Grennan @ 2008-02-27 4:37 UTC (permalink / raw)
To: netdev
Stephen Hemminger wrote:
> On Tue, 26 Feb 2008 18:30:47 -0800
> Nathan Grennan <linux-netdev@cygnusx-1.org> wrote:
>
>
>> I am using the sky2 driver in kernel-2.6.23.15-137.fc8.x86_64 with
>> my Marvell 88E8056 to do iSCSI. I have many errors in dmesg like the
>> ones below. If I count just the lines that match the first one, there
>> are over 1500. If I include the suppressed lines it is over 100k. At
>> first I got three of these doing something and then didn't see it for a
>> while. I suspect the 100k came from a download of an 8gb file from the
>> internet that was being written to the remote machine via iSCSI. The
>> download took about an hour and fifteen minutes. I would ignore just
>> three of these, but 100k of them suggests a real problem to me.
>>
>> sky2 0000:02:00.0: error interrupt status=0x8
>> printk: 77 messages suppressed.
>>
>
> That status comes from the MAC getting an error.
> Most likely the receive FIFO is getting overrun. Look at the receive
> errors, RX fifo is probably non-zero.
>
> $ ip -s -s li show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:00:5a:9b:0e:76 brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped overrun mcast
> 199873594 240394 0 0 0 0
> RX errors: length crc frame fifo missed
> 0 0 0 0 0
> ^
>
>
> Make sure and use hardware flow control if you are using jumbo frames because
> it is real easy to get the ram buffer full, and frames lost.
>
>
I couldn't find mention of the flow control till I downed and upped the
interface.
sky2 eth2: Link is up at 1000 Mbps, full duplex, flow control both
Yes, I do have fifo/overrun errors and the count is around the 100k
mark, but not on RX. It is on TX.
ifconfig eth2
eth2 Link encap:Ethernet HWaddr 00:18:F3:7C:38:5A
inet addr:192.168.254.1 Bcast:192.168.254.255 Mask:255.255.255.0
inet6 addr: fe80::218:f3ff:fe7c:385a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:3196945 errors:69 dropped:69 overruns:2 frame:69
TX packets:2930128 errors:0 dropped:0 overruns:111324 carrier:0
collisions:0 txqueuelen:10000
RX bytes:15313780678 (14.2 GiB) TX bytes:14583689334 (13.5 GiB)
Interrupt:17
ip -s -s li show dev eth2
6: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast
qlen 10000
link/ether 00:18:f3:7c:38:5a brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2428878890 3196946 69 69 69 0
RX errors: length crc frame fifo missed
0 0 0 2 0
TX: bytes packets errors dropped carrier collsns
1698787626 2930130 0 0 0 0
TX errors: aborted fifo window heartbeat
0 111324 0 0
I also notice I can't turn on TX checksumming. I can't turn on any of
the others either, except generic segmentation offload.
ethtool -k eth2
Offload parameters for eth2:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
ethtool -K eth2 tx on
Cannot set device tx csum settings: Invalid argument
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-02-27 4:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-27 2:30 sky2 0000:02:00.0: error interrupt status=0x8 Nathan Grennan
2008-02-27 3:48 ` Stephen Hemminger
2008-02-27 4:37 ` Nathan Grennan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).