netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timo Teras <timo.teras@iki.fi>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Ben Hutchings <bhutchings@solarflare.com>,
	netdev@vger.kernel.org
Subject: Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration
Date: Sat, 17 Mar 2012 11:56:25 +0200	[thread overview]
Message-ID: <20120317115625.3fc04de4@vostro> (raw)
In-Reply-To: <20120316221557.235f5ffd@vostro>

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

> On Thu, 15 Mar 2012 20:11:18 +0100 Francois Romieu
> <romieu@fr.zoreil.com> wrote:
> 
> > Timo Teras <timo.teras@iki.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".

  reply	other threads:[~2012-03-17  9:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 17:01 linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration Timo Teras
2012-03-14 17:15 ` Eric Dumazet
2012-03-14 17:29   ` Timo Teras
2012-03-14 18:25     ` Eric Dumazet
2012-03-14 19:29     ` Ben Hutchings
2012-03-14 19:51       ` Timo Teras
2012-03-14 20:12         ` Eric Dumazet
2012-03-14 20:33           ` Timo Teras
2012-03-14 20:52             ` Eric Dumazet
2012-03-14 20:53             ` Francois Romieu
2012-03-15  6:06               ` Timo Teras
2012-03-15 15:11                 ` Timo Teras
2012-03-15 16:11                   ` Eric Dumazet
2012-03-15 18:47                     ` Timo Teras
2012-03-15 19:11                   ` Francois Romieu
2012-03-16 20:15                     ` Timo Teras
2012-03-17  9:56                       ` Timo Teras [this message]
2012-03-17 11:35                         ` Francois Romieu
2012-03-17 22:20                           ` Francois Romieu
2012-03-18  7:00                             ` Timo Teras
2012-03-20 15:31                             ` Timo Teras
2012-03-20 18:20                               ` Francois Romieu
2012-03-14 21:16 ` Francois Romieu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120317115625.3fc04de4@vostro \
    --to=timo.teras@iki.fi \
    --cc=bhutchings@solarflare.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).