Kernel Bug Tracker – Bug 16252
Since 2.6.35-rc2 suspend to ram is very shaky
Last modified: 2010-07-08 23:05:40 UTC
This bug is a clone of 16179 to deal with the regression that suspends often hangs now.
+++ This bug was initially created as a clone of Bug #16179 +++
Subject : 2.6.35-rc2 completely hosed on intel gfx?
Submitter : Norbert Preining <firstname.lastname@example.org>
Date : 2010-06-06 11:55
Message-ID : 20100606115534.GA9399@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=127582534931581&w=2
This entry is being used for tracking a regression from 2.6.34. Please don't
close it until the problem is fixed in the mainline.
Up to 2.6.35-rc1 suspend was rock-solid on my computer. Since 2.6.35-rc2 I am often seeing hard freezes (not even Sysrq is working).
Following the suggestions of the original bug report I attach the .config plus the dmesg output after a successfull suspend.
I cannot attach the dmesg output after a not-successfull suspend, nothing is in there, since it is a hard freeze without even sysrq working.
Hope that helps
Created attachment 26862 [details]
config of the running kernel
Created attachment 26863 [details]
dmesg after a successfull suspend to ram
Can you try suspending from outside X?
echo 7 7 7 7 > /proc/sys/kernel/printk
echo 1 > /sys/power/pm_trace
echo mem > /sys/power/state
Having the last couple lines of output would really help.
> echo mem > /sys/power/state
Do I need config PM_TRACE? With my config I don't have /sys/power/pm_trace,
depends on PM_DEBUG && PM_SLEEP && EXPERIMENTAL
Gar... Sorry about that. If you end up recompiling your kernel can you enable CONFIG_ACPI_DEBUG as well?
In the end I'm mostly just poking through:
Ok, I have to say that it seems not to be a regression, but more a *developed* incompatibility I am tracking down.
echo mem > /sys/power/state
works 100% fine, without any problem.
BUT using suspend with pm-utils suspend mode breaks. First I thought because it uses uswsusp. So I switched to use the kernel mode for pm-utils suspend, but still there are some hangs.
I am trying to find the culprit, please see also Debian bug #586674
So I am not sure how to go from here with that bug report, please do whatever you think is appropriate.
Well, apparently it is not a bug from the kernel point of view, so I'm marking it as resolved. Please reopen if you find out that the this is a kernel problem after all.
I have to say it is a bit mysterious. Normally, in most of the cases with the echo mem > ... incantation the suspend/resume works without any problems, while using pm-utils it sometimes hangs.
In the cases of the pm-utils hangs it was always in the resume stage.
Just now I got a very similar hang with the pure kernel suspend/resume and I could see where it is hanging, at the backlight restore.
I made a photo of the hang and here are the last lines:
[16273.....] PM: resume of devices complete after 2115.046 msecs
[16273.....] Restarting tasks ... done
[16273.....] video LNXVIDEO:00: Restoring backlight state
and there it was off, the CPU started to work like hell (seemingly, the fans started), and not even sysrq worked, only 4-sec hold.
Whether this qualifies for a reopen I leave to you.
If you need any further information let me know.
AH, sorry, that was with git kernel up to commit 97e02140