Description of problem: I've a second monitor (VGA) attached to the laptop. Xorg server, with a second monitor attached, defaults to span the visible area on both screens (i.e. the LDVS screen of the laptop and the external attached monitor). I work on the VGA so I put off the LDVS one through Preferences --> Monitor (like I do in F14). If I issue a suspend from the menu on the right upper corner, the system starts to suspend,the monitor goes blank with the mouse pointer freezed, the laptop led start blinking and unfortunately keeps blinking with the fan running and the system is freezed and the only meaning to reboot is by shut down with the power button. If I suspend WITHOUT touching the display preferences (as above), the laptop regularly suspend and I can also resume.
Created attachment 486329 [details] pm-suspend.log
Created attachment 486330 [details] /var/log/messages
Created attachment 486331 [details] Xorg.0.log
Smolt profile: http://www.smolts.org/client/show/pub_cc9c7be0-2d64-43b6-8ee4-65f9565de32e
Could we get also output of dmesg after suspend/resume cycle (probably not with multi-head configuration), please? Thank you
Created attachment 487732 [details] dmesg output Attaching dmseg output of a suspend/resume cycle with both monitor on. As already said, as soon as I put the LDVS monitor off, suspend will fail. If you need dmesg output when LDVS is off, don't know maybe you can suggest a command to "live" buffer its output into some file...I haven't investigated in this direction yet.
As of today, the problem still persists. This is very unfortunate because it prevents me to upgrade to F15 for day to day computing, as I work on the VGA monitor and I need to suspend/resume quite often during the day! Do you need more informations about it ?
Created attachment 496910 [details] dmesg output when laptop monitor is off
Created attachment 500413 [details] dmesg output when laptop monitor is off Added drm.debug=14 log_buf_len=16M options to kernel.
Created attachment 500415 [details] Xorg.0.log updated
I've no experience with the nouveau source code, but scrolling the dmesg output and looking at the drm-nouveau output,it seems to me that there is no evidence that the nouveau driver is to blame for the problem: should the bug be moved to some other component ?
I can confirm that this is not a nouveau bug. I have the same issue with the r600g driver.
I made a few tests: 1. The wrong behaviour is identical on XFCE,LXDE and KDE spins. 2. If x11 nouveau driver is replaced with the official binary driver from nvidia, I can suspend/resume successfully. This is probably due to the fact that nvidia driver doesn't use at all the X11 randr module to manage multiple monitors.It does rely to its own internal module to manage multiple attached displays. 3. Because of precedent point I am quite confident that the bug is not kernel related. 4. I have even tested the latest ubuntu release, which suffers the same problem.Interestingly enough, ubuntu in his latest version has update xorg 1.9 -> 1.10 http://www.ubuntuupdates.org/pm/xorg-server 5. F14 behaves correctly. 6. F15 has update xorg to 1.10 https://admin.fedoraproject.org/updates/xorg-x11-server?_csrf_token=b946fb964f1dc97cc205219925006ffbd5a45d12 Thus I feel to say: this is definitively a xorg-x11-server-Xorg server bug. More specifically the issue is related to the randr portion of x11 server. Enough to suggest to proceed with a bisection to find exactly where the problem lies. In the meanwhile to use F15, I have found that if the laptop lid is put "down enough" to shut it off when booting (i.e. on the first X11 start) until you log-in inside your system, than you can suspend/resume and move the lid without problems even after the first suspend/resume cycle.
I am so glad to find out this report. I have exactly the same issue. At least I am not alone. Unfortunately I couldn't find where to start from to trace this issue. Thanks Marco for this bugreport!
Upgrading to linux 3.1, nouveau problems are gone: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646057