Bug 6108
Summary: | Failure of r8169 ethernet i/f after resume from S3 sleep | ||
---|---|---|---|
Product: | Drivers | Reporter: | David Giddy (d.giddy) |
Component: | Network | Assignee: | Francois Romieu (romieu) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | akpm, alan, d.giddy, fnd, gilles, patrick.thomson, protasnb, romieu |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.15.3 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
r8169 resume tryfix
r8169: fix broken ring index handling in suspend/resume r8169: enable wake on lan .rej file for the seperate wol enable patch |
Description
David Giddy
2006-02-20 02:38:32 UTC
Created attachment 7426 [details]
r8169 resume tryfix
The way rtl8169_resume() handles the ring indexes is completely broken.
The patch seems to have fixed the problem. Machine will now suspend and resume and the ethernet interface seems to function normally - Thanks! Now I need to get Wake-on-LAN working - I presume the driver should support that ? Any config gotchas to be aware of ? Many thanks, David. David Giddy: [...] > Now I need to get Wake-on-LAN working - I presume the driver should support that ? 'g' mode has just been reported to work. > Any config gotchas to be aware of ? The same report said that 'pumbg' did not produce the expected result but I have not understood what it did exactly. Feel free to describe it. :o) -- Ueimor I tried using ethtool to set each mode and in all cases, it appears to remain disabled, yet it claims to support all modes. When I put machine into S3, LAN LEDs are off, which I suspect means the I/F has been completely powered off. The BIOS setting for wake-on-Ring (LAN) is enabled as are "Wake on PME". simba:/home/david# ethtool -s eth0 wol g simba:/home/david# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000033 (51) Link detected: yes simba:/home/david# Let me know any tests you would like run. The patch provided by Francois has also fixed my issue - namely, a netgear DGE-528T that uses the 8169 chip, but has wake-on-lan that was not previously supported properly by the kernel (much to my frustration). Report: mode g works as expected with a magic packet. mode p works as expected (poweron when ethernet cable plugged in) (this will cause the strange bouncing-back after a powerdown when the card is placed in mode pumbg - since there is already PHY activity by the fact I never unplugged the cable in the first place) Further tests pending. (personally, this is entirely a feature request, since the machine I use this card in has a really inacessible power switch) Patrick Created attachment 7446 [details]
r8169: fix broken ring index handling in suspend/resume
Created attachment 7447 [details]
r8169: enable wake on lan
David, Patrick, could you try the two patch that I have just attached in that order on top of 2.6.16-rc4, namely: - r8169: fix broken ring index handling in suspend/resume - r8169: enable wake on lan The first one should fix the suspend/resume issue. No WOL. The second one should add the WOL feature. Separating the bugfix from the wol feature should ease the merge process (I'll try both for 2.6.16 but there is no guarantee) and there are a few little differences from the previous, aggregated, version. -- Ueimor Created attachment 7453 [details]
.rej file for the seperate wol enable patch
It seems that the wol enable patch no longer applies cleanly - It could still
be that I am making a silly mistake, but I tried everything I could think of to
get this to apply cleanly and failed. Vanilla 2.6.15.4 having previously
reverted the existing patch.
Yes, I can't read instructions. That would be what happens when I forget to apply the broken ring index handling patch first. Apologies, but I tend to work on this early in the morning, perhaps not the best time to patch a kernel. I can confirm that the compound patch still enables wake on lan with the same functionality I managed to test last time. I also feel rather stupid about the triple post, but this is offset by the warm fuzzy feeling of contributing in some small way to the community that supported my needs for so long. Great job, guys! I tried the two patches against 2.6.16-rc4 and found the following: - resume still works, however the interface seems to drop back from 1000Mb/s to 100 Mb/s after resume and stay there. I tried ethtool -r eth0, but apparently triggering re-negotiation is not currently supported. - setting the wol bits now is correctly reflected in the output of ethtool: simba# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: pumbg Current message level: 0x00000033 (51) Link detected: yes However, when I put the computer into S3 sleep, the ethernet LEDs go dark and there is no response to either a directed packet or a magic packet. Francois, Any further suggestions on getting WOL working (see my last response)? Any recommendations on how to test further ? Thanks, David. Hi! just wanted to add that wake-on-lan modes p and g work for me on 2.6.15.4 (I didn't test any other), but only on the first of the three RTL8169 chips of my board. I don't know if that's a driver bug or a hardware thing. I only need one port to wake the machine up, so for me, everything works perfectly. Many thanks to Francois for the patch! Michael Francois, Any further progress on this bug ? See my last comments on the problems I am still seeing. Thanks, David. this issues appears to be driver specific, rather than ACPI related. moving to drivers/network Is the problem still there with 2.6.18? I think this entry should be closed due to the lack of response from the reporter. bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> : [...] > I think this entry should be closed due to the lack of response from the reporter. I prefer to keep it open: - some of my r8169 queue from 05/2006 will only be in 2.6.19 ; - there is a flood of new 8169-like (8168) since mid-2006 ; - I am not convinced that the issue has gone/is negligible. Sorry, I've been flat out. I haven't had time to followup this bug as I ditched the offending card and have been using an e1000 based card (successfully) since. It was still a problem when I last looked some months back and I haven't seen any updates to the driver since. On 10/27/06, bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=6108 > > > > > > ------- Additional Comments From rjwysocki@sisk.pl 2006-10-26 09:48 ------- > I think this entry should be closed due to the lack of response from the reporter. > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are on the CC list for the bug, or are watching someone who is. > This one should be fixed by the patch available at: http://www.fr.zoreil.com/people/francois/misc/20070402-2.6.21-rc5-r8169-test.patch If nobody complains, I will close the bug as soon as the relevant bits hits the main trunk. -- Ueimor Note to myself: the failure of autonegotation after resume needs to be fixed. This is the same bug that Peter Missel <peter.missel@onlinehome.de> reported on netdev (16/04/2007+). -- Ueimor It looks like the patch mentioned in #21 is in, should David test it? Ueimor, I suppose you would still like to keep this bug open until you get the problem in #22? Thanks. Natalie Protasevich:
[...]
> I suppose you would still like to keep this bug open until you get the
> problem in #22?
Yes.
--
Ueimor
Still relevant ? Alan :
> Still relevant ?
No. It can be closed without a significant loss of information.
I guess that it either calls for more PHY tweaks or it will be fixed with
some (not too) different WOL problem.
--
Ueimor
|