Bug 477186
Summary: | Upgrade to F10 broke wake on LAN | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gary Benson <gbenson> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | kernel-maint, mlitwack, myjunkemail17, orion, ploujj, sergio.pasra, s-taka, uwe |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-18 07:20:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gary Benson
2008-12-19 14:47:22 UTC
I'm seeing the same thing, not on an upgrade, but on a fresh F10 install on a former windows box. Set wake on lan, and poweroff... send wake up packet.. NOTHING. Also I think this could be a little simpler to do.. having to enter some ethtool command every time is silly when I look at the fact all I had to do was check a box in windows and this machine would wake up every time I needed. So once it works you don't have to (manually) run the command. On my older installation I added the line: ETHTOOL_OPTS="wol g" to the file /etc/sysconfig/network-scripts/ifcfg-eth0. Not quite as simple as checking a box, but maybe there's a GUI solution in Fedora too. But of course adding that line does nothing if ethtool itself doesn't work... (In reply to comment #2) > So once it works you don't have to (manually) run the command. On my older > installation I added the line: > > ETHTOOL_OPTS="wol g" > > to the file /etc/sysconfig/network-scripts/ifcfg-eth0. Not quite as simple as > checking a box, but maybe there's a GUI solution in Fedora too. > > But of course adding that line does nothing if ethtool itself doesn't work... That's good enough for me, as long as I can "set it and forget it".. now on to getting it working.. I came across this same bug. I (fresh) installed Fedora 10 to the same machine previously with Fedora 8. In Fedora 8 wake on lan was working using ethtool to set wol to g at halt as indicated above. Now that the same machine with the same hardware has Fedora 10, wake on lan no longer works. I've installed Windows XP to the same machine, and wake on lan works fine. But Fedora 10 wake on lan is broken. ethtool reports wol is "g" after I run "/sbin/ethtool -s eth0 wol g" but seems like something in the OS or kernel is preventing wake on lan. Hopefully there is a solution soon. Thanks. I came across a few forums about an old forcedeth bug that was breaking wake on lan, but this seems to be fixed in subsequent Fedora releases. It seems that forcedeth reverses the mac address of the ethernet interface. The quick and dirty solution is to send the mac address in reverse when sending the magic packet using a wol client. ether-wake F0:0F:15:6D:AC:CA reverse the mac address ether-wake CA:AC:6D:15:0F:F0 Sure enough this works for my Fedora 10. Did the forcedeth bug reappear in Fedora 10? Hopefully this helps someone. btw, I'm using a machine with NVIDIA CK804 ethernet controller built into the motherboard. Same thing here. I've been using the wake-on-lan feature on my IBM T43 laptop on Fedora 8 and its predecessors. I recently installed Fedora 10 and found I could no longer wake it up. There was no link light anymore in suspend. It appears that the PCI ACPI device that handles my ethernet is in a "wakeup disabled" state according to "acpitool -w". (I'm assuming it was enabled in F8, but I'm not running it anymore to be able to find out.) Using "acpitool -W <devnum>" to re-enable the device allows WOL to work again for me. I was able to figure out the correct device name by using "acpitool -w" and "lspci" and experimenting with "acpitool -W" until the link light stayed on in suspend. The name will vary from platform to platform, but the right device name for the T43 is "EXP0". Here is a snippet that can be placed in /etc/rc.local: ACPIDEV="EXP0" echo "Enabling ACPI device $ACPIDEV so that WOL works..." # if acpitool -w | grep -q "$ACPIDEV.*enabled"; then echo "Already enabled" else acpitool -W $(acpitool -w | awk -F. '/'"$ACPIDEV"'/{print $1}') fi Replace EXP0 with the name of your ACPI device once you figure out what it is. You'll still need whatever ethtool settings you were using before. I suppose this should be considered a workaround until it gets fixed for real, or maybe there's a better way to do it. But it worked for me. YMMV. Bug #477504 is a possible duplicate of this issue, but there's not as much info there and it's also F9. I've had this same issue before with older versions of Fedora and other platforms (sorry, don't have the specifics). I suppose the right fix would be to automatically figure out the ACPI device dependencies if WOL gets enabled on an ethernet. Seems like a lot of drivers affected by a kernel change. Dell Dimension 4700. I needed to enable "PCI1" in /proc/acpi/wakeup (echo PCI1 > /proc/acpi/wakeup): PCI1 S5 enabled pci:0000:00:1e.0 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 03:08.0 Ethernet controller: Intel Corporation 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller (rev 03) So my guess is that while eth0 wol was enabled the PCI bus that device was plugged into was not enabled to wakeup the machine. I suppose this may be a bios issue, but I imagine it could get worked around in the kernel somehow. BTW - using 2.6.29.4-162.fc11.i686.PAE, so still an issue with F11. Here's what I'm using: pciid=`lspci | awk '/PCI Bridge/ { print $1 }'` if [ -n "$pciid" ] then acpidev=`awk -v pciid=$pciid '$4 ~ pciid && $3 == "disabled" { print $1 }' /proc/acpi/wakeup` echo $acpidev > /proc/acpi/wakeup fi This has make wake on lan functional for me on a couple of different machines, though not all. *** Bug 477504 has been marked as a duplicate of this bug. *** Fix suggested in comment #11 worked for me. Though there are other issues with that specific onboard card. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. I think this is still an issue in F11 and F12. I have PME enabled in the BIOS and ethtool shows "Wake-on: g", but I can't wake up any of the three computers I've tried with a wol tool. machine1: # ethtool eth0 Settings for eth0: 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: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes # dmesg|grep PME pci 0000:00:02.0: PME# supported from D0 D3hot D3cold pci 0000:00:02.0: PME# disabled pci 0000:00:07.0: PME# supported from D0 D3hot D3cold pci 0000:00:07.0: PME# disabled pci 0000:00:13.5: PME# supported from D0 D1 D2 D3hot pci 0000:00:13.5: PME# disabled pci 0000:00:14.2: PME# supported from D0 D3hot D3cold pci 0000:00:14.2: PME# disabled pci 0000:02:00.0: PME# supported from D1 D2 D3hot D3cold pci 0000:02:00.0: PME# disabled # lspci |grep Eth 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) [root@turbo-desktop ~]# lspci |grep "PCI Bridge" 00:02.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Graphics Port 0) 00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3) 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge Ethernet light does not stay on after 'poweroff' on this machine. Actually, on one machine just 'ethtool -s eth1 wol g' was enough for me. This machine runs F11 with the 2.6.30.10-105.2.23.fc11.x86_64 kernel and has this NIC: 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) WOL works even if I see this output right before poweroff: $ acpitool -w Device S-state Status Sysfs node --------------------------------------- 1. HUB0 S5 disabled pci:0000:00:09.0 2. XVR0 S5 disabled pci:0000:00:0e.0 3. XVR1 S5 disabled pci:0000:00:0d.0 4. XVR2 S5 disabled pci:0000:00:0c.0 5. XVR3 S5 disabled pci:0000:00:0b.0 6. USB0 S3 disabled pci:0000:00:02.0 7. USB2 S3 disabled pci:0000:00:02.1 8. MMAC S5 disabled pci:0000:00:0a.0 9. MMCI S5 disabled 10. UAR1 S5 disabled pnp:00:08 However, configuring the appropriate (2nd NICs) network-script doesn't actually enable wol like ethtool does: # cat /etc/sysconfig/network-scripts/ifcfg-eth1 # Networking Interface DEVICE=eth1 HWADDR=00:0F:EA:79:86:AC ETHTOOL_OPTS="wol g" # ethtool eth1 Settings for eth1: Supported ports: [ TP ] 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: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: d Current message level: 0x000000ff (255) Link detected: yes (Confirmed by `wol 00:0f:ea:79:86:ac` not waking up the machine and no NIC light) Both machines that I've mentioned so far run the 2.6.30.10-105.fc11.x86_64 kernel. |