Help request on S3 resume problems

Help request on S3 resume problems

[David Giddy]

Hi,

I'm relatively new to ACPI and am having problems trying to get wake on LAN 
working from S3. I have managed to successfully get the machine to resume from 
S3 using the power button, and also to get the machine to wakeup using a magic 
packet, but not to a working state.

The machine is a small server running Debian Sarge with kernel version 
2.6.16.16 and the corresponding ACPI patch set. It has two Gigabit LAN ports 
(one on the motherboard - a Realtek 8110 and the other an Intel PRO 1000/MT 
PCI card). The e1000 driver has been patched according to bugzilla bug 5609.

The symptoms are that I put the machine to sleep 
(echo -n mem >/sys/power/state), send it a magic packet, the machine comes to 
life but there is no screen, no keyboard response and no response to ping. It 
seems to be off with the fairys.

The video card is Nvidia, but I have used the latest nvidia drivers (version 
1.0-8756), and these work fine for resume from S3 using the power button.

The one question mark I have is that /proc/acpi/wakeup has the following 
entries:

Device	Sleep state		status
PCI0			4		enabled
HUB0			4		enabled
USB0			3		disabled
USB1			3		disabled
USB2			3		disabled
USB3			3		disabled
USBE			3		disabled

Given I am trying to wake from S3, is this correct ? Do I need to/is it 
possible to change the wakeup state to S3 for the PCI0/HUB0 lines ? Note that 
enabling PCI0 enables HUB0 as well (not sure what the latter actually is, but 
there is a message saying that they share the same GPE).

Any suggestions on what's going on and how to fix it would be appreciated.

Regards,

David.
 

RE: Help request on S3 resume problems

[Brown, Len]

I expect that the method to wake the system
and the fact that resume from S3 fails
are independent problems.

Likely you can use WOL from S5 and the system
will boot normally from poweroff.  (same can
be said for suspend-to-disk -- S4).

Likely you can wake the system from S4/S5 via
power or sleep button, and it will fail the same
way as it fails via WOL.

The way to debug an S3 resume with no video
is to use a serial or a firewire console.

-Len

RE: Help request on S3 resume problems

[David Giddy]

Len,

Thanks for the quick response. Unfortunately, I think in this instance that
the failure on resume IS related to the method of waking. Here are the
results of testing as you imply below:

Resume from S3 using power button	  -> 100% functional, both ttyS0 serial
console and NVIDIA video card console
Resume from S3 using WOL magic packet -> Fans run, disk activity, NO NVIDIA
video card console response, NO ttyS0 serial console response, NO ping
response
Resume from S5 using power button	  -> Normal boot
Resume from S5 using WOL magic packet -> Normal boot

I haven't tried wake from S4 as I don't currently have a swap partition
large enough to try it (1GB RAM).

Regards,

David.


-----Original Message-----
From: linux-acpi-owner@vger.kernel.org
[mailto:linux-acpi-owner@vger.kernel.org]On Behalf Of Brown, Len
Sent: Tuesday, 16 May 2006 4:35 PM
To: David Giddy; linux-acpi@vger.kernel.org
Subject: RE: Help request on S3 resume problems


I expect that the method to wake the system
and the fact that resume from S3 fails
are independent problems.

Likely you can use WOL from S5 and the system
will boot normally from poweroff.  (same can
be said for suspend-to-disk -- S4).

Likely you can wake the system from S4/S5 via
power or sleep button, and it will fail the same
way as it fails via WOL.

The way to debug an S3 resume with no video
is to use a serial or a firewire console.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Help request on S3 resume problems

[Andreas Saur]

Hello,

same here! (nForce2 chipset).

After many many trial and error scenarios, I cannot remember exactly what I've done to get it work (resume from s3 on WOL) at least partitially.

1) In a sort of combination of using X86_UP_IOAPIC with USB turned off in BIOS, the system always woke up after sending the magic packet.
2) After turning on USB in BIOS the system woke up exactly 3 times. The forth time always led to a dead keyboard and a black screen, no ping.
3) Turning off X86_UP_IOAPIC in the kernel leads always to a dead keyboard and black screen, no ping.

Except WOL, S3 works fine here using the PowerButton or Keyboard.

I've studied all the the logs I've turned on in kernel, but there is nothing of interest concerning this error, at least for me.
Btw. It didn't make a difference whether doing the test in single user mode or not. Results were the same. I've also turned off all devices I could in the BIOS to minimize the IRQ impact. Didn't make a difference either.

