Bug 650432 - Lenovo IdeaPad S12: Suspend does no longer work in Fedora 14 (was OK in F13)
Lenovo IdeaPad S12: Suspend does no longer work in Fedora 14 (was OK in F13)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-06 07:27 EDT by Joerg_H
Modified: 2011-03-07 15:40 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-09 16:09:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Misc info (cpuinfo, lspci, lsmod, services) - Fedora 14 (10.95 KB, application/octet-stream)
2010-11-06 07:27 EDT, Joerg_H
no flags Details
Misc info (cpuinfo, lspci, lsmod, services) - Fedora 13 - System OK (13.99 KB, text/plain)
2010-11-06 07:37 EDT, Joerg_H
no flags Details

  None (edit)
Description Joerg_H 2010-11-06 07:27:10 EDT
Created attachment 458311 [details]
Misc info (cpuinfo, lspci, lsmod, services) - Fedora 14

Description of problem:

Lenovo IdeaPad S12, Intel Atom N270, 2 GB RAM.

Using Fedora 13 KDE (2.6.34.7-61.fc13.i686, not PAE), Suspend and Hibernate work out of the box.

Using Fedora 14 KDE (2.6.35.6-48.fc14.i686 and its PAE sibling), Suspend no longer works.

This is perfectly reproducible:

1. Boot up, log in.
2. Close the laptop lid to put system into suspend mode.
3. Wait until fan activity etc has finished.
4. Reopen the lid. 

The machine does not "wake up" anymore. The 3 LED at the front (pwr, bat, wlan) come on, the fan does spin again, but there's no HDD activity (LED). Network is dead (not even ping). Display remains completely dark - no backlight at all. Display switching (Alt-Ctrl-Fn, or Fn-F2) does not change anything, I have to do a power cycle to get the machine running again.

After this forced re-boot there is nothing suspect in /var/log/messages - just NetworkManager taking down the network interfaces; the following line is written after the reboot.

Btw, Hibernate (Fn-F1) works flawlessly!

Tried to add "nolapic" on the kernel cmd line: Now Suspend works - but hibernate is now broken: The machine seems to boot but the display remains off - this time the backlight is on, and Fn-F2 has an influence (backlight on/off).

To me this seems NOT to be related to https://bugzilla.redhat.com/show_bug.cgi?id=641557 ... and NOT to https://bugzilla.redhat.com/show_bug.cgi?id=644842 either since there is no "tpm" message anywhere.


Additional info:

Using Fedora *13* KDE (2.6.34.7-61.fc13.i686 - not PAE) on the same machine (same home directory, same KDE power settings etc), Suspend and Hibernate work out of the box!
Comment 1 Joerg_H 2010-11-06 07:37:46 EDT
Created attachment 458314 [details]
Misc info (cpuinfo, lspci, lsmod, services) - Fedora 13 - System OK

