Distribution: Debian unstable Hardware Environment: Athlon XP 2500+, Abit NF7-S (nforce2 chipset) Software Environment: Debian unstable, 2.4.22 stock kernel Problem Description: System doesn't respond to magic packets (ether-wake) after power down from Linux. Briefly turning the system on and immediately off restores Wake-on-LAN functionality. This behaviour is similar when using a tained kernel (nvnet, yes I know...) or without a network device driver loaded. Steps to reproduce: Buy motherboard with proprietary driver support ;) Build kernel from 2.4.22 source, boot, turn machine off (halt first), send magic packets over lan cable from another computer with ether-wake.
Created attachment 1605 [details] dmesg-s40000.txt
Created attachment 1606 [details] dmidecode.txt
Created attachment 1607 [details] acpidmp.txt
Created attachment 1608 [details] lspci-vv.txt
Created attachment 1609 [details] cat-proc-interrupts.txt
Does this procedure work if you use a non-ACPI kernel? Do you know of any revision of the ACPI-enabled kernel where this has worked? Any reason you're using a 2.4.22 kernel? FYI, we publish a patch with the latest ACPI against 2.4.22 here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.22/ Or it might be good to simply upgrade to 2.4.23. Poweroff is slightly different in 2.6, so it might be good to test that too. I've never used WOL. How do you send a WOL packet? Seems like it has nothing to do with the actual NIC Linux driver, but by chance I happen to have an nforce2 box with this NIC. When the baseline kernel didn't recognize it I simply plugged in an e100;-) Can you point me to where to get the driver you're using? thanks, -Len
> Does this procedure work if you use a non-ACPI kernel? > Do you know of any revision of the ACPI-enabled kernel where this has worked? Kernels I have tried are: 2.4.22, 2.4.23 and 2.6.0-test11. Arguments I have passed to the kernel: noapic, apci=off In case you are referring to PM > APM, my box will not power down with APM built-in, even though I turned on using the BIOS call for power off. As you understand, if a computer doesn't power down (you have to manually turn it off) it is pretty hard to wake it up using magic packets :) I had hopes for noapic, but acpi=off more or less yielded the same situation as using APM. Where WOL is concerned, functionality seems to be the same for these kernels. I will triple check and let you know. I have also tried a patch to 2.6.0-test11 sent to me by Emmanuel Thome. There is no author, but it adds /proc/acpi/wakeup_devices - he suggested that echo'ing a string to wakeup_devices fixed an issue for him with ACPI and S3 (echo LID > wakeup_devices). The patch can be found here, just like all the stuff I have been collecting about this thus far (kernel trees excluded): http://vengeance.et.tudelft.nl/~sphere/acpi-bug/wakeup.patch.gz NOTE: I didn't choose acpi-bug because I know it is a bug in ACPI, that was just mere guessing on my part and I had to start somewhere. > Any reason you're using a 2.4.22 kernel? > FYI, we publish a patch with the latest ACPI against 2.4.22 here: > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.22/ > > Or it might be good to simply upgrade to 2.4.23. > Poweroff is slightly different in 2.6, so it might be good to test that too. No particular reason, I downloaded 2.4.22 and the next day 2.4.23 was released. Woops. > I've never used WOL. How do you send a WOL packet? Ah. David Becker, the guy from Scyld, Beowulf and realtek drivers (etc) wrote a nice little program called etherwake that sends a magic packet. If you wanted, you can read more about it here, although I don't know if magic packets actually originate from AMD: http://www.amd.com/us- en/ConnectivitySolutions/TechnicalResources/0,,50_2334_2481,00.html > Seems like it has nothing to do with the actual NIC Linux driver, > but by chance I happen to have an nforce2 box with this NIC. > When the baseline kernel didn't recognize it I simply plugged in an e100;-) > Can you point me to where to get the driver you're using? Let me stress that I have tried this with and without drivers for the NIC. Simply because I have thusfar gotten to page 130 of the ACPI standard, and I haven't really figured out if you need a device driver to enable ACPI-related stuff on devices. NOTE: the nvidia driver for Windows has a drop-down box where you can enable/disable WOL. I have emailed nvidia about this and they have not responded yet. Forcedeth, reverse-engineered GPL driver for the NIC: http://www.hailfinger.org/carldani/linux/patches/forcedeth/ 2.4 patch: http://www.hailfinger.org/carldani/linux/patches/forcedeth/ 2.6 patch: http://www.hailfinger.org/carldani/linux/patches/forcedeth/forcedeth_2_6_patch_v 18.txt Non-free, binary nvidia driver, probably nvidia custom license: http://download.nvidia.com/XFree86/nforce/1.0-0261/NVIDIA_nforce-1.0-0261.tar.gz README for the drivers: http://download.nvidia.com/XFree86/nforce/1.0- 0261/ReleaseNotes_Linux_nForce_1.0-0261.html
Len, Hunting for some more information I found this: http://gsd.di.uminho.pt/jpo/software/wakeonlan/mini-howto/ In this howto is a useful link with lots of information about debugging stuff with regards to WOL: http://www.scyld.com/diag/index.html I'm still in the dark, whether a device driver is actually required to enable the WOL functionality. Can you comment on this? A brief reply from nvidia learned that the linux driver does not support WOL, but a "future release" may support it. If a driver is indeed necessary, maybe we have to start warming up the forcedeth crew? Kind regards, Arjen
Len, I have good news and bad news. The good news is that now have a working solution for enabling Wake-on-LAN after Power down. from Linux and it works with all 2.4.22-nvidia, 2.4.23-forcedeth and 2.6.0-test11-forcedeth. The bad news is that is really ugly and then some... My box runs Debian sid. On the scyld page I found a nice little program that can force D3 power state: http://www.scyld.com/diag/index.html ftp://ftp.scyld.com/pub/diag/pci-config.c NOTE: pci-config does NOT compile with gcc-3.3.2 on Debian sid. It does compile with gcc-2.95. Compile it with: gcc-2.95 -O pci-config.c -o pci-config I was fiddling with two consoles, where I entered halt in one, and after an arbitrary delay pci-config -S -#12. I swear that it worked at least 1 out of 12 times ;) The biggest downside is that sometimes the system hangs, and most of the time will not respond to Wake-on-LAN magic packets. I figured out that with the network up and the nic-module in the kernel, the box would hang. After ifdown eth0 I could just do as I please, putting the chip to sleep and waking it up again. Same for no module inserted at all. None of these situations enabled me to wake the box up again however. Still, I was convinced that it had worked at least one time. I decided to add a job to /etc/rc0.d so I could systematically find the sweetspot. The sweetspot is between S20sendsigs (where all processes are send the TERM and then the KILL signal by killall5) and S35networking (as far as I can tell only ifdown -a happens here). Before S20sendsigs the box will just hang and after S35networking the box does not respond to magic packets. barton:/etc/rc0.d# cat S21D3NIC #! /bin/sh echo "Putting NIC to D3 state -- FIXME!!!" /home/sphere/media/pci-config -S -#12 | grep Power /home/sphere/media/pci-config -a -#12 | grep Power With the help of lspci, cat /proc/pci and ./pci-config -a -#<#> for every device number listed by ./pci-config -a I figured out that device 12 was my nic. I hope this information can be useful to you in trying to figure out how to solve this problem in a clean way. Maybe the forcedeth driver could set the D3 state? I have no idea how the ACPI standard prescribes this should be implemented. The only puzzling thing to me at this moment is how the driver is connected to my solution. I will look into that some more, but this will probably be after the weekend. Best regards, Arjen
It seems I may have been too optimistic. The box still hangs occasionally after setting the power state of the NIC to D3, but a lot less than doing it by hand. Nonetheless I'm still happy, because it looks like this issue could be resolved some way or another. Kind regards, Arjen
Len, a small update: I have been using the little power down script I wrote with the forcedeth driver successfully for the last week. According to one Nvidia employee, their nvnet driver has functionality to enable WOL. Unfortunately though, this feature doesn't do its magic on my Abit. Seeing how there have no hiccups for the last 25 odd times that I used WOL, it might be a good idea to start thinking of a more permanent solution. Could you please comment on the following: - Is changing a powerstate of a device the job of the driver or not? - If it is: should the ACPI in the kernel trigger device drivers to change a power state, or are drivers supposed to do this independently? - If it isn't, I'll wait patiently until the laptop people stop complaining about their petty problems :P This info could be useful, if the next step should be to harrass the Forcedeth people :) Thank you for your effort.
lspci: 00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) is this device in the DSDT: Device (MMAC) { Name (_ADR, 0x00040000) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) } Which should be able to wake up the system from as deep as S5. does it make any difference if in 2.6.9 if you "echo MMAC" >/proc/acpi/wakeup_devices before you power off?