Bug 15604 - r8169: Reports incorrect link information
r8169: Reports incorrect link information
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Network
All Linux
: P1 low
Assigned To: Francois Romieu
:
Depends on:
Blocks: 14885
  Show dependency treegraph
 
Reported: 2010-03-22 04:19 UTC by Michael B. Trausch
Modified: 2011-01-09 10:16 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.33
Tree: Mainline
Regression: Yes


Attachments

Description Michael B. Trausch 2010-03-22 04:19:22 UTC
First note that it is possible that this bug is more than this; I cannot force settings on my internet Ethernet interface using this driver either.  I need to boot into 2.6.32 to see if it possible there.

In 2.6.32, when I plug into a gigabit Ethernet network, the driver reports a 1000Mbit, full duplex link.  However, in 2.6.33, only a 10Mbit, half-duplex link is reported.  When I run a speed test on the network, though, I am able to get the same actual transfer speeds in either case, leading me to believe that the driver is bringing up the hardware just fine, but misreporting information.

The first version that I have which has the problem is 2.6.33; I have not yet had a chance to bisect the kernel tree to find the commit that presents the problem.  I should have time to do this in the next 24 hours.
Comment 1 Francois Romieu 2010-03-22 22:46:39 UTC
A simple dmesg (2.6.32 / 2.6.33) would be a good start to identify your
chipset too.

-- 
Ueimor
Comment 2 Michael B. Trausch 2010-03-23 04:28:22 UTC
Here is dmesg output from 2.6.33.  I am about to start the bisection now, I had an extremely long-running job that prevented me from being able to do that until now.

[    2.903317] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    2.903343] r8169 0000:09:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    2.903404] r8169 0000:09:00.0: setting latency timer to 64
[    2.903436]   alloc irq_desc for 29 on node 0
[    2.903438]   alloc kstat_irqs on node 0
[    2.903453] r8169 0000:09:00.0: irq 29 for MSI/MSI-X
[    2.903819] eth0: RTL8168d/8111d at 0xffffc90002168000, 00:26:9e:5c:8c:41, XID 081000c0 IRQ 29
Comment 3 Michael B. Trausch 2010-03-24 05:02:34 UTC
My bisection concluded with "421355de876b9f3fcc7e4cb6026e416fb12a5068 is the first bad commit".  The bisection log is:

# bad: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect start 'v2.6.33' 'v2.6.32'
# bad: [5f1141eb352ea79d849920039503e40dd623fffa] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 5f1141eb352ea79d849920039503e40dd623fffa
# good: [3ad1f3b35e8309ec93454dbf89beaafcdb5312da] Merge branch 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6
git bisect good 3ad1f3b35e8309ec93454dbf89beaafcdb5312da
# bad: [41440ffe21f29bdb985cab76b2d0b06d83e63b19] Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
git bisect bad 41440ffe21f29bdb985cab76b2d0b06d83e63b19
# bad: [1e875e9f16e3138d0e23cbf806a6d9520b622db2] ath9k: rename ath_rx_prepare() to ath9k_rx_skb_preprocess()
git bisect bad 1e875e9f16e3138d0e23cbf806a6d9520b622db2
# bad: [bd6b4442ff3cee73f73987cf0c0e66ea677aa075] ath: Updates for regulatory and country codes.
git bisect bad bd6b4442ff3cee73f73987cf0c0e66ea677aa075
# good: [70f9cf8951e5253cfef821f8dcb92f6fc3af50c6] netxen: add sysfs entries for diag tools
git bisect good 70f9cf8951e5253cfef821f8dcb92f6fc3af50c6
# bad: [743cdf1b65656faf1e6f1f74278c52b89a0b7360] iwl3945: streamline iwl3945_rfkill_poll()
git bisect bad 743cdf1b65656faf1e6f1f74278c52b89a0b7360
# bad: [d8eb59dc8b9e77bb4fa5420ff80142759ad5cd7b] qlge: Add ethtool blink function.
git bisect bad d8eb59dc8b9e77bb4fa5420ff80142759ad5cd7b
# bad: [caa2dd53bc2f9c44938f2f261ebe15e2f26cc51e] netxen: sysfs control for auto firmware recovery
git bisect bad caa2dd53bc2f9c44938f2f261ebe15e2f26cc51e
# bad: [766e9037cc139ee25ed93ee5ad11e1450c4b99f6] net: sk_drops consolidation
git bisect bad 766e9037cc139ee25ed93ee5ad11e1450c4b99f6
# bad: [421355de876b9f3fcc7e4cb6026e416fb12a5068] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad 421355de876b9f3fcc7e4cb6026e416fb12a5068
# good: [231835e4163cf14c90e295f1729004f571ee1cc7] igb: Fix erroneous display of stats by ethtool -S
git bisect good 231835e4163cf14c90e295f1729004f571ee1cc7
# good: [b4efc5610980bc4b65a6cb49b939cf5f7dfa2723] net: enable smsc911x on MIPS
git bisect good b4efc5610980bc4b65a6cb49b939cf5f7dfa2723
# good: [aace495933a981274b6491d71b915165a61defdc] net: smsc911x: allow platform_data to specify mac address
git bisect good aace495933a981274b6491d71b915165a61defdc

