Bug 45981 - Resume from suspend to ram doesn't work anymore since kernel 3.5.0-35 and higher
Summary: Resume from suspend to ram doesn't work anymore since kernel 3.5.0-35 and higher
Status: CLOSED OBSOLETE
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Lan Tianyu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-14 20:05 UTC by Andreas Prittwitz
Modified: 2013-03-31 14:28 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.5.0-35 and higher
Tree: Mainline
Regression: Yes


Attachments
dmesg after failing resume (246.57 KB, text/plain)
2012-10-29 10:38 UTC, Harald Brennich
Details
messages of kernel 3.6.3 with failing resume (145.96 KB, text/plain)
2012-10-29 10:39 UTC, Harald Brennich
Details

Description Andreas Prittwitz 2012-08-14 20:05:14 UTC
Machine fails to resume from suspend to ram every time since kernel 3.5.0-35.
It enters str correctly, but when waking it up it only comes up with the
following message repeating it endlessly:

drm nouveau 0000:02:00:0 Failed to idle channel 1
drm nouveau 0000:02:00:0 0x2634 !=child: 0x00100002
drm nouveau 0000:02:00:0 FIFO - playlist update failed

Machine can be restarted by logging in on the console that's showing the
above error messages and typing "systemctl reboot".

I couldn't find any hints in the log files.
Comment 1 Andreas Prittwitz 2012-08-14 20:07:00 UTC
Forgot to say that this is a desktop PC.
Comment 2 Alan 2012-08-15 21:46:22 UTC
If you build without the nouveau driver does it suspend/resume fine (even if you only get console mode) ?
Comment 3 Andreas Prittwitz 2012-08-18 11:40:44 UTC
Alan,

I am sorry for the long delay and the brief description but I was running out of time.

This machine is running openSUSE 12.1 64-bit, updated from the openSUSE Tumbleweed repo, running KDE 4.8.4 on an Asrock N68-S mobo, using an NVIDIA GT440.

I am just a user, so I don't compile (or "build" as you mentioned above) my own kernel(s). I am using the desktop-kernels provided by openSUSE. So I regret, but I can't answer your question.

In the case of this bug, I filed the bug on openSUSE's bugzilla first. You can find it here:

https://bugzilla.novell.com/show_bug.cgi?id=775601

Jeff Mahoney from SUSE asked me to try the vanilla kernel to see if this behaviour also happens with a vanilla kernel and if so, which was the case, to file a bug report here at kernel.org.

When I wake the machine from str it only shows a black screen without a login window for about 10 seconds. After that it switches to a console where the above error message appears. Alternatively I can switch to a console myself pressing strg+alt+F(x). After about 10 seconds it switches back to a black sreen saying "Resuming..." in the upper left corner which is shown for about 10 seconds again. It then repeats the whole procedure over and over again.

Regretfully, this is all I can tell you about this bug and I hope it helps. If I can do somthing else to help to resolve this, please let me know.
Comment 4 Jeff Mahoney 2012-09-25 23:06:51 UTC
Andreas, you can test it by booting with 'nomodeset' on the command line.
Comment 5 Andreas Prittwitz 2012-09-26 12:45:51 UTC
Jeff, thanks for your hint.

Kernelversion is openSUSE's 3.5.3-40-desktop.

I tried what you suggested and the machine's behaviour changed when resuming, compared to the behaviour described above. 

The result was a black screen without a login window and no way to <ctrl+alt+x> to a console to be able to reboot the machine, entering 'systemctl reboot' at the prompt. The only way to cure this was to press the reset button.

I also tried to str without 'nomodeset' and the behaviour when resuming also changed. I now get a login prompt where I can enter my password. After that the kde wallpaper appears, but without the systempanel (no kickoff). When right-clicking on the desktop there is no context menu popping up and I can't do anything but to <ctrl+alt+x> to a console, login as root and enter 'systemctl reboot' at the prompt.

HTH.
Comment 6 Harald Brennich 2012-10-19 15:36:31 UTC
I have a similar problem.
Environment:
Hardware: Toshiba Satellite L755-161 notebook
System: openSuse 12.1
Kernel: 3.4.11

Up to kernel version 3.4.1, resume from s2ram worked fine (not so resume from s2disk, see bug 42627). With kernel version 3.4.11, resume results in kind of colored salt and pepper screen. Some frames still are visible, and login is possible, but the screens are not shown properly so it is best to go to console mode and reboot.
I don't know how to get at kernel sources prior to 3.4.11, so I cannot tell starting with what kernel version the resume fails.
Comment 7 Harald Brennich 2012-10-29 10:32:18 UTC
I have gained some more information on the failing resume.
1. Though resume from s2ram sporadically fails with kernel versions 3.4.x, but generally it works.
2. Starting with 3.5.x up to 3.6.3, resume from s2ram fails with respect to the xsession. Symptoms are:
2.1 Background image of screens is not shown anymore. Instead, some salt & pepper is displayed. If the background is simply a color, the color will be displayed when clicking on the background.
2.2 The margin of running windows is not displayed. However, the content page of running programs (Java, browser) is shown.
2.3 The task bar and the screen menus are not displayed. However, they can be used via the keyboard (if you know what to enter - no prompts, no guidance).
2.4 When a program is started, for instance vlc or a file browser, the content page is shown, but incompletely - for instance no text in the file lists. Again, vlc can be controlled via the keyboard.
2.5 Switching to console mode (ctl-alt-fx) works. That way dmesg and messages where gained.
Comment 8 Harald Brennich 2012-10-29 10:38:14 UTC
Created attachment 85171 [details]
dmesg after failing resume

dmesg after resume from s2ram with kernel version 3.6.3. xsession is faulty.
Comment 9 Harald Brennich 2012-10-29 10:39:35 UTC
Created attachment 85181 [details]
messages of kernel 3.6.3 with failing resume

messages after resume from s2ram with kernel version 3.6.3. xsession is faulty.
Comment 10 Harald Brennich 2012-11-21 09:33:49 UTC
One additional observation:
When the xsession is terminated via ctl bsp bsp, the prompt for user login appears. After login, the system works again.
It looks as if some instance (nouveau?) simply lost a lot of information of what and how to represent on the screen (including some fonts?), but starting the new xsession fixes everything.
So possible the problem does not start with the resume but with the suspend.
Comment 11 Harald Brennich 2012-11-23 10:29:39 UTC
As suspend/resume bugs do not seem to be in focus of nouveau-developers I have decided to replace nouveau by the current nvidia driver (310.19). With this driver, both s2ram and s2disk work. Hopefully in the future also a working nouveau is available.
See also bug #42627
Comment 12 Lan Tianyu 2013-03-31 14:26:47 UTC
This is a video driver and nvidia driver works smoothly with s2ram. So close the bug.

Note You need to log in before you can comment on or make changes to this bug.