netdev - Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Aug 2010 15:18:19 -0400
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Maciej Żenczykowski <zenczykowski@...il.com>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Linux NetDev <netdev@...r.kernel.org>
Subject: Re: sky2 driver fails to handle "rx length error: status 0x5d60100
 length 2982" gracefully

On Thu, 12 Aug 2010 09:58:01 -0700
Maciej Żenczykowski <zenczykowski@...il.com> wrote:

> I'm not sure if there is a known good kernel.  It seems to be getting
> worse over time (as I upgrade kernels), but maybe the hardware is
> aging and the situation is becoming more likely.  When it first
> started happening it was like once every 2-3 months or even rarer.
> Now it has happened again since the last time I posted to this
> thread...
> 
> Aug 12 08:29:08 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
> status 0x5e50100 length 3013
> 
> > Are you trying to run with Jumbo >1500 MTU?
> 
> No, normal 1500 MTU network, with ipv4 and ipv6 native traffic.  Not a
> huge amount of traffic either.
> And indeed the problem seems to happen just as easily (if not easier)
> when the machine (and thus the network) is close(r) to idle (ie.
> overnight, etc) - although that might just be a matter of more time
> passing.
> 
> Are you sure there is nothing the driver could do on seeing such an error?
> It seems like since "ip link set eth0 down && ip link set eth0 up"
> fixes it, what it should do is some sort of partial reset...
> 
> I will try to verify if 'ethtool -K eth0 rx off && ethtool -K eth0 rx
> on' is enough to fix the problem (when it happens once again).
> Afterwards I'll turn of rx csum (ethtool -K eth0 rx off) and will see
> if it happens again.


The status values indicate that the GMAC (frame parser) got a reasonable
size frame but the DMA merged frames together. This indicates a timing
problem. There are some bits which even with NDA programmers manual doesn't
help with. The Linux driver expects the BIOS or EEPROM to set them correctly
because different problems different settings.

There is firmware in eeprom that configures internal state. On one motherboard
the vendor provided an update. There is no good way to update this from Linux,
you need to go system vendor and install firmware with their native OS (ie Windows
or MacOS).
--
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