Kernel Bug Tracker – Bug 12684
Toshiba L355 will suspend/resume once, but after a second suspend, won;t resume
Last modified: 2010-06-27 23:47:19 UTC
Latest working kernel version: Unknown
Earliest failing kernel version: Unknown
Hardware Environment: Toshibe Satellite L355-S7812
Software Environment: Mandriva Cooker
Problem Description:After a suspend/resume, and a second suspend, the machine refuses to resume.
See http://marc.info/?l=linux-acpi&m=123421014421021&w=2 for some more info, aswell as http://bugzilla.kernel.org/show_bug.cgi?id=12641 for another acpi problem with attachments
Steps to reproduce:
reassigned to acpi
what if you do the suspend/resume in console mode?
Seems not....i logged out,
switched to vt1,
logged in as root,
did 'service dm stop' to stop X.
echo mem > /proc/power/state
It went to sleep
Then i woke it up, and it still took a long time, so the long wake up time can't be X related.
I put it back to sleep
Then, it wouldnt wake up (the power led comes on, but thats all) and i had to hold down the power to get it turned off.
please echo core > /sys/power/pm_test, and run echo mem > /sys/power/state,
wait for about 10 seconds, does the system come back?
do this test for several times in a row, can the system come back?
if yes, run this test after the first suspend/resume, can the system come back?
please attach the dmesg output after these tests.
i dont have /sys/power/pm_test
You need to enable CONFIG_PM_DEBUG for it to appear.
please verify if the problem can be reproduced in 2.6.27
sorry for the delay...just built a custom kernel and done the test above. tried 4 times, and yes, the system comes back after approx 10 seconds
Created attachment 20414 [details]
dmesg after core pm test 1
Created attachment 20415 [details]
dmesg after core pm test 2
there are a lot of error messages about the X/drm driver.
please boot into console mode. make sure drm driver is not loaded
and check if the problem still exists.
Note that in console mode, the screen may not come back after resume.
But if you can login via network, and system runs okay, then this is a successful suspend/resume cycle.
ping Adam. :)
close the bug as there is no response from the bug reporter.
please re-open it if the bug still exists in the latest upstream kernel
and you can provide the info requested in comment #13.
How do i stop the drm driver loading? Now on kernel 18.104.22.168, using kms etc.
Would it be best to boot into runlevel 3 with i915.modeset = 0?
Created attachment 25731 [details]
List of modules with no drm, 1st boot
Created attachment 25732 [details]
dmesg of 1st boot with no drm
Created attachment 25733 [details]
list of modules with no drm, 2nd boot, after sleep
Created attachment 25734 [details]
dmesg of 2nd boot, after sleep, with no drm
So i think ive dont the test you asked for,
I blacklisted the drm module, stopeed i915 from being loaded and booted with 'nomodeset i915.modeset=0 3'
I got the list of modules and dmesg output as attached (.1) and put the system to sleep with 'echo mem > /sys/power/state'
Booed up again, and as you said, the screen didnt come back. But, after about a minute, i could tell the system was running, as i could type commands in and see disk activity, and pressing backspace caused the pc speaker to beep. At this point i got the module list and dmesg again as attached (.2).
Note, it took about a minute to start to respond, just like before.
I put the system to sleep.
Again, as before, the system wouldnt respond after the second boot. I left it about 10 minutes, but got nothing, so its probbaly not drm related.
This was using 'acpi_osi="!Windows 2006" acpi_osi="!Windows 2006 SP1", as you know from the other bug.
in 2.6.33, does the error messages still exist if you don't use nomodeset?
does the screen come back after the first resume with KMS?
I was only able to boot to runlevel 3 using nomodeset. Using KMS, the screen just went blank when the mode got changed.
In this setup, i had i915 + drm loaded.
It went to sleep the first time, and resumed (after ~1min), and the screen came back also.
Second time, wouldnt come back up.
Attached the output of lsmod and dmesg for the 1st and second sessions.
Created attachment 25751 [details]
lsmod from runlevel 3, nomodeset, 1st boot
Created attachment 25752 [details]
dmesg from runlevel 3, nomodeset, 1st boot
Created attachment 25753 [details]
lsmod from runlevel 3, nomodeset, 2nd boot
Created attachment 25754 [details]
dmesg from runlevel 3, nomodeset, 2nd boot
can you please apply the patches
on top of the latest upstream kernel and see if they help?
thanks for that!
words cannot describe just how much better that is! not only does is sleep/resume many times (tried about 6 in under a minute), but it also resumes instantly, no more waiting ~60 seconds
I built it from kernel 2.6.35-rc2 .... the patches didnt apply cleanly against 2.6.34,
If only the kernel i built could obtain an IP address over wifi, i mustnt have it configured properly,
great news. thanks for testing.
Another machine that need to save/restore NVS for S3.
I think Len will ship them in acpi tree soon.
Hi, is there any chance of getting a patch for this agains 2.6.34 as i cant get 2.6.35-rc to work with wifi.
When do you think this will get into the mainline?
This is set to enter mainline very soon.
About wireless, you did select intel wireless 3945 in Kconfig?
Does wireless led blink?
Try to do
sudo ifconfig wlan0 promisc
And then try to associate.
If the above works, revert 3474ad635db371b0d8d0ee40086f15d223d5b6a4.
yes the driver is built, and it associates, but dhclient never gets an address. I can pastebin the messages later as I'm on my phone atm.....i'll also try rc3 as I see it is out now
In this case you surely hit the same regresion.
I also own an iwl3945.
Just revert 3474ad635db371b0d8d0ee40086f15d223d5b6a4.
sudo ifconfig wlan0 promisc
Its not fixed in rc3
Fix for this bug in now upstream.