netdev - Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration

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:	Sat, 17 Mar 2012 11:56:25 +0200
From:	Timo Teras <timo.teras@....fi>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	netdev@...r.kernel.org
Subject: Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and
 performance degration

On Fri, 16 Mar 2012 22:15:57 +0200 Timo Teras <timo.teras@....fi> wrote:

> On Thu, 15 Mar 2012 20:11:18 +0100 Francois Romieu
> <romieu@...zoreil.com> wrote:
> 
> > Timo Teras <timo.teras@....fi> :
> > [...]
> > > The other broken box is connected to a HP ProCurve 4202vl-48G, and
> > > the switch is reporting drops due to FCS Rx errors.
> > [...]
> > > So I have two broken pieces of hardware, or there is a driver bug.
> > 
> > I'll take blame for any bug in the driver. However many ethernet
> > controllers are and the PCI 8169 is no exception.
> 
> Ok.
> 
> As a side though, all these devices suffered from the bug I fixed
> earlier. See commit 024a07bac (r8169: fix random mdio_write failures).
> Also, all these devices probably got garbage written to their PHY. So
> I'm wondering if it is possible that it caused some permanent damage?
> 
> Would it be possible to dump/compare the related things?
> 
> Additional pointer to this direction is that one of the "broken" boxes
> has different PCI ID for the "broken NIC" of the three. The hardware
> is Jetway daughter board with the three NICs on single board. So it
> sounds really weird that one of those NICs chips would be from
> different series. I wonder if the PCI ID and other stuff could have
> got corrupted in EEPROM or something similar.

It seems that we have working eeprom reading code in commit 6709fe9a27e4
"r8169: read MAC address from EEPROM on init (2nd attempt)" which later
got reverted due to problems. I'm now wondering if those problems were
actually caused by unrelated issues that got later fixed in 78f1cd02457
"r8169: fix broken register writes".

I wonder if it'd be worth to do the eeprom reading and expose it via
ethtool so I can compare those. Or as easy alternative, enabling the VPD
bit in Config1 should allow me to read the EEPROM contents using the PCI
/sys/.../vpd interface, right?

And maybe re-introduce the reading of the MAC from there on reboot. Or
if could just do:
-	Cfg9346_Lock    = 0x00,
+	Cfg9346_Lock    = 0x40,

The 0x40 apparently means "Auto-load: the EEPROM contents will be
reloaded when PCI RSTB signal is asserted, and will automatically
resume to normal 0x00 mode after the load".
--
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