Hide Forgot
Description of problem: Since upgrading to F15, suspend to ram on closing laptop lid no longer works. (It did with F14 only a few days ago). Version-Release number of selected component (if applicable): kernel-2.6.38.8-31.fc15.x86_64 libdrm-2.4.25-1.fc15.x86_64 xorg-x11-drv-ati-6.14.1-1.20110504gita6d2dba6.fc15.x86_64 How reproducible: Always, with 2.6.38.6-27.fc15 also. Steps to Reproduce: 1. close laptop lid (Toshiba Satellite Pro A210) 2. 3. Actual results: led does not switch to flashing amber; re-opening lid, screen blank and no longer responsive. Requires holding power/reset button to reboot to regain use. Expected results: led switch to flashing amber; re-opening lid results in laptop waking up. Additional info: On a hunch from age-old experience with kernel-mode-setting and with early version of xf86-video-ati/xf86-video-radeonhd on the same hardware from a year or two ago (see my previous postings on redhat's bugzilla), I tried booting with "nomodeset" edited onto the grub command line. Voila, suspend to ram works again. I saved my f14 rpm package list before upgrade last week, and the last successful suspend would seem to be: libdrm-2.4.22-1.fc14.x86_64 kernel-2.6.35.12-90.fc14.x86_64 kernel-2.6.35.13-91.fc14.x86_64 xorg-x11-drv-ati-6.13.1-0.4.20100705git37b348059.fc14.x86_64 If you need to know more about either pre/post-f15 upgrade, please feel free to ask. This is crazy to have such a bad regression(?) to reappear after two years...
Booting into the f14 kernel 2.6.35.13-91.fc14.x86_64 normally (without nomodeset) also allow suspend to work. so kernel 2.6.35.13-91.fc14.x86_64 + rest of f15 or nomodeset (kernel 2.6.38.6-27.fc15/2.6.38.8-31.fc15.x86_64) + rest of f15 are known to allow suspend to ram to work (and resume). So this looks like a dri problem...
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
(In reply to comment #1) > kernel 2.6.35.13-91.fc14.x86_64 + rest of f15 > or > nomodeset (kernel 2.6.38.6-27.fc15/2.6.38.8-31.fc15.x86_64) + rest of f15 > are known to allow suspend to ram to work (and resume). > > So this looks like a dri problem... Also, if you try to install some older 2.6.38.* F15 kernel from http://koji.fedoraproject.org/koji/packageinfo?packageID=8 could you make it work?
downloaded the first of f15 - kernel-2.6.36.1-11.fc15.x86_64 - it also crashes on suspend. (and the last f14 kernel-2.6.35.13-91.fc14.x86_64 still suspend and wake up okay). Will be attaching the logs etc now. Sorry I forgot to add drm.debug=0x04 - but other than that, the rest will be attached.
Created attachment 503815 [details] Xorg.0.log under f14 kernel (suspend and wake ok) before booting the latest f15 kernel (which crashes on suspend),
Created attachment 503816 [details] dmesg on latest f15 kernel (crashes on suspend) dmesg on latest f15 kernel (crashes on suspend) - the first f15 kernel from koji also crashes on supend. so I am using the last f14 kernel for now.
Created attachment 503817 [details] Xorg.0.log under f15 kernel (crash on suspend) Xorg.0.log f15
Created attachment 503822 [details] Xorg.0.log under f14 kernel again (suspend and wake ok), after Xorg.0.log from f14 kernel again, just to be sure.
I am wondering if it is a stable long-term kernel vs others, but possible not.
Created attachment 504052 [details] /var/log/message, up to just before closing the lid. /var/log/message for f15 kernel up to just before closing the laptop's lid.
Hi everyone, I'm having the same problem on my desktop with suspend/resume. It was perfect with F14 but now, with F15, the resume gives a black screen. I tried the option "nomodeset" with actual kernel (2.6.38.7-30.fc15.i686.PAE) but nothing is changed and also the driver intel isn't loaded. So I tried to start with the last F14 kernel that I used before update (2.6.35.13-91.fc14.i686.PAE) and suspend/resume works well again. Let me know if you need some additional informations. Bye
kernel-2.6.40-4.fc15.x86_64 still won't suspend . (In reply to comment #11) > Hi everyone, > I'm having the same problem on my desktop with suspend/resume. > It was perfect with F14 but now, with F15, the resume gives a black screen. > I tried the option "nomodeset" with actual kernel (2.6.38.7-30.fc15.i686.PAE) > but nothing is changed and also the driver intel isn't loaded. > So I tried to start with the last F14 kernel that I used before update > (2.6.35.13-91.fc14.i686.PAE) and suspend/resume works well again. > Let me know if you need some additional informations. > Bye Won't _suspend_ and won't _resume_ are entirely different problems, BTW. Since yours cannot be worked around by nomodeset, it would look to be an entirely different problem on a 2nd count. On a 3rd count, you mentioned intel hardware - I have ATI hardware.
Created attachment 527562 [details] 2.6.40.6 (3.0.0.6) drm.debug=0x04 dmesg 2.6.40.6 (3.0.0.6) drm.debug=0x04 dmesg 2.6.40.6-0.fc15.x86_64 This one crashes (without nomodeset) on suspend and aren't responsive (blank screen but power light on throughout). This was captured before suspend, of course.
Created attachment 527563 [details] dmesg when nomodeset is added dmesg when nomodeset is added, drm.debug=0x04 also, latest kernel (same as the last attachment). suspend and resume okay twice. So this definitely looks like a modeset problem with suspend. Strangely enough mplayer works, etc, and there does not seem to be any lost of functionality with nomodeset added (unlike previous experience a few years ago when kernel modesetting was first introduced)
Strangely since I upgrade to f16 radeon/RS690 seems to default to nomodeset. Is such a change intended? # grep modeset /var/log/Xorg.0.log [ 84.185] (II) [KMS] drm report modesetting isn't supported. I am not really complaining - while there is no nice graphics at boot up, suspend/resume works, and that's more important.
Please ignore last comment - I found that I got so fed up with suspend not working with modeset for 4 months, I added /etc/modprobe.d/radeon-kms.conf with "options radeon modeset=0" as content, on 25 Oct, just before upgrading to f16 and I forgot about doing so afterwards. It wasn't in the more usual grub.conf or /etc/sysconfig/kernel, so I totally forgot about it. Nevertheless, after 2 months, and now at 3.1.9-1.fc16.x86_64, and I removed the workaround I put in and forgot, suspend with modesettting seems to work again. I don't know when it started working between 2.6.40-6-0.fc15 and 3.1.9-1.fc16 but it seems to be working okay at least twice now. I'll re-open if I see the problem persistently again.