Bug 10130
| Summary: | r8169 doesn't negotiate 1000baseT mode after suspend/resume | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Bas Zoetekouw (bas) |
| Component: | Network | Assignee: | Francois Romieu (romieu) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | bugzilla, bunk, centaur, erbrochendes, jnelson-kernel-bugzilla, pizza, rjw, stefan.andreas.bauer |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.24.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 7216 | ||
| Attachments: |
PHY init after resume
[2.6.33.5] Fix random mdio write failures [2.6.33.5] Fix mdio read and update mdio write after Realtek's spec (Hand-patch as applied to F13 kernel) incorrect identifier for a 8168dp |
||
|
Description
Bas Zoetekouw
2008-02-28 07:10:47 UTC
Can you send the output of 'mii-tool -vv' : - before the suspend - after the resume (broken) - after the mode is forced Thanks. -- Ueimor Before suspending:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 32:
1000 796d 001c c912 0de1 c5e1 000d 2001
4ce1 0300 3800 0000 1007 f880 0000 3000
0060 acc0 0000 0000 1060 0000 d00c 2108
2740 8c00 0040 0106 097c 8000 0123 0000
product info: vendor 00:07:32, model 17 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
After suspend/resume cycle:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 32:
1000 796d 001c c912 0de1 c5e1 000f 2001
c5e1 0000 0000 0000 1007 f880 0000 3000
0060 6c00 0000 6c42 1060 0000 870c 2108
2740 8c00 0040 0162 846c 8000 0123 0000
product info: vendor 00:07:32, model 17 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
after forcing Gb speed with ethtool:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 32:
1000 796d 001c c912 0de1 c5e1 000f 2001
4d68 0300 3800 0000 1007 f880 0000 3000
0060 ac80 0000 6c42 1060 0000 e00c 2108
2740 8c00 0040 0106 097c 8000 0123 0000
product info: vendor 00:07:32, model 17 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Created attachment 15100 [details]
PHY init after resume
Can you give this patch a try on top of 2.6.24 ?
Please add the updated mii-tool outputs (and keep the old ones).
--
Ueimor
Just tried it, and it doesn't seem to make any difference... bas@debian.org 2008-02-29 15:49 : > Just tried it, and it doesn't seem to make any difference... Can you send the mii-tool output of the network interface just after the resume ? The r8169 does not seem to see the expected advertisement from the link partner after resume. Is there some way for you to check that the switch still advertises 1000 Mbps after the resume ? I'll welcome the command that you use to force the Gb mode too. > Can you send the mii-tool output of the network interface just after the > resume ? That's quoted above already in comment #2 ("After suspend/resume cycle"). Note in particular that according to mii-tool, the 1000baseT _capability_ of the card is missing at that point. To switch the card back to 1000Mbit, I simply use "ethtool -s eth0 speed 1000". For what it's worth, I have this problem too.
uname -r:
2.6.29.3-60.fc10.x86_64
(bug exists in 2.6.27 too, and possibly older)
lspci -v:
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: ASUSTeK Computer Inc. U6V laptop
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at e800 [size=256]
Memory at f8fff000 (64-bit, prefetchable) [size=4K]
Memory at f8fe0000 (64-bit, prefetchable) [size=64K]
Expansion ROM at feaf0000 [disabled] [size=64K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
ethtool pre-suspend: (nothing plugged in)
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: no
ethtool post-suspend:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: no
Interestingly, if I remove the module and re-insert it, things work fine.
I can confirm all of the above. openSUSE 11.1 kernel, 2.6.27.29 Any progress on this? Still seen in 2.6.31. Bug still present in 2.6.32.7 Bug still present in 2.6.33.5 Bug still present in 2.6.34 I can confirm this bug on my Debian box. Please fix this! Confirmed still present in F13 with kernel 2.6.33.5-124.fc13.x86_64 Created attachment 27048 [details]
[2.6.33.5] Fix random mdio write failures
Created attachment 27049 [details]
[2.6.33.5] Fix mdio read and update mdio write after Realtek's spec
Can someone check the two patches above against a stable 2.6.33.5 ?
Thanks.
--
Ueimor
Created attachment 27099 [details] (Hand-patch as applied to F13 kernel) (In reply to comment #15) > Created an attachment (id=27049) [details] > [2.6.33.5] Fix mdio read and update mdio write after Realtek's spec > > Can someone check the two patches above against a stable 2.6.33.5 ? > > Thanks. Well, I tried it against Fedora 13's kernel-2.6.34.1-11.fc13, but had to do so by hand (see the attached diff). Had no effect. Maybe I botched the patch? Created attachment 27123 [details]
incorrect identifier for a 8168dp
James Ettle :
[...]
> Well, I tried it against Fedora 13's kernel-2.6.34.1-11.fc13, but had to do
> so
> by hand (see the attached diff). Had no effect. Maybe I botched the patch?
Apparently not. Your diff seems fine.
Can you grep the xid debug line from the kernel log when the module
it inserted ? There are quite a few different 8168 chips.
--
Ueimor
(In reply to comment #18) > Can you grep the xid debug line from the kernel log when the module > it inserted ? There are quite a few different 8168 chips. $ dmesg | grep 8169 r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:08:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 r8169 0000:08:00.0: setting latency timer to 64 r8169 0000:08:00.0: irq 32 for MSI/MSI-X r8169 0000:08:00.0: eth0: RTL8168b/8111b at 0xffffc9002474c000, 00:90:f5:69:d5:9e, XID 18000000 IRQ 32 r8169 0000:08:00.0: eth0: link down (It's really not plugged in at the moment.) Anything happened since? (I'm not currently near a Gigabit network, I'll be able to test with 2.6.36 some time next week.) It looks like this should be fixed in 2.6.37-rc8, any chance to verify? (In reply to comment #21) > It looks like this should be fixed in 2.6.37-rc8, any chance to verify? I just tested STR and STD on 2.6.37-rc8 and it seems to be fixed for me. (This is the on-board NIC of an Asus M3A78) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Subsystem: ASUSTeK Computer Inc. Device 82c6 Flags: bus master, fast devsel, latency 0, IRQ 41 I/O ports at e800 [size=256] Memory at fbeff000 (64-bit, non-prefetchable) [size=4K] Memory at faff0000 (64-bit, prefetchable) [size=64K] Expansion ROM at fbec0000 [disabled] [size=128K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=2 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel <?> Capabilities: [160] Device Serial Number 00-00-00-00-ec-10-68-81 Kernel driver in use: r8169 Kernel modules: r8169 Great, closing. |