Bugzilla – Bug 257356
s2ram double suspend on Thinkpad z61p
Last modified: 2007-04-03 07:18:03 UTC
On a thinkpad z61p a s2ram via the hot key Fn+F4 often causes a "double suspend". Issuing the s2ram command line works fine as far as a single suspsend/resume. The first suspsend often works as it should, but subsequent suspends without a reboot in between will suspsend correctly, then resume, but then immediately trigger a second suspend. It will then resume correctly from the second suspend. To debug, I hacked up the PM scripts a bit so that the /var/log/pm-suspend.log is appended to on every suspend rater than deleted and started a new each time. Then by adding debug statements to the /etc/pm/functions scripts, I was able to ascertain that the /etc/pm/functions function pm_main was being called twice. I added echo statements to the begining of pm_main right after the exec call that redirects to the log file to state when suspend began. I also added statemtns before every major step and one at the very end before the exit to indicate completley done. In the log, I see two sequential calls to pm_main. I'm not sure whats calling pm_main, so I couldnt debug further. For now, I've hacked it such that it will only allow 1 suspend per minute, but this is hardly ideal. Here are the levels (latest from suse updates): powersave-0.15.11-0.2 pm-utils-0.20.0.20061114-5.2 suspend-0.50-6 dbus-1-1.0.0-7 hal-0.5.8_git20061106-31.1 kernel: 2.6.18.8-0.1-default s2ram -n : Machine is unknown. This machine can be identified by: sys_vendor = "LENOVO" sys_product = "9453CQU" sys_version = "ThinkPad Z61p" bios_version = "7FET91WW (2.09 )" The -f (force) parameter was added to the s2ram options in order for it to suspend even though the system is not on the white list from being so new.
Please attach output of 'lshal -m' while pressing the Fn+F4 and if it's possible also immediately before the second suspend, please attach also output of 'lspci -vvn'. What version of acpid do you have?
Running acpid-1.0.4-53 - latest that seems available throught the update streams. To get the lspci at the times you wanted I integrated it into my /etc/pm/functions along with the changes I made so the log is appended to on each suspend rather than creating an entirely new file. I will attach that file in just a second here, so please note that this log contains both suspends back to back with the lspci output at the top of each suspend. The one you asked for is in the middle of the file at the top of the second suspend. Here is the lshal -m output from the Fn+F4 through the second resume: platform_i8042_i8042_Kbd_Port_logicaldev_input condition ButtonPressed = wake-up acpi_SLPB condition ButtonPressed = sleep acpi_BAT0 property battery.voltage.current = 12440 (0x3098) usb_device_483_2016_noserial_if0 removed usb_device_483_2016_noserial_usbraw removed usb_device_483_2016_noserial removed usb_device_483_2016_noserial added usb_device_483_2016_noserial_if0 added usb_device_483_2016_noserial_usbraw added computer_logicaldev_input condition ButtonPressed = brightness-down usb_device_483_2016_noserial_usbraw removed usb_device_483_2016_noserial_if0 removed usb_device_483_2016_noserial removed usb_device_483_2016_noserial added usb_device_483_2016_noserial_if0 added usb_device_483_2016_noserial_usbraw added computer_logicaldev_input condition ButtonPressed = brightness-up
Created attachment 127891 [details] pm-suspsend log with append each suspend and lscpi pm-suspend.log from edits scripts to append rather than replace on each suspend and lspci at the top of each suspend.
Thank you. From the logs is not clear what is causing the second suspend. Therefore, could you please attach /var/log/pm-suspend.log, /var/run/pm-suspend and try to suspend to disk "by hand" by executing 'powersave -U'?
Created attachment 128249 [details] pm-suspend.log via powersave -u
Created attachment 128252 [details] pm-suspend run with powersave -u
Executing powersave -u (i assumed you meant little u - suspend to ram rather than big U) actually doesnt see the issue. It correctly suspended and resumed only once. Anyway, I have attached the log files requested. Note the pm-suspend.log file still contained the aforementioned hacks to the scripts to append and do lspci.
Even though this is on 10.2, could this be a duplicate of Bug#259666?
It looks like the problem is more pervasive than just my z61p. I just powered up my T60 which hasnt been on since early January and it didnt show the double suspend issue. I then ran the updater on the T60 to pull down all the latest updates and it now suffers the same double suspend issue. I'm guessing the problem is in one of the recent updates (last month or two) that caused this and that update is likely in the 10.3 development stream. Sounds like Bug#259666 is a duplicate.
*** This bug has been marked as a duplicate of bug 259666 ***