suspend-to-ram hangs on HP NX7010

DISCUSSION Pierre Ossman 3 participants 6 messages Jun 9, 2004 – Jun 19, 2004 4 messages not in the archive ACPI

Share & tools

Pierre Ossman

author

2004-06-09 12:06 UTC #0 lore raw

Hi!

I've been spending a few days trying to get suspend-to-ram to work on my new HP NX7010 laptop. Haven't had much success though so I thought I might get some help from the more experienced.

I'm running FC2 with linux 2.6.6. S3 has been tested using vanilla kernel and with the patch from acpi.sf.net. I've also included a patch from the ACPI bugzilla to be able to control which devices can wake the unit. The behaviour has been the same for all tests.

I don't think the unit actually gets all the way into S3 though. If I turn on ACPI debug in the kernel I can see a debug message that says 'Entering S3' but the laptop doesn't power down anything. After this point the only way to get control of the machine again is to hold down the power button for a couple of seconds, bypassing the OS. Also, for some strange reason I have to do this twice because the machine hangs during POST after the first reset (after a failed suspend-to-ram that is, works fine otherwise).

I've started looking in the ACPI spec. since I suspect the bug might be in the DSDT. I doesn't even compile cleanly with Intel's compiler as it is. ACPI is new to me however so I could use some pointers on where I should start looking. I'm also fluent in C so I intend to have a look at the kernel code and insert some debug statements. Might help me pinpoint where it hangs.

I'd appreciate any help I can get. Just tell me what information you need and what I should test and I'll gladly do it. Suspend-to-ram is a badly needed function so I'm ready to devote whatever time is required to get this fixed.

Regards
Pierre Ossman

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

A message that is not in the archive (sent off-list or not yet received): [email protected]

Pierre Ossman

2004-06-14 22:58 UTC #2 lore raw

Some updates.
I've been fiddling around with this during the weekend but haven't made much progress. Removing all modules, in case they were causing problems, didn't help.
I have, however, pinpointed where in the kernel it hangs. It stops while writing the SLP_EN bit. I guess that's where it should actually go into sleep mode. The bit is set in two registers but the hang is when it writes the first one. Changing the order of them still causes the first one to hang (B in that case). I also tried combining SLP_TYPx and SLP_EN but again, hang during the first write. I'm out of ideas now so I *really* need some tips on what to try next. There is nothing more to debug around the crash-point so the problem must be somewhere during the preparation.

Rgds
Pierre

A message that is not in the archive (sent off-list or not yet received): [email protected]

Pierre Ossman

author

2004-06-16 12:36 UTC #4 lore raw

Quoted 2 lines · Pierre Ossman

I have, however, pinpointed where in the kernel it hangs. It stops while writing the SLP_EN bit. I guess that's where it should actually go into sleep mode. The bit is set in two registers but the hang is when it writes the first one. Changing the order of them still causes the first one to hang (B in that case). I also tried combining SLP_TYPx and SLP_EN but again, hang during the first write. I'm out of ideas now so I *really* need some tips on what to try next. There is nothing more to debug around the crash-point so the problem must be somewhere during the preparation.

I can also point out that when suspending to S4 or S5 the machines powers off after the first write (where it hangs during S3).

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

Pierre Ossman

author

2004-06-18 19:56 UTC #5 lore raw

In reply to a message not in the archive

I've updated to linux 2.6.7 and applied the acpi patch for it. The behaviour is now a bit different. When trying to suspend (echo 3 > /proc/acpi/sleep) I now get the following:

PM: Preparing system for suspend
Stopping tasks: ===================================================================================================|
PCI: Setting latency timer of device 0000:00:1d.7 to 64
Could not suspend device 0000:00:1d.7: error -5
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.5 to 64
Restarting tasks... done

Device 0000:00:1d.7 is the USB 2 controller. If I remove the ECHI module the behaviour is as previously (i.e. locks up).
I don't know if this is a new bug in the EHCI module or if this is the source of all the problems on this machine. I do not know enough of how things work at that level to determine if the USB controller could prevent the standby. The BIOS doesn't have an option to turn of USB so I can't try it with the hardware disabled.
Any ideas?

Rgds Pierre

A message that is not in the archive (sent off-list or not yet received): [email protected]

Michael Frank

2004-06-19 03:29 UTC #7 lore raw

Quoted 14 lines · Pierre Ossman

I've updated to linux 2.6.7 and applied the acpi patch for it. The behaviour is now a bit different.
When trying to suspend (echo 3 > /proc/acpi/sleep) I now get the following:
PM: Preparing system for suspend
Stopping tasks:
===================================================================================================|
PCI: Setting latency timer of device 0000:00:1d.7 to 64
Could not suspend device 0000:00:1d.7: error -5
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1f.5 to 64
Restarting tasks... done

Quoted 10 lines

Device 0000:00:1d.7 is the USB 2 controller. If I remove the ECHI module the behaviour is as previously (i.e. locks up).
I don't know if this is a new bug in the EHCI module or if this is the source of all the problems on this machine. I do not know enough of how things work at that level to determine if the USB controller could prevent the standby.
The BIOS doesn't have an option to turn of USB so I can't try it with the hardware disabled.
Any ideas?

Oh, how nice, it looks like progress with the drivers when it dies wo one ;)

Seriously, please try again with init=/bin/bash and then add drivers in multiuser mode until you find the culprit.

Also ACPI modules may have to be removed.

Regards
Michael

A message that is not in the archive (sent off-list or not yet received): opr9tnzbol4evsfm-TBR8pM7LtsqkE96DxU8f+dAkNl5+tjhE@public.gmane.org

Pierre Ossman

author

2004-06-19 07:23 UTC #9 lore raw

Quoted 7 lines · Michael Frank

Oh, how nice, it looks like progress with the drivers when it dies wo one ;)
Seriously, please try again with init=/bin/bash and then add drivers in multiuser mode until you find the culprit.
Also ACPI modules may have to be removed.

Tried this. Booting up with only bash gives me a single module loaded (xfs). Trying a suspend at that point results in a hang. Loading the USB 2 module results in the error.

Rgds
Pierre