Description of problem: With nomodeset (and thus textual boot sequence) suspend/resume works fine. Without nomodeset (and thus graphical boot sequence) then resume hangs. 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary) in Dell OptiPlex 745 Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.9.0-27.fc10.i386 kernel-2.6.27-13.fc10.i686 How reproducible: 100%
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 attach your X server config files (/etc/X11/xorg.conf) and X server log files (/var/log/Xorg.*.log), and /var/log/dmesg from both attempts to start Xorg (with and without nomodeset) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
I tried booting to runlevel 3 (no X) but without nomodeset (and thus with graphical boot sequence) . After pm-suspend I couldn't resume. So it isn't related to X and I reassign to kernel. When booting to runlevel 5 it runs without xorg.conf. Logs from running with nomodeset is attached to Bug 467430.
Created attachment 320876 [details] /var/log/messages from boot to runlevel 3 without nomodesetting where pm-suspend can't resume
Created attachment 320877 [details] Xorg.0.log from session without nomodeset which can't resume - but it probably isn't interestning when the same is seen without X ...
Problem remains with xorg-x11-drv-ati-6.9.0-29.fc10.i386 kernel-2.6.27.3-34.rc1.fc10.i686
I changed the component to kernel, but can't change the assignment from X team to kernel team. Could someone please un/reassign.
kernel-2.6.27.4-58.fc10.i686 contained some radeon fixes, but it did not fix this.
FWIW, the same with kernel-2.6.27.4-69.fc10.i686
- and rawhide with kernel-2.6.27.4-73.fc10.i686 xorg-x11-drv-ati-6.9.0-41.fc10.i386
and kernel-2.6.27.5-92.fc10.i686
airlied: should be fixed with latest kernel/pm-utils airlied: -104 kernel + pm-utils 1.2.2.1-2
It did NOT work with kernel-2.6.27.5-104.fc10.i686 (modeset) xorg-x11-drv-ati-6.9.0-44.fc10.i386 (neither with or without) pm-utils-1.2.2.1-2.fc10.i386 Can I debug more somehow? Btw: the proper way to test from runlevel 3 - that is a plain "pm-suspend", right?
Didn't work for me either: kernel-2.6.27.5-104.fc10.i686 pm-utils-1.2.2.1-2.fc10.i386 xorg-x11-drv-ati-6.9.0-38.fc10.i386 ...the behavior is pretty much: "normal" boot -- without nomodeset: ----------------------------------- suspend makes laptop go to sleep, but it will not resume hibernate fails to ever power off the machine with nomodeset: --------------- suspend makes laptop go to sleep, but it will not resume hibernate and wakeup works as expected
Suspend AND resume works fine for me with nomodeset. So apparently it isn't exactly the same problem we have. (jlayton: Perhaps you should creater another issue with your system information and logs. Or you could wait and see if it gets solved with this issue.) (I don't use hibernate and haven't tested it. Will do when suspend works.)
Thanks Mads, I've gone ahead and opened bug 471711 for the problems I'm seeing.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I confirm this issue with similar hardware 01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series] and kernel-2.6.27.7-130.fc10.x86_64. With "nomodeset" (KMS disabled), suspend to ram (echo mem > /sys/power/state) works as well as resuming. But if KMS is active, the computer suspends but resuming does not work (black screen, everything dead).
Can you please check if you have stuff like this in /var/log/messages after a failed resume? Dec 2 12:25:35 lopeptoid kernel: Suspending console(s) (use no_console_suspend to debug) Dec 2 12:25:35 lopeptoid kernel: [drm:drm_bo_evict_mm] *ERROR* lru empty Dec 2 12:25:35 lopeptoid kernel: [drm] Num pipes: 1 ... Dec 2 12:25:35 lopeptoid kernel: pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Dec 2 12:25:35 lopeptoid kernel: [drm:radeon_resume] *ERROR* Dec 2 12:25:35 lopeptoid kernel: [drm] Loading R500 Microcode Dec 2 12:25:35 lopeptoid kernel: [drm] Num pipes: 1 Dec 2 12:25:35 lopeptoid kernel: [drm] writeback test failed Dec 2 12:25:35 lopeptoid kernel: [drm:drm_ttm_bind] *ERROR* Couldn't bind backend. Dec 2 12:25:35 lopeptoid kernel: executing set pll Dec 2 12:25:35 lopeptoid kernel: executing set crtc timing Dec 2 12:25:35 lopeptoid kernel: [drm] LVDS-8: set mode 1280x800 10 Dec 2 12:25:35 lopeptoid kernel: executing set LVDS encoder Dec 2 12:25:35 lopeptoid kernel: Restarting tasks ... done.
It seems to work fine with kernel-2.6.27.7-130.fc10.i686 modeset xorg-x11-drv-ati-6.9.0-60.fc10.i386 from updates-testing Closing.