Message-ID: <76366b180705281406j69d08bbeu77ff18991f161df8@mail.gmail.com>
Date:	Mon, 28 May 2007 17:06:43 -0400
From:	"Andrew Paprocki" <andrew@...iboo.com>
To:	"Francois Romieu" <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org
Subject: Re: r8169 in 2.6.18 silently corrupting data, 2.6.22-rc3 link not detected at all

Attached are the following:
- 2.6.18 dmesg output (working link, but data corruption)
- 2.6.22-rc3 .config, dmesg, ethtool -S, lspci -vvx, mii-tool -vv

All 2.6.22-rc3 logs are with a clean 2.6.22-rc3 + patch URL you
supplied. I verified the new eeprom driver was loaded along w/ r8169
at boot. The link still does not work at boot time or if I restart
auto-nego using mii-tool.

Inside the mii log, I provided what I can determine to be the loop of
PHY registers while it is looking for a link. I saw that it only
printed out a few different register patterns and it repeats them in a
loop, so I dumped them all, if that helps.

Also, while transferring these logs off the machine, I noticed that
the 2.6.18 data corruption only happens on RX, not TX. If I push files
to a remote host they get there fine, but if I attempt to pull any
files (netcat, web, ftp, etc), they are all corrupt in the manner I
described before.

The align errors in ethtool show up even in the "working" 2.6.18.
Could this be related to the fact that other hosts on this gigabit
network run with a 9000 MTU? I saw that this chipset has a hardware
limitation and the drivers caps off at 7200..

-Andrew

On 5/28/07, Francois Romieu <romieu@...zoreil.com> wrote:
> Andrew Paprocki <andrew@...iboo.com> :
> [...]
> > This struck me as strange, so I checked and it is directly connected
> > to the MAC addr of the ethernet card: 00:0c:76:ae:b5:16
> >
> > I figured that a newer kernel might fix this issue, so I built
> > 2.6.22-rc3 and under that kernel the r8169 device doesn't work at all.
> > It never detects a valid link. I insmod'd the driver with debug=16 and
> > all I see it printing is "eth0: PHY reset until link up" on a timer.
>
> Ok.
>
> You will not pollute the console much with a single bit of debug.
>
> > I see some patches flying around for r8169.c, but I'm not sure if
> > either of these two cases are known/fixed
>
> I am not sure either. With the usual luck, I could bet that an update
> will make the alignment issue go away while introducing a link negotiation
> regression.
>
> > Also, this is a gigabit NIC on a gig-e switched network, yet mii-tool
> > only reports 10mb-hd speed... ?
>
> Auto-negotiation probably failed. Your ethernet cables are fine, aren't they ?
>
> Please:
> - send a 'lspci -vvx' of the host
> - try 2.6.22-rc3 +
>   http://www.fr.zoreil.com/people/francois/misc/20070527-2.6.22-rc3-r8169.patch
> - send a complete dmesg (2.6.18 and 2.6.22-rc3 patched)
> - send 'mii-tool -vv' and 'ethtool -S' for a patched 2.6.22-rc3
> - send .config (one never knows...)
>
> [...]
> > # ethtool -S eth0
> > NIC statistics:
> >     tx_packets: 4397
> >     rx_packets: 6701
> >     tx_errors: 1
> >     rx_errors: 999
> >     rx_missed: 0
> >     align_errors: 25770
>                     ^^^^^
> ~2/3 of misaligned packets. Wow. Same thing with both interfaces ?
>
> If the patched kernel does not detect the link, restart autonegotiation
> with mii-tool.
>
> --
> Ueimor
>
>

Download attachment "2.6.18.dmesg" of type "application/octet-stream" (10611 bytes)

Download attachment "2.6.22-rc3.config" of type "application/xml" (48629 bytes)

Download attachment "2.6.22-rc3.dmesg" of type "application/octet-stream" (11450 bytes)

Download attachment "2.6.22-rc3.ethtool" of type "application/octet-stream" (300 bytes)

Download attachment "2.6.22-rc3.lspci" of type "application/octet-stream" (12316 bytes)

Download attachment "2.6.22-rc3.mii-tool" of type "application/octet-stream" (1813 bytes)

Powered by blists - more mailing lists