Bug 1636

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?