Created attachment 157241 [details] dmesg log before suspending [kernel 3.18rc3] In versions before and equal to 3.18 rc3, I used an acpi video S3 quirk to resume my laptop properly to fully workable state after suspending the machine. I used to enter the command "sysctl -w kernel.acpi_video_flags=3" which would allow my machine to resume properly. Without the quirk, my system would resume but without a backlight. With the latest mainline kernel 3.18 rc4, the quirk does not work properly. Using the same quirk, and trying to resume results only in a big blinking cursor even though the backlight works. I am even unable to perform VT-switch. I have to hard-reboot my machine to get it working again. I feel that this is a acpi_power_video bug but not a radeon bug, because there has been no changes in the radeon drm source between 3.18 rc3 and 3.18 rc4. lspci output: swoorup@arch ~ % lspci | egrep -i 'vga|display' 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7520G] I have attached the dmesg log before and after suspend-resume cycle using version 3.18 rc3, if it helps. Please let me know if there is any further information I can provide.
Created attachment 157251 [details] dmesg log after suspend-resume [kernel 3.18rc3]
Created attachment 157261 [details] dmidecode output
I have to add that this is rather a strange bug, just now I tested the quirk and again its working fine with 3.18 rc4. I think the bug occurs randomly. However is it possible to get the quirk patched upstream for ASUS K55N laptops?
It's not clear that if the system survived the resume for 3.18 rc4. If you press the NumLock key, does the indicator get lighted? Or can you ssh to the laptop in this case? The fact that you have to set acpi_video_flags=3 means your GPU driver isn't capable of resuming the graphics card, are you using DRM raedon driver with modeset enabled?
The system does not respond after resume at that time. No change on NumLock and yes I am using radeon DRM driver with modeset enabled.
That means the system doesn't resume back, it's not only a backlight issue. Take a look at this document: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt, then do some testing. Basically, you can do: # cd /sys/power # echo devices > state # echo mem > state See if system gets back. And with modeset enabled, the graphics card should be resumed by the GPU driver so you should not need set the acpi_video_flags to get the screen on, it feels something is wrong with the GPU driver to me.
ping...
please build a kernel without graphics driver, and do suspend/resume in console mode, does the problem still exist?
piing...
(In reply to Zhang Rui from comment #8) > please build a kernel without graphics driver, and do suspend/resume in > console mode, does the problem still exist? Sorry about the late reply. Got busy on work. I just compiled the mainline kernel and commented out the radeon module. Suspend/Resume the machine without the radeon module results in blank screen again same as before. I didn't enable the acpi_video_flags=3 flag. Looks like radeon module has nothing to do with this bug, Regards Swoorup
Since this is a regression, please do a git bisect to find the offending commit, thanks.
(In reply to Aaron Lu from comment #11) > Since this is a regression, please do a git bisect to find the offending > commit, thanks. Sorry, I think this is not a regression. The blank screen on suspend/resume issue could be fixed by applying the acpi_video_flags=3 flag. I have fixed my title and bug report. However, on some latest kernels this quirk sometimes work and sometimes doesn't. I did try testing the suspend/resume on older kernel such as 3.8 but it still results in blank screen without the quirk. I am wondering whether this quirk can be permanently applied to the kernel upstream?
My understanding is that this quirk is used to call video BIOS during early resume to bring up the display and is used when GPU driver is in user space. Since we have in kernel GPU driver this task is handled by GPU drivers. If your display didn't get up after resume, that probably means the GPU driver has a bug. I suggest we have a GPU people to take a look at this problem first.
All right sure, Just noticed the bug has been moved to non-intel dri section. I will just wait in that case. Appreciate you guys taking time to resolve this issue.
*** Bug 80851 has been marked as a duplicate of this bug. ***