It's a pitty, I was so close to a very cool MediaCenterPC for my living-room. But at the moment I ran out of ideas. If anybody is interested in my specs, can look into a bugzilla report I've posted earlier (another problem), the hardware didn't change, except the kernel. It's 2.6.17-rc3 at the moment. the last three mm patches led to kernel panics. (here my specs: http://bugzilla.kernel.org/show_bug.cgi?id=6326)

Regards,

Andreas

>Len,
>
>Thanks for the quick response. Unfortunately, I think in this instance that
>the failure on resume IS related to the method of waking. Here are the
>results of testing as you imply below:
>
>Resume from S3 using power button	  -> 100% functional, both ttyS0 serial
>console and NVIDIA video card console
>Resume from S3 using WOL magic packet -> Fans run, disk activity, NO NVIDIA
>video card console response, NO ttyS0 serial console response, NO ping
>response
>Resume from S5 using power button	  -> Normal boot
>Resume from S5 using WOL magic packet -> Normal boot
>
>I haven't tried wake from S4 as I don't currently have a swap partition
>large enough to try it (1GB RAM).
>
>Regards,
>
>David.

RE: Help request on S3 resume problems

[David Giddy]

Andreas,

Thank you for the pointers below. This seems to have solved my problem!
Enabling X86_UP_IOAPIC was sufficient in my case for success (it seems to
work OK with USB enabled in the BIOS - haven't tried with connected USB
devices yet though...)

Interesting that my hardware is quite different to yours, yet the symptoms
were the same:
- Gigabyte GA-8IPE1000-G motherboard (Intel 865PE chipset)
- Realtek 8110 Gigabit LAN chip on board
- Intel PRO1000/MT PCI card
- NVIDIA AGP video card
- Debian Sarge with kernel 2.6.16.16 latest ACPI patch set(with NVIDIA
driver added and an e1000 module WOL patch)

Maybe something around the code related to X86_UP_IOAPIC needs looking at by
ACPI experts ? Unfortunately I don't understand the kernel anywhere near
well enough to help.

Works successfully with both on board and PCI LAN interfaces and now works
from both S3 and S4 (using swsusp2).

One happy camper!

Regards,

David.


-----Original Message-----
From: linux-acpi-owner@vger.kernel.org
[mailto:linux-acpi-owner@vger.kernel.org]On Behalf Of Andreas Saur
Sent: Saturday, 20 May 2006 10:13 AM
To: linux-acpi@vger.kernel.org
Subject: RE: Help request on S3 resume problems


Hello,

same here! (nForce2 chipset).

After many many trial and error scenarios, I cannot remember exactly what
I've done to get it work (resume from s3 on WOL) at least partitially.

1) In a sort of combination of using X86_UP_IOAPIC with USB turned off in
BIOS, the system always woke up after sending the magic packet.
2) After turning on USB in BIOS the system woke up exactly 3 times. The
forth time always led to a dead keyboard and a black screen, no ping.
3) Turning off X86_UP_IOAPIC in the kernel leads always to a dead keyboard
and black screen, no ping.

Except WOL, S3 works fine here using the PowerButton or Keyboard.

I've studied all the the logs I've turned on in kernel, but there is nothing
of interest concerning this error, at least for me.
Btw. It didn't make a difference whether doing the test in single user mode
or not. Results were the same. I've also turned off all devices I could in
the BIOS to minimize the IRQ impact. Didn't make a difference either.

It's a pitty, I was so close to a very cool MediaCenterPC for my
living-room. But at the moment I ran out of ideas. If anybody is interested
in my specs, can look into a bugzilla report I've posted earlier (another
problem), the hardware didn't change, except the kernel. It's 2.6.17-rc3 at
the moment. the last three mm patches led to kernel panics. (here my specs:
http://bugzilla.kernel.org/show_bug.cgi?id=6326)

Regards,

Andreas

>Len,
>
>Thanks for the quick response. Unfortunately, I think in this instance that
>the failure on resume IS related to the method of waking. Here are the
>results of testing as you imply below:
>
>Resume from S3 using power button	  -> 100% functional, both ttyS0 serial
>console and NVIDIA video card console
>Resume from S3 using WOL magic packet -> Fans run, disk activity, NO NVIDIA
>video card console response, NO ttyS0 serial console response, NO ping
>response
>Resume from S5 using power button	  -> Normal boot
>Resume from S5 using WOL magic packet -> Normal boot
>
>I haven't tried wake from S4 as I don't currently have a swap partition
>large enough to try it (1GB RAM).
>
>Regards,
>
>David.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html