Bug 477186 - Upgrade to F10 broke wake on LAN
Summary: Upgrade to F10 broke wake on LAN
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 477504 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-19 14:47 UTC by Gary Benson
Modified: 2010-02-15 03:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-18 07:20:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 11865 0 None None None Never

Internal Links: 794788

Description Gary Benson 2008-12-19 14:47:22 UTC
Description of problem:
I recently installed F10 on a box that was previously running FC5.  With the FC5 installation wake on LAN would work so long as you ran "ethtool -s eth0 wol g", but on the F10 install this has no effect.

Version-Release number of selected component (if applicable):
kernel-2.6.27.7-134.fc10.x86_64
e100 driver

How reproducible:
Always

Steps to Reproduce:
1. ethtool -s eth0 wol g
2. poweroff
  
Actual results:
Lights on switch go out, no response to magic packet.

Expected results:
Lights on switch stay on, system wakes up in response to magic packet.

Additional info:
I'm not sure how you find out what card you have (is there somewhere in /proc?) so here's the syslog output of the card coming up instead:

  Dec 16 09:54:56 mambo kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
  Dec 16 09:54:56 mambo kernel: e100: Copyright(c) 1999-2006 Intel Corporation
  Dec 16 09:54:56 mambo kernel: e100 0000:05:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  Dec 16 09:54:56 mambo kernel: e100 0000:05:04.0: PME# disabled
  Dec 16 09:54:56 mambo kernel: e100: eth0: e100_probe: addr 0xfe4ff000, irq 16, MAC addr 00:d0:b7:de:32:69

Comment 1 Matt Castelein 2008-12-24 03:14: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.

Comment 2 Gary Benson 2008-12-24 09:46:15 UTC
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...

Comment 3 Matt Castelein 2008-12-24 13:27:00 UTC
(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..

Comment 4 fedora_user 2009-02-04 20:56:11 UTC
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.

Comment 5 fedora_user 2009-02-04 21:38:26 UTC
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.

Comment 6 fedora_user 2009-02-04 21:39:45 UTC
btw, I'm using a machine with NVIDIA CK804 ethernet controller built into the motherboard.

Comment 7 Mark Litwack 2009-02-04 22:06:07 UTC
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.

Comment 8 Orion Poplawski 2009-02-18 19:03:43 UTC
Seems like a lot of drivers affected by a kernel change.

Comment 9 Orion Poplawski 2009-05-29 16:37:30 UTC
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.

Comment 10 Orion Poplawski 2009-05-29 16:38:19 UTC
BTW - using 2.6.29.4-162.fc11.i686.PAE, so still an issue with F11.

Comment 11 Orion Poplawski 2009-05-29 19:49:52 UTC
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.

Comment 12 Arthur Pemberton 2009-06-22 04:23:59 UTC
*** Bug 477504 has been marked as a duplicate of this bug. ***

Comment 13 Arthur Pemberton 2009-06-22 04:27:52 UTC
Fix suggested in comment #11 worked for me. Though there are other issues with that specific onboard card.

Comment 14 Bug Zapper 2009-11-18 10:31:20 UTC
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

Comment 15 Bug Zapper 2009-12-18 07:20:24 UTC
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.

Comment 16 Michael Ploujnikov 2010-02-14 22:22:29 UTC
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.

Comment 17 Michael Ploujnikov 2010-02-15 02:55:04 UTC
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

Comment 18 Michael Ploujnikov 2010-02-15 03:02:13 UTC
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)

Comment 19 Michael Ploujnikov 2010-02-15 03:16:41 UTC
Both machines that I've mentioned so far run the 2.6.30.10-105.fc11.x86_64 kernel.


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