For comparison, this is the output of cpuinfo, lspci, lsmod, services etc. for the trouble-free system = Fedora 13. 
- The 2nd CPU (atom) is no longer detected by the standard kernel in F14?
Comment 2 Zdenek Kabelac 2010-11-08 11:13:59 EST
Maybe completely unrelated - but could you please try to disable drm_kms_helper thread (see bug 617809 for more detail)?
Comment 3 Joerg_H 2010-11-08 14:17:55 EST
(In reply to comment #2)
> could you please try to disable drm_kms_helper

Been there, done it - no change:

(1) Created a file /etc/modprobe.d/drm.conf with the following line:

    options drm_kms_helper poll=0

(2) Reboot, then test as above.

Result: the laptop remains "dead". It would have been too nice ;-)
Comment 4 Zdenek Kabelac 2010-11-08 16:20:14 EST
Maybe checking with 2.6.36 kernel ? (http://koji.fedoraproject.org package kernel - try kernel-2.6.36-1.fc15)

Btw  - serial console could give you some great hints if you have it available.

Also you could try to attach kernel option to grub "no_console_suspend"  to see more kernel log messages.
Comment 5 Joerg_H 2010-11-09 03:20:00 EST
(In reply to comment #4)
> Maybe checking with 2.6.36 kernel ?

I prefer to stay with an official F14 kernel - this is a "production" laptop.
 
> Btw  - serial console could give you some great hints if you have it available.

N/A on the S12.

> Also you could try to attach kernel option to grub "no_console_suspend"  to see
> more kernel log messages.

Using this, the machine does not go into suspend mode when I'm in a console, but as soon as I'm in X it will go to sleep and not wake up anymore.

Additional info - don't know if this helps: As I said, I'm using KDE. When I close the lid using F13 (where suspend works fine) I can hear the sound notfication ("ding-dong-dang") *twice*. Using F14 with the same KDE environment settings (it's the same /home) , the sound is only emitted *once* and the last bit is cut off ("ding-dong-da--").
Comment 6 Zdenek Kabelac 2010-11-09 03:44:14 EST
If the bug is in the kernel - I think you will need to check if there is some kernel which does work properly, if the problem is visible on your particular laptop. (I assume you've already tested ideas from Bug 641557 i.e.: 'intel_idle.max_cstate=0' ?)

Also another thing to try is to install kernel from your previously working F13 version and iteratively try to go up by few version and see where the first fail is visible (something like kernel bisect - but you do not need to compile kernel yourself). I'd suggest to test 2.6.36 first - you do not need to use it later for work just for simple test and uninstall this kernel afterwards.

Also good idea would be to put KDE out of the game here - and try to use 'pm-suspend' as root directly from console - eventually - 
'echo mem >/sys/power/state' - so you would eliminate various plugin.
Comment 7 Joerg_H 2010-11-09 05:09:41 EST
(In reply to comment #6)
> I assume you've already tested ideas from Bug 641557 i.e.: 'intel_idle.max_cstate=0' ?)

No, since the symptoms reported there do not match mine ...

> is to install kernel from your previously working F13 version and 
> iteratively try to go up by few version and see where the first
> fail is visible 

ACK, I think this is the way to go ... 

Sorry for the potentially silly question - but how do I install the F13 kernel under F14 - preferably using yum? I have to admit that my last kernel compilation dates a few years back ;-)
Comment 8 Zdenek Kabelac 2010-11-09 06:00:47 EST
(In reply to comment #7)
> (In reply to comment #6)
> > I assume you've already tested ideas from Bug 641557 i.e.: 'intel_idle.max_cstate=0' ?)
> 
> No, since the symptoms reported there do not match mine ...
> 

Symptoms could be different - as users may have different settings.
(If you see kernel bugzilla from given bug - it's probably worth to try)

> > is to install kernel from your previously working F13 version and 
> > iteratively try to go up by few version and see where the first
> > fail is visible 
> 
> ACK, I think this is the way to go ... 
> 
> Sorry for the potentially silly question - but how do I install the F13 kernel
> under F14 - preferably using yum? I have to admit that my last kernel
> compilation dates a few years back ;-)


See the koji link from Comment 4 - pick kernel package and try to find in history kernels having fc13 inside - i.e.:

http://koji.fedoraproject.org/koji/buildinfo?buildID=200973

Try to find the one you had last working on your box (if you can remember)
Download and install kernel via   browser  and  'rpm -ivh'
reboot - test - eventually - repeat (eventually remove unneeded versions)
Comment 9 Joerg_H 2010-11-10 03:08:07 EST
(In reply to comment #6)
> try to use 'pm-suspend' as root directly from console

Been there, done that: The system "dies" in the same, constant way. KDE is definitively innocent.

Had no time yet to test with other kernels ...
Comment 10 Joerg_H 2010-11-11 07:43:14 EST
> See the koji link from Comment 4 - pick kernel package and try to find in
> history kernels having fc13 inside - i.e.:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=200973
> 
> Try to find the one you had last working on your box (if you can remember)

I still have FC13 with 2.6.34.7-61.fc13 running fine on this machine :-)

> Download and install kernel via   browser  and  'rpm -ivh'
> reboot - test - eventually - repeat (eventually remove unneeded versions)

For now, I downloaded and installed ("yum --nogpgcheck localinstall ...") the following two kernels in F14:

kernel-PAE-2.6.34.7-61.fc13.i686.rpm = identical to F13 on the same machine
kernel-PAE-2.6.34.7-62.fc13.i686.rpm

In BOTH cases, suspend (lid) and hibernate (Fn-F1) work flawlessly. 

To be continued ... (sometimes I have to work, too ;-))
Comment 11 Joerg_H 2010-11-11 08:44:35 EST
Update ... two more:

kernel-PAE-2.6.35.8-53.fc14.i686.rpm - behaves just like described initially in this thread, i.e. the S12 is "dead" after closing the lid.

kernel-PAE-2.6.36-1.fc15.i686.rpm - something has changed: when I reopen the lid, the display backlight is enabled and (after a while) I can see the mouse cursor. Alt-Ctrl-Backspace then kills X, but at least the machine is brought back to life :-) Thus. not perfect, but somehow on the right track ...

Hibernate (Fn-F1) is somehow half-working - seems to require keyboard interaction before really sleeping, and takes a looong time to wake up.

And ... I need to figure out why the wireless card has "disappeared" ... 

In the meantime I'll stay with the F13 partition for production work.
Comment 12 Zdenek Kabelac 2010-11-11 09:07:21 EST
Do you need to  kill X - or just switch between  Alt+f1 & Alt+Fx whather your X server is located on (F7?) is enough to get back to your running Xsession ?

I think this is some problem of Xorg intel driver and resume - not sure where - but simple switch between console makes thing working.
Comment 13 Joerg_H 2010-11-11 10:24:34 EST
(In reply to comment #12)
> Do you need to  kill X - or just switch between  Alt+f1 & Alt+Fx whather your X
> server is located on (F7?) is enough to get back to your running Xsession ?

Switching is enough. 

Actually the behaviour "what happens when" is somewhat unclear with this kernel-PAE-2.6.36-1.fc15; tried to reproduce:

- put laptop to sleep by closing lid
- upon try-to-resume, the backlight remains intially off. 
- No reaction to keys nor display switching.
- Backlight comes on when I briefly hit the On/Off button. Display is still off.
- I need to caress the mousepad ;-) and hit ENTER at least once until I get something onscreen - reminds me of a memory from "just before suspend". Still nothing workable, but at least the screen is alive now.
- After display switching (Alt-F2 and back to X server on Alt-F1), the display comes back to life. 

Btw, another kernel: kernel-PAE-2.6.35.4-28.fc14.i686.rpm - unusable on this machine. Seems to freeze quite often for quite a while (during boot, after login, etc). Removed.
Comment 14 Zdenek Kabelac 2010-11-11 10:31:34 EST
(In reply to comment #13)
> (In reply to comment #12)
> > Do you need to  kill X - or just switch between  Alt+f1 & Alt+Fx whather your X
> > server is located on (F7?) is enough to get back to your running Xsession ?
> 
> Switching is enough. 
> 
> Actually the behaviour "what happens when" is somewhat unclear with this
> kernel-PAE-2.6.36-1.fc15; tried to reproduce:
> 
> - put laptop to sleep by closing lid
> - upon try-to-resume, the backlight remains intially off. 

And now the game with  drm_kms_helper thread :)
I need to disable it on my machine to keep backlight working and avoid weird intel driver bug.


> - No reaction to keys nor display switching.
> - Backlight comes on when I briefly hit the On/Off button. Display is still
> off.
> - I need to caress the mousepad ;-) and hit ENTER at least once until I get
> something onscreen - reminds me of a memory from "just before suspend". Still
> nothing workable, but at least the screen is alive now.
> - After display switching (Alt-F2 and back to X server on Alt-F1), the display
> comes back to life. 

Thought in my case I've never seen a chance to restore disabled backlight and reboot was required - but it's not longer problem with disable helper thread.
So eventually you problem here could be different.

But it looks like your machine 'freezing' suspend bug has been fixed in 2.6.36 kernel - and the only remaining problem is incorrectly restored Xsession ? (which should be opened as another bug I think)
Comment 15 Joerg_H 2010-11-11 10:41:52 EST
(In reply to comment #14)

> And now the game with  drm_kms_helper thread :)
> I need to disable it on my machine to keep backlight working and avoid weird
> intel driver bug.

Well, I just removed this fc15 kernel out again since the wireless drivers are not working ;-)

> But it looks like your machine 'freezing' suspend bug has been fixed in 2.6.36
> kernel

No it isn't. See for yourself:

Expected behaviour: re-open the lid, wait a few seconds, and voilà - machine is usable (This is the case with FC13).

Observed behaviour: re-open the lid, touch a few buttons, hit POWER, wait a few seconds, hit ENTER, touch the mousepad, hit Alt-F2, hit Alt-F1. Explain to curious observers (I'm using this laptop in seminars!) what you're doing, and then the machine is usable. In my book, this is far from "resolved" ;-)
Comment 16 Zdenek Kabelac 2010-11-11 10:58:37 EST
(In reply to comment #15)
> (In reply to comment #14)
> 
> > And now the game with  drm_kms_helper thread :)
> > I need to disable it on my machine to keep backlight working and avoid weird
> > intel driver bug.
> 
> Well, I just removed this fc15 kernel out again since the wireless drivers are
> not working ;-)

Ohhhh - wireless - that's a completely different story :(...

> 
> Expected behaviour: re-open the lid, wait a few seconds, and voilà - machine is
> usable (This is the case with FC13).
> 
> Observed behaviour: re-open the lid, touch a few buttons, hit POWER, wait a few
> seconds, hit ENTER, touch the mousepad, hit Alt-F2, hit Alt-F1. Explain to
> curious observers (I'm using this laptop in seminars!) what you're doing, and
> then the machine is usable. In my book, this is far from "resolved" ;-)

Here I purely meant 'resolved' from kernel point of view - not from the users pov :) Bug should probably travel over to some xorg package.
(Unless dmesg shows some warning/errors from this operation).
Comment 17 Joerg_H 2010-11-11 11:01:22 EST
(In reply to comment #14)

> And now the game with  drm_kms_helper thread :)

OK ... so I re-installed kernel-PAE-2.6.36-1.fc15 and created a file /etc/modprobe.d/drm.conf with "options drm_kms_helper poll=0" in it. 

Reboot. Log into X.

Close lid.

Re-open lid:
- Backlight comes on.
- a little flashing text cursor (about 1/4 from top of the screen, left edge). No reaction to any keyboard key.
- Briefly hit POWER: System seems to come alive. I stll need to hit ENTER, Alt-F2 and Alt-F1 before the system is operational again. 

Please don't call that a fix, it's not even a workaround ;-)
Comment 18 Joerg_H 2010-11-11 11:08:02 EST
Ah, our comments overlapped ... 

> Bug should probably travel over to some xorg package.

Hmmmm. I don't know if that would be appropriate?

- On the same machine and using Fedora 14 as base system but using the late FC13 kernels (e.g. kernel-PAE-2.6.34.7-62.fc13.i686.rpm), suspend/hibernate works flawlessly. 

- When I change the *same* system to any fc14 kernel, suspend/hibernate fails.

... and the complete X environment is the same ... in both cases. Now try to explain that to the xorg people ;-)
Comment 19 Zdenek Kabelac 2010-11-11 11:37:46 EST
I'm far from saying where is the bug - but there are differences in the Intel kernel driver versions (which is in fact partially developed by some by Xorg bugzilla team members) between each kernel release - and Xorg driver decides upon supported feature set what will be used -  so I'm guessing  2.6.34 doesn't support some latest technologies also used by Xorg - so if the Xorg founds some feature is not supported by the kernel driver - it will not use it - and you will not see a  bug.

For the kernel side - I think it's important whether it works on your console only -  if the kernel resumes on console without any X involved - then it's kernel bug - if you see the problem with X - I would suggest to reassign bug to xorg intel driver.
Comment 20 Zdenek Kabelac 2010-11-11 19:09:49 EST
Played bisect game myself - and guilty upstream kernel is this one:

commit 8fd4bd22350784d5b2fe9274f6790ba353976415
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jun 23 12:56:12 2010 -0700

    vt/console: try harder to print output when panicing
    

This is the first commit which is switch X screen to black and you need to switch consoles.
Comment 21 Joerg_H 2010-12-05 06:48:18 EST
Good news!

Just received the Fedora 14 update for kernel 2.6.35.9-64.fc14.i686.PAE. As far as I can conclude from several quick tests, both "Suspend" and "Hibernate" are working again on this machine! 

Now I just have to wait until the WiFi modules (kmod-wl-PAE and broadcom-wl) are available for the PAE kernel ... ;-)
Comment 22 Kyle McMartin 2010-12-09 16:09:47 EST
Great, glad it got fixed.

regards, Kyle
Comment 23 Adam Williamson 2011-03-07 15:40:37 EST
drop commonbugs keyword.

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