Created attachment 127191 [details] dmesg, cpuinfo, lsusb, lspci I have a HP laptop g6-2145ss with Fedora 20 installed into my HDD. But, I have to add this problem persist at openSUSE 13.1 and Tumbleweed too. Fedora or openSUSE does not suspend system properly. When It's going to suspend. This works OK. But wake up does not work. Screen does not turn on. I have to force reboot machine push AC powe button. It's not good idea. However, when I use AMD Catalyst drivers. I can perform suspends awesome. I guess is a kernel bug, or AMD haven't released source code of suspend graphics card yet. Log attached is of AMD Catalyst driver installed and how to works fine suspend operation. Note: I don't interested use AMD Catalyst driver, because I'm using GNOME 3.10 and It's does not work with it. Because AMD does not included libGLES into privative driver.
Created attachment 127201 [details] pm-utils.log
I tried to listen to music with VLC player. So I was surprised... system works 100% after resume but Screen is off LOL. I can swtich into different ttys and X11 desktop without Screen turned on LOL.
Add information: I've tried some options to going into suspend system with pm-suspend --* All options tried was not turn on laptop screen after resume: --quirk-dpms-on --quirk-dpms-suspend --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore --quirk-vga-mode-3 --quirk-save-pci --store-quirks-as-lkw --quirk-none
Created attachment 127311 [details] Contains some information get of pm-utils-bugreport.sh script.
systemctl suspend does not work too. systemd-python-208-9.fc20.x86_64 systemd-208-9.fc20.x86_64 systemd-libs-208-9.fc20.x86_64
From mine (toshiba, but I believe the hp has similar graphic hardware): dmesg: [drm] Found VCE firmware/feedback version 40.2.2 / 15! # lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] I looked up that 'VCE firmware/feedback' line where it comes from in the kernel code. It seems that Mullins support in new to kernel 3.15.x (?) and still being actively worked on. Is that correct?
(In reply to Hin-Tak Leung from comment #6) > From mine (toshiba, but I believe the hp has similar graphic hardware): > > dmesg: > > [drm] Found VCE firmware/feedback version 40.2.2 / 15! > > # lspci | grep VGA > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Mullins [Radeon R3 Graphics] > > > I looked up that 'VCE firmware/feedback' line where it comes from in the > kernel code. It seems that Mullins support in new to kernel 3.15.x (?) and > still being actively worked on. Is that correct? This is a different chip than Álvaro, so it's probably a different issue.
Created attachment 150801 [details] possible fix for mullins This patch may fix Hin-Tak's issue, but won't affect the original reporter.
(In reply to Alex Deucher from comment #8) > Created attachment 150801 [details] > possible fix for mullins > > This patch may fix Hin-Tak's issue, but won't affect the original reporter. Yes, it does fix my suspend problem. Thanks for the quick response. Please feel free to add a 'Tested-By:'. The screen stays blank after wake on hibernate though, with these messages: Sep 19 04:42:48 localhost kernel: [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed Sep 19 04:42:48 localhost kernel: [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed Somehow blindly suspending (by accident, pressing the power button for too short a duration) aand waking brings it back, interestingly. The corrupted mouse pointer also changed from the usual 'squashed + block' ( photo attached to https://bugzilla.redhat.com/show_bug.cgi?id=1141491#c0) to a phantom double pointer, which is extremely confusing now. I'll attach the full dmesg of the 'wake from hibernate + suspend + wake from suspend', and the double pointer picture below. And while I am at it, is there any patches to get x-video I should try?
Created attachment 150871 [details] The wake from hibernate, suspend and wake dmesg. The wake from hibernate, suspend and wake dmesg, mentioned in the last comment. screen does not turn on until after the 2nd wake.
Created attachment 150881 [details] photo of the double-pointer corruption It is very confusing - the arrow is fake, and the squashed text cursor 3 lines above is the correct one. Both are smaller than intended. This double-pointer is very confusing and worse than the usual 'pointer + block' corruption. ( see https://bugzilla.redhat.com/attachment.cgi?id=937273 in https://bugzilla.redhat.com/show_bug.cgi?id=1141491#c0 )
(In reply to Hin-Tak Leung from comment #11) > photo of the double-pointer corruption Looks like you're using an old version of xf86-video-modesetting, or another generic driver which doesn't correctly handle 128x128 hardware cursors. Please use the radeon driver from a current version of xf86-video-ati; with glamor enabled, that also provides X-Video support.
(In reply to Michel Dänzer from comment #12) > (In reply to Hin-Tak Leung from comment #11) > > photo of the double-pointer corruption > > Looks like you're using an old version of xf86-video-modesetting, or another > generic driver which doesn't correctly handle 128x128 hardware cursors. > Please use the radeon driver from a current version of xf86-video-ati; with > glamor enabled, that also provides X-Video support. Thanks for the hints! Bringing drv-ati,drv-modesetting,glamor up gives me the correct cursor, and I get X-Video after bring mesa (and llvm) up - from up-to-date fedora 20 to the not-yet-alpha fedora 21-ish. The mouse cursor totally disappeared after GUI login in the first reboot (and I had to use vt2 to reboot the system again) and video playback showed very strange colors - almost B/W-ish - after the first X restart, but both wierdness seems to be gone in later reboots, so far. So as far as I am concerned, I just need attachment 150801 [details] going upstream, and possibly the hibernate cik_ring_test/radeon_dp_link_train_cr error issue looked at. FWIW, I tested attachment 150801 [details] against 3.16.2 (or rather, adapted fedora's 3.16.2-200 to include the patch).
(In reply to Hin-Tak Leung from comment #13) ... attachment 150801 [details] going > upstream ... cik_ring_test/radeon_dp_link_train_cr > error issue looked at. To answer my own question, attachment 150801 [details] is in 3.17-rcX, so will be in 3.17 proper ; my suspend problem is no-more. I've a problem with GPU lock-up under stress, filed as Bug 85421 .
(In reply to Hin-Tak Leung from comment #14) ... > To answer my own question, attachment 150801 [details] is in 3.17-rcX, so > will be in 3.17 proper... besides v3.17-rc6, it is also in v3.16.4 .
I have a Dell Inspiron with AMD A6 (Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics]), and stopped upgrading my kernel at 3.16.3 because it would no longer resume from disk about 90% or more of the time. I have finally given in and looked for the cause a bit, and have traced it to this patch. Without this patch, 3.18.3 (and probably all other versions I skipped before it) works fine for me. That said, I never suspend to memory, and so I tried with and without, and indeed the patch seems to be necessary for resume-from-memory on my system as well. So, while this patch does fix a bug, it introduces a regression for me. Is it possible the value of nb_dpm_enabled is not restored or initialized properly on resume from disk, due to the video mode change? The symptoms when resuming from disk are similar to comment 9 (ring test failures, which do not occur without the patch), with X crashing (and, due to the fact that I start it in inittab, retrying with "couldn't schedule ib" error until I reboot or disable the inittab entry).