Latest working kernel version: None Earliest failing kernel version: 2.6.25 Distribution: OpenSuSE 11.0 /11.1A1 Hardware Environment: HP dv5-1004nr Software Environment:x86-64 Problem Description: System can suspend to ram but crashes when you try to resume Steps to reproduce: enter s2ram -fr system goes into suspend mode pressing the power switch to power up led's for caploc and numloc flash 2 times then pause and pattern repeats. System must be powered off for several minutes otherwise system thinks it's still suspended. Suspend to disk works correctly. Testing with OpenSuSE 11.1A1 with the 2.6.26 kernel and the 2.6.27-rc3-git4. ATI driver is not loaded.
Marked as a regression, reassigned to acpi.
(In reply to comment #0) > Latest working kernel version: None so s2ram never works on your laptop, right? > Earliest failing kernel version: 2.6.25 > Distribution: OpenSuSE 11.0 /11.1A1 > Hardware Environment: HP dv5-1004nr > Software Environment:x86-64 > Problem Description: System can suspend to ram but crashes when you try to > resume > > Steps to reproduce: > enter s2ram -fr > system goes into suspend mode > pressing the power switch to power up > led's for caploc and numloc flash 2 times then pause and pattern repeats. > > System must be powered off for several minutes otherwise system thinks it's > still suspended. sorry, I didn't understand. what will happen if system is not powered off for several minutes? > > > Suspend to disk works correctly. > Testing with OpenSuSE 11.1A1 with the 2.6.26 kernel and the 2.6.27-rc3-git4. > ATI driver is not loaded. >
When you power on, the caplock and numlock led start flashing the same pattern.
> Latest working kernel version: None so s2ram never works on your laptop, right?
Correct. Only s2disk works correctly. s2ram fails on restore.
clear the regression flag.
please boot with "acpi_sleep=s3_beep". run s2ram and check if you can hear the beep when resuming.
No beep heard when resuming.
I've seen this same issue on my dv5z, on a 2.6.26.3 kernel that I compiled myself. Also, s2disk isn't really right; when it resumes the video palette is not restored correctly. Anything beyond the first 256 colors is displayed with the wrong colors. HP dv5z, ZM-80, HD3450 graphics
Hi, Clark Will you please attach the output of acpidump? Thanks.
Created attachment 17460 [details] acpi dump acpi dump
Created attachment 17470 [details] try the custom DSDT Hi, Clark Will you please try the custom DSDT and see whether the suspend/resume can work on your laptop? how to use a custom DSDT can be found at: www.lesswatts.org/projects/acpi/faq.php As the acpi object related thermal is incorrect, please don't load the ACPI thermal driver(driver/acpi/thermal). thanks.
(In reply to comment #12) > Created an attachment (id=17470) [details] > try the custom DSDT > > Hi, Clark > Will you please try the custom DSDT and see whether the suspend/resume can > work on your laptop? Did you attach the right file? I disassembled this one and it looks identical to the original, aside from the compiler ID/version.
Hi, Howard thanks for pointing this problem. Yes, they are the same file. But when the custom DSDT is used, the content of the DSDT table will reside in the memory instead of ACPI NVS memory region. This is what I want to test. thanks.
What result are you expecting to see? I've been using a custom DSDT on my machine already, loaded from initramfs, to fix the thermal zone issue. (Bug 11421). It still fails to resume, with or without the thermal zone patches. Are you saying that the behavior will change if the custom DSDT is compiled into the kernel, instead of loading it off the filesystem?
I've also been using a modified dsdt to fix the thermal issue. I tried your dsdt and it failed. When you said 'custom', I thought you might have reworked the sleep/wake code sections. Too bad that bios do not follow the standards and coding rules.
Generally speaking, the DSDT used by ACPI will reside in the ACPI NVS memory region when the system is in running state. After the system enters the sleeping state, maybe the system can't be resumed correctly if the ACPI NVS memory region crashes. (One laptop has such a problem. The SSDT table crashed after the system is resumed.) Since the custom DSDT is already used on the system, there is no such issue. But the system still fails to be resumed. Maybe the issue is related with BIOS. Will you please confirm whether the windows can work on this laptop? Thanks.
Yes, on Windows Vista64 suspend works fine. Also, pressing any key wakes up the machine. With Linux, only pressing the power button or the Quickplay button wakes it up.
Vista 64bit does suspend and restore also.
I have the same issue, dv5-1000 cto, zm80, fedora9. tried latest kernel from rawhide (*27), same issue. computer suspends successfully with pm-suspend but does not resume; starting with solid but leaving flashing caps/scroll-lock. noticed very slight initial drive activity, did not appear to be the resume kind. attempted with vesa and fglrx drivers. did not attempt with windows vista.
Created attachment 17517 [details] try the debug patch Will you please try the debug patch and see whether the problem still exists? Thanks.
Created attachment 17519 [details] rejects had some rejects patching against 2.6.25
Will you please try the debug patch on the latest kernel 2.6.27-rc4?(Of course the 2.6.27-rc1/2/3 is also OK). Thanks.
(In reply to comment #23) > Will you please try the debug patch on the latest kernel 2.6.27-rc4?(Of > course > the 2.6.27-rc1/2/3 is also OK). > Thanks. > I tried it with 2.6.27-rc4. It still hangs on wakeup. Before, both the Caps and Numlock would stay lit; now they both light up but the Numlock stays lit and the Caps turns off after a couple seconds.
By the way, I see this in the dmesg log. Is there something that needs to be fixed here first? [ 17.808085] ACPI: I/O resource piix4_smbus [0xb00-0xb07] conflicts with ACPI region SMBI [0xb00-0xb0f] [ 17.808085] ACPI: Device needs an ACPI driver [ 17.808085] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 [ 17.808085] PM: Adding info for No Bus:i2c-0 or is it completely unrelated?
And another question - it seems to me that something else must not be succeeding in the preparation to sleep. In particular, why aren't the keyboard and mouse enabled for wakeup?
Using pm-suspend --vbe-post gets the display back on suspend. When I suspend from a text console, the text cursor is blinking on resume. But the keyboard is still not functional, and neither are the network interfaces, so I can't do much else. But pressing the power button again will cause an orderly shutdown, and all of the shutdown messages scroll by on the screen as usual.
Created attachment 17528 [details] dmes log from restore from ram numloc light on when restoring from ram. s2ram -fr was used to put the system to sleep. Crash information in log.
Created attachment 17529 [details] dmesg id as ascii id as ascii.
Howard, the S3 failure on your laptop is another problem, please file a new bug report and give a detailed description there. Clark, it seems that the kernel is back bug hang when resuming USB devices. So please compile ohci_hcd/ehci_hcd/uhci_hcd as modules, remove them before suspending and see if it can resumes.
Created attachment 17563 [details] suspend test with usb modules unloaded before suspend usb modules unloaded before suspend to ram. Numlock light is lit on restore. keyboard has no input and display is black. Dump of message log. No crash information found in the log.
Additional test. Changed the parameters from s2ram -fr to -f --vbe_post. Screen now visible and the wireless mouse works, but the keyboard is non responsive. numlock is lit and cannot be turned off without reboot.
(In reply to comment #30) > Howard, > the S3 failure on your laptop is another problem, > please file a new bug report and give a detailed description there. Hm, this laptop is nearly identical to Clark's; same chipset/motherboard/CPU, just that it has HD3450 graphics instead of HD3200. Or are you referring to the piix4 error message?
1. the black screen. an known issue, please use vbepost as a workaround. 2. network failure. a r8169 driver bug. please unload r8169 before suspend and reload it after resume. I think the network can work again. Now it seems that you're experiencing the same problem, i.e. keyboard doesn't work after resuming from S3, right? what keyboard are you using? if it a usb keyboard, it doesn't work because the usb driver is unloaded. If it's a PS2 keyboard, please try to use a usb keyboard, and run a script like the one below to test again? #!/bin/bash modprobe -r uhci_hcd; modprobe -r ehci_hcd; modprobe -r ohci_hcd; modprobe -r r8169; echo mem > /sys/power/state; sleep 1; vbetool post; modprobe uhci_hcd; modprobe ehci_hcd; modprobe ohci_hcd; modprobe r8169;
This is the laptop keyboard. No external keyboard is attached.
then what if you try a usb keyboard?
System will not suspend as ohci__hcd is in /etc/pm/conf.d/default. Why do you want a usb keyboard on a laptop? The keyboard controller is not being setup correctly when returning from s2ram.
A usb keyboard plugged in while the system is suspended will work when the system comes out of s2ram. My bluetooth mouse w/usb bluetooth dongle works, the gui works with the mouse, the usb keyboard works, the laptop keyboard does not work. Has the patch that you had us test been push into the kernel tree yet?
as the system can resume from S3 except the laptop keyboard, this seems like a serio problem rather than an ACPI issue. (In reply to comment #38) > Has the patch that you had us test been push into the kernel tree yet? > No. I only get the test result from Howard. Did you try this patch? Are these tests done with the patch applied? (In reply to comment #27) > Using pm-suspend --vbe-post gets the display back on suspend. When I suspend > from a text console, the text cursor is blinking on resume. But the keyboard > is > still not functional, and neither are the network interfaces, so I can't do > much else. is this done with or without the patch applied?
Created attachment 17573 [details] dmesg for suspend/resume Just for completeness sake, here's a log from my suspend/resume attempt, with the debug patch applied.
Tests were done with the patch.
I backported the patch to 2.6.25 and I can suspend to ram, but still have the issue where the laptop keyboard and touchpad do not work after restoring. I will be testing two other types of laptops later with this patch.
I should also add, that with the 2.6.25 kernel, I did not have to unload the usb modules.
okay, we have these issues here: 1. S3 resume failed -- fixed by the patch in comment #21 2. keyboard not work after S3 -- this seems like a serio problem rather than an ACPI issue. so let's focus on the first issue in this bug report, okay? Yakui and I will refresh the patch in comment #21 and try to push it upstream, while we still need some tests from you after the patch is refreshed. :) For the second issue, will you please open another bug and assign it to the serio category?
Hi, Clark&& Howard Will you please double check whether the system can be resumed if the patch in comment #21 is not applied? Of course the test method described in comment #34 is still required. thanks.
Suspend hangs on restore without the patch. Will the other group look at the keyboard issue if the patch is not in the tree?
With the patch for sleep, the only way to get the keyboard to work after saving to ram is to pass i8042.reset on the kernel boot line.
Cool, I was just about to try that. Still it makes no sense that we need to do this. My other computers wake up fine pressing any keyboard key. The fact that only the power buttons work here says that something else in the i8042 driver wasn't set properly during suspend.
Tried the patch on a GW ml-3109 laptop (2. 6.27-rc5). Was not able to suspend to ram with 2.6.26 and later kernels. This laptop will suspend, but on resume, hd light on and cpu never comes up and no information added to pm-suspend or the log file.
Also tried the patch on a hp dv6772 (AMD tl-64). Unable to restore from s2ram. Using s3_beep and you do get the beep tone. Both this system and the ml3109 are able to suspend and restore with the 2.6.25 kernel, but cannot with 2.6.26 and later. Also now I have to use the a3 option or the 6772 just reboots from s2ram.
(In reply to comment #47) > With the patch for sleep, the only way to get the keyboard to work after > saving > to ram is to pass i8042.reset on the kernel boot line. > Okay, please file a new bug and assign it to the serio category.
(In reply to comment #49) > Tried the patch on a GW ml-3109 laptop (2. 6.27-rc5). Was not able to > suspend > to ram with 2.6.26 and later kernels. This laptop will suspend, but on > resume, > hd light on and cpu never comes up and no information added to pm-suspend or > the log file. > that should be another story. will you please file another bug report and attach the dmesg in both 2.6.25/2.6.27-rc5? (In reply to comment #50) > Also tried the patch on a hp dv6772 (AMD tl-64). Unable to restore from > s2ram. > Using s3_beep and you do get the beep tone. Both this system and the ml3109 > are able to suspend and restore with the 2.6.25 kernel, but cannot with > 2.6.26 > and later. Also now I have to use the a3 option or the 6772 just reboots > from > s2ram. > sorry, what does a3 option stand for? did you use any boot parameters in 2.6.25?
Created attachment 17704 [details] patch: use 32 bit wakeup vector this is the patch for upstream. Mark it as resolved, will close it once it's upstream.
no boot parameters used. a3 was used with the s2ram command.. use both s3 bios and mode.
shipped in linux-2.6.28-rc1 closed commit a6629105dd03d370fcb31e97bddf223fa4bb651e Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Sat Sep 6 13:13:01 2008 +0200 ACPI suspend: Always use the 32-bit waking vector According to the ACPI specification 2.0c and later, the 64-bit waking vector should be cleared and the 32-bit waking vector should be used, unless we want the wake-up code to be called by the BIOS in Protected Mode. Moreover, some systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit waking vector is used. Therefore, modify the code to clear the 64-bit waking vector, for FACS version 1 or greater, and set the 32-bit one before suspend.