Bug 650432

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?

Maybe completely unrelated - but could you please try to disable drm_kms_helper thread (see bug 617809 for more detail)?

(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 ;-)

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.

(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--").

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.

(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 ;-)

(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)

(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 ...

> 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 ;-))

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.

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.

(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.

(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)

(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" ;-)

(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).

(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 ;-)

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 ;-)

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.

Played bisect game myself - and guilty upstream kernel is this one:

commit 8fd4bd22350784d5b2fe9274f6790ba353976415
Author: Jesse Barnes <jbarnes>
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.

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 ... ;-)

Great, glad it got fixed.

regards, Kyle

drop commonbugs keyword.