There is an interesting other issue, however, which may make this inaccurate.  It would seem that near the end, within the last three or so bisections, the Ethernet interface got "stuck" somehow.  I powered off after I discovered this, and it seemed okay after that point, but I need to repeat the bisection to try to confirm that.

I am not able to pull up any more information, as I don't know what the commands in git are for that.  I'll try to find that out, but if someone can tell me how to bisect "into" a merge, I might be able to pinpoint it more accurately than that.
Comment 4 Francois Romieu 2010-03-26 21:00:04 UTC
Michael B. Trausch <mike@trausch.us>  :
[...]
> I am not able to pull up any more information, as I don't know what the
> commands in git are for that.  I'll try to find that out, but if someone can
> tell me how to bisect "into" a merge, I might be able to pinpoint it more
> accurately than that.

You may check that 0fe7463a35aadfaf22d1ca58325ab3851b8d757c (421355's parent)
does not work and you restart from this commit.

Imho 0fe7463a35aadfaf22d1ca58325ab3851b8d757c^^ is ok and
0fe7463a35aadfaf22d1ca58325ab3851b8d757c^ is broken.

-- 
Ueimor
Comment 5 Michael B. Trausch 2010-03-27 02:12:18 UTC
Could you explain how to do that, or point me to something that will tell me how to do that?  And what is the "^^" and "^"?  Consider me one of those ignorant, unintelligent users of other DVCS systems.  :-)
Comment 6 Francois Romieu 2010-03-27 10:43:53 UTC
Michael B. Trausch <mike@trausch.us>  :
> Could you explain how to do that ?

git reset 0fe7463a35aadfaf22d1ca58325ab3851b8d757c
git checkout -f
build, test, crash

[...]
> And what is the "^^" and "^"?

^ is a shorthand for the parent. See 'man 7 gittutorial', "EXPLORING HISTORY".

-- 
Ueimor
Comment 7 Florian Mickler 2010-12-08 07:59:08 UTC
Ping?
Comment 8 Francois Romieu 2010-12-08 22:24:17 UTC
Florian Mickler :
> Ping ?

Pong.

It apparently is a 8168d identified as RTL_GIGA_MAC_VER_25 in the driver.
It should work better with the two patches below on top of 2.6.37-rc
http://marc.info/?l=linux-netdev&m=129161959416963
http://marc.info/?l=linux-netdev&m=129119732929951

-- 
Ueimor
Comment 9 Florian Mickler 2010-12-09 10:07:00 UTC
Patch: http://patchwork.ozlabs.org/patch/74317/
The other patch (the firmware) doesn't seems to be for the linus tree, but for the firmware tree? 

As far as I understand this is a new version of the firmware?
Comment 10 Francois Romieu 2010-12-14 23:42:59 UTC
Florian Mickler :
[...]
> The other patch (the firmware) doesn't seems to be for the linus tree, but for
> the firmware tree? 

Yes.

> As far as I understand this is a new version of the firmware ?

Exactly.

-- 
Ueimor
Comment 11 Florian Mickler 2011-01-08 22:20:50 UTC
Commit:     bca03d5f32c8ee9b5cfa1d32640a63fded6cb3c0
Comment 12 Florian Mickler 2011-01-08 22:33:22 UTC
References: http://marc.info/?l=linux-netdev&m=129442611107360&w=2
Comment 13 Francois Romieu 2011-01-08 23:00:25 UTC
Florian Mickler :
[...]
> References: http://marc.info/?l=linux-netdev&m=129442611107360&w=2

- it is not a bug
- I have already sent a fix

-- 
Ueimor
Comment 14 Florian Mickler 2011-01-09 10:16:56 UTC
I already closed this bug as CODE_FIX. The link is just for reference. 

Regards,
Flo

Note You need to log in before you can comment on or make changes to this bug.