Most recent kernel where this bug did not occur: none known Distribution: 2.6.16.16 Hardware Environment: Asus A8N5X Software Environment:Mandriva 2006, forcedeth ethernet driver This BIOS setting is relevant: BIOS -> POWER -> APM config -> Poweron by PCI devices=ENABLED description in BIOS is: Disable/Enable PME to wake up from S5 by PCI devices and NV onboard LAN. BIOS version 0902 Problem Description: Following poweroff from linux the computer will not respond to an WOL magic packet. When the same machine is powered off from Windows XP it responds to an WOL magic packet and wakes up normally. Things that were tried to enable WOL: ethtool -s eth0 wol g poweroff Donald' Becker's pci-config as: pci-config -#11 -S #executed immediately before /sbin/halt in /etc/rc.d/init.d/halt echo "MMAC" >/proc/acpi/wakeup poweroff None of these had any effect singly or in combination. Steps to reproduce: Install linux: (in this case, Mandriva 2006 2.6.12-12mdk) poweroff WOL fails Upgrade to kernel 2.6.16.9 or 2.6.16.16 poweroff WOL fails Boot to Windows XP during any of this Shutdown WOL works
Created attachment 8181 [details] lspci -xxx output following ethtool -s eth0 wol d
Created attachment 8182 [details] lspci -xxx output following ethtool -s eth0 wol g
Created attachment 8183 [details] cat /proc/acpi/wakeup (immediately following boot)
Created attachment 8184 [details] /var/log/dmesg I normally run with the nvidia driver for the graphics card. To demonstrate that this was not the problem this dmesg is from a boot (by necessity, "failsafe") where that module was not loaded. As before, following "poweroff" the computer did not WOL when it was hit with a magic packet.
Created attachment 8186 [details] .config used to build 2.6.16.16
Created attachment 8194 [details] output of acpidump built from pmtools-20051111
Please hack acpi_hw_enable_all_wakeup_gpes (hwgpe.c) to add some debug info to check exactly what gpes were enabled there. If Lan-wakeup-gpe was enabled , then mostlikey, this is not acpi driver issue. Thanks, Luming
I pulled a 3COM 3C905C-TXM card from another older linux machine that has WOL working and plugged it into the test machine. After adding the following line to /etc/modprobes.conf options 3c59x enable_wol=1 Rebooting, and then poweroff, the current machine would WOL when a magic packet was sent to this second ethernet card. A magic packet sent to the first ethernet port (the nvidia one) still did nothing. Oddly there didn't seem to be any new entries in /proc/acpi/wakeup, and the WOL worked even though everything in that file was set to disabled. So apparently it isn't ACPI per se that's screwed up. Perhaps this indicates a problem in the forcedeth driver instead? I'm still waiting for a serial port adapter cable so that I can do some kernel debugging. I had 2 of these cables, but both were for a different pin out than is present on the A8N5X.
One more bizarre observation. While there were two ethernet ports active in the machine there was only one ethernet cable available, so I had to keep moving that back and forth between the two. It turns out that unplugging the ethernet cable from the nvidia port (the one that won't WOL) causes the machine to start! It does that plus/minus the second card, and plus/minus a magic packet. In other words, as the machine/linux is now configured following poweroff unplugging the ethernet cord starts the machine. As far as I can tell there's no BIOS option that corresponds to: Power on when the ethernet cord is unplugged.
Summary: Magic packet to Nvidia (onboard ethernet) does WOL? Following XP shutdown: yes Following linux poweroff: no Following power application: no Magic packet to 3COM 3C905C-TXM adapter (in PCI slot) does WOL? Following XP shutdown: yes Following linux poweroff: yes Following power application: no Unplugging ethernet cable to Nvidia onboard port starts machine? Following XP shutdown: no Following linux poweroff: yes Following power application: no
What version of forcedeth are you using? Could you try the latest version (version 56)? Also, can you double check that the mac address you are sending the magic packet to is the forcedeth mac address?
It's forcedeth 0.49 which is what comes in the 2.6.16.16 kernel. Tell me where to find the latest version and I'll happily install it. (I just googled and couldn't find anything more recent than 0.49). The MAC being addressed is correct = remember it works to start XP on the same machine, and it's being run through a script every time so that I can't typo the number.
Created attachment 8241 [details] forcedeth version 56 Here is version 56, give it a try. Can you run "ethtool -d eth0" and send me the output?
Created attachment 8242 [details] output of: ethtool -d eth0, with forcedeth 0.49 Here is the output of "ethtool -d eth0" for forcedeth 0.49. I'll build 0.56 now and see what happens. Thanks
Created attachment 8243 [details] ethtool -d with forcedeth 056 after boot output of: ethtool -d eth0 following boot with forcedeth 0.56
Created attachment 8244 [details] ethtool -d with forcedeth 056 after ethtool -s eth0 wol g Same command as the preceding but shortly after doing: ethtool -s eth0 wol g
Unfortunately, no joy even with 0.56. This is what I did: cp /usr/src/linux-2.6.16.16/drivers/net/forcedeth.c ./forcedeth.c_v49 cp forcedeth.c_v56 /usr/src/linux-2.6.16.16/drivers/net/forcedeth.c cd /usr/src/linux make all make modules_install reboot It must be the new one loading since now there's a message from forcedeth in /var/log/messages at boot: using HIGHDMA ethtool -s eth0 wol g poweroff and WOL did not work. Tried this a couple of times and still WOL wouldn't work. Finally, as a positive control, rebooted to XP, did a shutdown, and voila, WOL worked. At that point booted to linux, verified that the lan was working (there had been problems reported about it not doing so following an XP boot, but I've not yet seen that problem). Then made the two ethtool -d attachments which precede this comment. Any other suggestions??? Thanks
Just on the off chance any of this is helpful, here are the forcedeth lines in /var/log/messages and a few around them (cut as a block, no lines in the block are missing). This is with the 0.56 forcedeth. Jun 2 14:05:00 saf05 kernel: NET: Registered protocol family 17 Jun 2 14:05:00 saf05 kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56. Jun 2 14:05:00 saf05 kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 Jun 2 14:05:00 saf05 kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 16 Jun 2 14:05:00 saf05 kernel: forcedeth: using HIGHDMA Jun 2 14:05:00 saf05 kernel: eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0 Jun 2 14:05:00 saf05 kernel: eth0: no link during initialization. Jun 2 14:05:00 saf05 kernel: eth0: link up. Thanks
Created attachment 8245 [details] forcedeth version 57 Can you give this version 57 a try? I believe the issue could be that the mac address is swapped when the forcedeth driver is shutting down. Or another way to check is to reverse the mac address in your script that sends the magic packet. i.e 00:01:02:03:04:05 becomes 05:04:03:02:01:00
I didn't get a chance to try the new forcedeth but you were correct, the MAC is reversed at shut down. I was able to get WOL to work with the 0.56 forcedeth by doing just: (boot) ethtool -s eth0 wol g poweroff (it wasn't necessary to "echo MMAC > /proc/acpi/wakeup" and the values in there didn't change after the ethtool command) and then on the remote machine send a magic packet to the reversed MAC address. I'll try forcedeth 0.57 when I can get back in on Monday. Thanks!!!
Unfortunately the forcedeth.c version 0.57 which was posted wouldn't compile. kernel 2.6.16.16 gcc version 4.0.1 These were the errors: drivers/net/forcedeth.c: In function 'nv_remove': drivers/net/forcedeth.c:4605: error: 'np' undeclared (first use in this function) drivers/net/forcedeth.c:4605: error: (Each undeclared identifier is reported only once drivers/net/forcedeth.c:4605: error: for each function it appears in.) drivers/net/forcedeth.c:4605: error: 'base' undeclared (first use in this function) drivers/net/forcedeth.c: At top level: drivers/net/forcedeth.c:4679: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_16' undeclared here (not in a function) drivers/net/forcedeth.c:4683: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_17' undeclared here (not in a function) drivers/net/forcedeth.c:4687: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_18' undeclared here (not in a function) drivers/net/forcedeth.c:4691: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_19' undeclared here (not in a function) drivers/net/forcedeth.c:4695: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_20' undeclared here (not in a function) drivers/net/forcedeth.c:4699: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_21' undeclared here (not in a function) drivers/net/forcedeth.c:4703: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_22' undeclared here (not in a function) drivers/net/forcedeth.c:4707: error: 'PCI_DEVICE_ID_NVIDIA_NVENET_23' undeclared here (not in a function) make[2]: *** [drivers/net/forcedeth.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Thanks
Created attachment 8258 [details] Forcedeth v57 with pci device ids Please try this file out. I fixed the missing pci device ids and compile errors.
Second forcedeth 0.57 compiled cleanly (as advertised) and fixes the WOL problem. Specifically, once this module is built and running on the system did: ethtool -s eth0 wol g poweroff The machine did WOL when a magic packet was sent to the correct MAC. (Reversing the MAC is not required for WOL.) In limited network testing (NIS, NFS, DNS running, and interactively just nosing around the web) no network errors were encountered. Looks good to me. THANKS!
It sounds like you have this one nailed, but I'll add one item of information in case it helps in some small way. I have a machine that exhibits this bug with FC5 (kernel 2.6.15 + driver 0.49, or kernel 2.6.18 + driver 0.56), but does not exhibit the bug with Mandriva 2006 (kernel 2.6.12 + driver 0.32). Driver 0.32 has different code to deal with the reversed MAC issue, but I didn't study it in detail -- I just noticed a change in that area when diffing 0.32 vs. 0.49. I'll try the patch...
moving report to drivers/network from ACPI closing b/c issue was resolved.
I still have this bug on a "MCP51 Ethernet Controller (rev a1)". Calling the WOL with the reversed MAC address is a workaround.
Can you try the latest forcedeth driver?
I have the 2.6.28 kernel, from archlinux. I guess it's the lastest forcedeth driver available? (sorry I didn't tell it earlier)
Can you send me the output of "ethtool -d ethX" when the interface is up and running?
sorry, I didn't come back and didn't get any warning about your reply. Here is the result of ethtool -d eth0: Offset Values -------- ----- 000: 00 00 00 00 ff 00 00 00 03 00 00 00 ca 03 db 02 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 020: 00 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 00 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 040: 0e e2 20 04 55 a4 00 00 20 2e 00 00 00 00 00 00 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 00 00 00 00 00 00 00 00 ff ff 00 00 070: ff ff 00 00 ff ff 00 00 ff ff 00 00 00 00 00 00 080: 3c 0f 3b 00 01 00 00 00 00 00 00 00 20 00 7f 00 090: 1c 06 00 00 01 00 00 00 00 00 00 00 1f 7f 00 80 0a0: 0f 07 16 00 16 00 00 00 00 15 58 45 91 27 00 00 0b0: 01 00 00 00 00 01 00 00 cd cc 00 ba 6e d9 00 00 0c0: 01 00 00 10 01 00 00 00 01 00 00 00 01 00 00 00 0d0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 0e0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 0f0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 100: 00 e8 3d 37 00 e0 3d 37 ff 00 7f 00 00 80 00 00 110: 64 00 01 00 00 00 00 00 0c 00 00 00 f0 ee 3d 37 120: 80 e1 3d 37 40 a4 65 34 eb ff 00 a0 10 b8 4b 34 130: 1c 06 00 80 fc ee 3d 37 ec e0 3d 37 00 80 e0 01 140: 20 41 30 00 00 22 c0 80 00 00 00 00 00 00 00 00 150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 180: 16 00 00 00 08 00 00 00 6d 79 94 01 03 81 00 00 190: 2a 00 00 00 00 40 00 00 6d 79 94 01 03 c1 00 00 1a0: 16 00 00 00 08 00 00 00 6d 79 94 01 03 81 00 00 1b0: 2a 00 00 00 00 40 00 00 6d 79 94 01 03 c1 00 00 1c0: 16 00 00 00 08 00 00 00 6d 79 94 01 03 81 00 00 1d0: 2a 00 00 00 00 40 00 00 6d 79 94 01 03 c1 00 00 1e0: 16 00 00 00 08 00 00 00 6d 79 94 01 03 81 00 00 1f0: 2a 00 00 00 00 40 00 00 6d 79 94 01 03 c1 00 00 200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 260: 00 00 00 00 00 00 00 00 01 00 02 fe 00 01 00 00 270: 00 00 00 00 00 00 00 00 01 00 02 fe 00 01 00 00 280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2d0: 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 2e0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 2f0: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 600: 00 00 00 00
It looks like there was a code change here that is causing the problem. It is reversing the address during shutdown: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=f55c21fd9a92a444e55ad1ca4e4732d56661bf2e cc'ing yhlu.kernel@gmail.com for comment
The fix has been submitted by http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=34edaa88324004baf4884fb0388f86059d9c4878