Bug 88031

Summary: S3 resume fails using acpi video quirk
Product: Drivers Reporter: swoorupj
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: ASSIGNED ---    
Severity: normal CC: aaron.lu, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.18 rc4 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg log before suspending [kernel 3.18rc3]
dmesg log after suspend-resume [kernel 3.18rc3]
dmidecode output

Description swoorupj 2014-11-11 11:25:25 UTC
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.
Comment 1 swoorupj 2014-11-11 11:26:29 UTC
Created attachment 157251 [details]
dmesg log after suspend-resume [kernel 3.18rc3]
Comment 2 swoorupj 2014-11-11 11:27:42 UTC
Created attachment 157261 [details]
dmidecode output
Comment 3 swoorupj 2014-11-11 11:39:25 UTC
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?
Comment 4 Aaron Lu 2014-11-17 05:33:25 UTC
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?
Comment 5 swoorupj 2014-11-18 03:22:04 UTC
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.
Comment 6 Aaron Lu 2014-11-18 04:31:56 UTC
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.
Comment 7 Zhang Rui 2014-12-01 07:25:48 UTC
ping...
Comment 8 Zhang Rui 2014-12-01 07:28:53 UTC
please build a kernel without graphics driver, and do suspend/resume in console mode, does the problem still exist?
Comment 9 Zhang Rui 2014-12-08 06:45:41 UTC
piing...
Comment 10 swoorupj 2014-12-11 07:11:48 UTC
(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
Comment 11 Aaron Lu 2014-12-11 07:18:19 UTC
Since this is a regression, please do a git bisect to find the offending commit, thanks.
Comment 12 swoorupj 2014-12-11 07:39:49 UTC
(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?
Comment 13 Aaron Lu 2014-12-11 07:44:31 UTC
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.
Comment 14 swoorupj 2014-12-11 07:56:05 UTC
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.
Comment 15 swoorupj 2014-12-11 08:09:11 UTC
*** Bug 80851 has been marked as a duplicate of this bug. ***