Kernel 2.6.39 keeps breaking suspend (like 2.6.38)

paraw · Last edited by paraw on Sat Jul 23, 2011 8:44 am; edited 2 times in total

Upon updating from kernel 2.6.37 to 2.6.38 suspend to ram and to disk appear to be broken.
In particular, the system correctly goes to sleep/suspends to disk. Upon resuming, the resuming procedure is apparently completed, but the system remains locked on a black screen with a blinking underscore on the top left corner. Nothing can be done, except a hard poweroff of the system.
I tried different versions of the kernel, in fact all the 2.6.37 and 2.6.38, and the problem seems to start with the 2.6.38-r4, which is the lowest revision of the 2.6.38 tree available in portage. The latest 2.6.37, which is 2.6.37-r6, works fine.
The problem seems to exist also on other distributions (see, for example here). In the case linked the issue seems related to acer-wmi, but I strongly tend to exclude this in my case, as I don't have this option turned on in the kernel.

How can I identify where the problem is? I was thinking of using git bisect, but I'm not very familiar with it, and the man page doesn't help too much. For example, which tree should I clone to start working on it?

stareagle · n00b Joined: 04 Jul 2006 Posts: 29

Same problem here with the tuxonice kernel. With kernel version 2.6.37 it works, with the 2.6.38 kernel I get the same problem you have described. But: On my notebook suspend to disks works fine...

Regards, Stareagle

Hu · Administrator Joined: 06 Mar 2007 Posts: 23273

Clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.38.y.git, since you need multiple revisions of v2.6.38. If the problem started in =sys-kernel/gentoo-sources-2.6.38-r4, then I would look up which vanilla revision was used as a base for -r4. Build the corresponding sys-kernel/vanilla-sources to confirm the problem comes from upstream, rather than being introduced by Gentoo. Try also the latest =sys-kernel/vanilla-sources-2.6.38* if there is a newer one. Maybe you will get lucky and it has been fixed, but not pulled back to Gentoo yet. If it is still broken in the latest 2.6.38, then tell git bisect that the revision used for -r4 is bad and mark as good the most recent known working sys-kernel/vanilla-sources. From there, it can pick intermediate revisions to try.

You might also find it useful to pass no_console_suspend to the test kernels, so that you can get any error text that may be printed while the console is normally suspended. For VGA consoles, I have seen no problems from using no_console_suspend.

moben · n00b Joined: 09 Jan 2009 Posts: 52

same issue as here i think: https://forums.gentoo.org/viewtopic-t-876981.html

-> suspend/hibernate works again in 2.6.39

paraw · Posted: Sat Jul 23, 2011 8:43 am Post subject:

I just updated to kernel 2.6.39, and the problem remains, although with different symptoms.
With 2.6.39 suspend to ram completes successfully, but upon resuming the screen remains black. In fact, it appears that is does not turn on at all (backlight is off). Also, mouse and keyboard are not working. Suspend to disk, instead, just makes the computer hang after a while. It looks like it starts the procedure, but at a certain point it just ends up with a blinking cursor in the top left corner of the screen and the computer completely unresponsive (i.e., I have to turn it off by keeping the power button pressed for 5 seconds). Also, by inspection I see that it does not write anything at all on the suspend partition, so I guess it does not reach that stage.

Any help would be appreciated.

optiluca · Posted: Sun Jul 24, 2011 10:34 am Post subject:

paraw · Posted: Thu Jul 28, 2011 11:43 am Post subject:

Hmmm... I don't think that's my case.
In the other thread, you mention that the responsible commit is http://lkml.org/lkml/2011/4/29/308. However, I'm not using IOMMU at all, so I seriously doubt it to be the root of the problem. Incidentally, I tried bisecting but I was actually unable to identify the commit that started the trouble.

kimmie · Guru Joined: 08 Sep 2004 Posts: 531 Location: Australia

Sympathy post: I have the same problem. 2.6.36 was fine, 37 I never tried. Suspend works, but hibernate randomly fails on resume (blank screen) for 38,39....

paraw · Posted: Sun Jul 31, 2011 12:42 pm Post subject:

I compiled version 3.0 of the kernel, and I can confirm that the bug still persists. No change in symptoms from version 2.6.39. At this point I think I'll just open a new bug.

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3998

As of kernel 2.6..38-r7, suspend/hibernate works fine here.
Didn't try many times though.
So can not confirm it doesn't randomly fails.

I'm about to configure 2.6.39-r3.
Will return here and comment if I have any failure in this respect.

Thanks for your attention.

paraw · Posted: Tue Aug 02, 2011 8:58 am Post subject:

Alright... so... I investigated the problem a little more. The findings are as follows.

If I activate interrupts on hypertransport devices (CONFIG_HT_IRQ), then upon resume the system is frozen, with no power to USB ports and keyboard completely unresponsive.

Instead, if I set CONFIG_HT_IRQ=N, then all works fine, provided I'm using kernel modesetting for the video card (Mobility Radeon HD 4650). Otherwise, if I use the closed source driver (fglrx) OR the old DRI kernel module, the system resumes well, but the backlight of the laptop is off. Notice that this happens whether I'm in X or not and whether the fglrx module is loaded or not. In other words, if I use fglrx, even without loading the module (untainted kernel) and without entering X, the backlight is off upon resume. The same goes for the old DRI module: backlight off upon resume even if I didn't enter X at all.

So, in conclusion, a quick solution would be clearly to set CONFIG_HT_IRQ=N and use open source drivers with KMS. Unfortunately, this causes a different issue, namely that the power saving mode on the video card is switched completely off. As a result, my video card goes to 82 °C (180 °F) in idle, as opposed to 55 °C (131 °F).

Therefore, the question now becomes, how to get the backlight working upon resume using the børked closed source driver.

Thanks to all for info and support.

depontius · Advocate Joined: 05 May 2004 Posts: 3530

How much configuration tweaking have you done? I haven't played much with hibernation, but I do have one system that I've set up to suspend, and I know that there are a lot of hooks in there, especially for video. I'm away from that system now, but I'd swear that one of the things they let you do is unload the video and the kernel module for the proprietary drivers, and reload after wakeup.
_________________
.sigs waste space and bandwidth

paraw · Posted: Tue Aug 02, 2011 6:43 pm Post subject:

I've tried a few things, but the problem is that the backlight keeps being off on resume even if I use the in-kernel (old) drivers. As I mentioned, the only way to have the backlight on is to use KMS.

For what concerns the proprietary drivers, I even tried booting, not loading the fglrx module, suspending, resuming and (typing blindly on the keyboard) loading the module and starting X. The result is the KDE starts properly (I can even hear the startup sound), but the screen is still off.

So, more than a module-related issue, the problem seems to be more how to turn the backlight on without KMS, regardless of the open- vs. closed-source driver used.

depontius · Advocate Joined: 05 May 2004 Posts: 3530

Can you control the backlight separately? I've never actually tried this myself, I've seen backlight stuff in the kernel configs when I build them, and for my Thinkpads I load thinkpad_acpi, which I know includes backlight controls. If you can script it, I'm under the impression that most hibernation scripts/systems will let you hook in. Can you ssh in, get root, and try out various control methods on the backlight.
_________________
.sigs waste space and bandwidth