Bug 43829

Created attachment 55194 [details]
difference of `radeontool regmatch \*` from before and after suspend

HP G4-1215DX with an A4-3300 APU here.  Everything comes back but the display on a resume from a suspend.  I can ssh into the machine and get any kind of debugging info needed.

Created attachment 55303 [details]
difference of `radeonreg regs dce4` from before and after suspend

I have the full before and after dumps still if you need them also.

Do these patches help?
http://people.freedesktop.org/~agd5f/dce_fixes/

against drm-next or Linus' git.

No- these patches leave my screen dark after KMS kicks in.

Same for me - black screen.

*** Bug 49281 has been marked as a duplicate of this bug. ***

*** Bug 53657 has been marked as a duplicate of this bug. ***

*** Bug 54484 has been marked as a duplicate of this bug. ***

This should be fixed in my drm-next-3.7-wip branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip

(In reply to comment #10)
> This should be fixed in my drm-next-3.7-wip branch:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip

Just tried on Thinkpad E525 (see bug #54484), and it does *not* fix the issue ( it does however also not wedge the system as 3.6-rc3 did, in case you want would like any data collected or experiments performed).

Created attachment 67249 [details] [review]
testing patch

If my 3.7 branch by itself doesn't work, does this patch on top of my 3.7 branch help?  Please attach the output of dmesg after resume with this patch applied.

Created attachment 67252 [details]
t525-dmesg-patch-bug43829

(In reply to comment #12)
> Created attachment 67249 [details] [review] [review]
> testing patch
> 
> If my 3.7 branch by itself doesn't work, does this patch on top of my 3.7
> branch help?  Please attach the output of dmesg after resume with this patch
> applied.

attached (the added DRM_INFO yields "bl_level: 0xff" )

as an additional experiment, I used "kexec" after suspending to reboot the same kernel and let the radeon driver do a full reinitialization -- but even that fails to bring the display back to life :(

Anything further I can do?

I seem to be having this issue with A6-4400M (at least symptoms are all the same).

At first i thought that it's the same issue as #52256, but apparently it is not so simple.

I've tried merging http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=c49170742d6928b16fb3839b47a94cc41630dbe0 into current kernel master HEAD (it had 1 merge conflict, resolved it by sticking to the branch being merged in) and compiling&installing the resulting kernel - no luck.

Should i try attachment 67249 [details] [review] too and post the results?

A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit bced76f27165ca7733437715185c3a1aa526f7a1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 14 09:45:50 2012 -0400

    drm/radeon: restore backlight level on resume

(In reply to comment #15)
> A patch referencing this bug report has been merged in Linux v3.7-rc1:
> 
> commit bced76f27165ca7733437715185c3a1aa526f7a1
> Author: Alex Deucher <alexander.deucher@amd.com>
> Date:   Fri Sep 14 09:45:50 2012 -0400
> 
>     drm/radeon: restore backlight level on resume

appears to be the same patch as mentioned in comment #10, and (at least for me) still does not fix the issue

(In reply to comment #16)
> (In reply to comment #15)
> > A patch referencing this bug report has been merged in Linux v3.7-rc1:
> > 
> > commit bced76f27165ca7733437715185c3a1aa526f7a1
> > Author: Alex Deucher <alexander.deucher@amd.com>
> > Date:   Fri Sep 14 09:45:50 2012 -0400
> > 
> >     drm/radeon: restore backlight level on resume
> 
> appears to be the same patch as mentioned in comment #10, and (at least for
> me) still does not fix the issue

I have think i have same problem with a Radeon HD 6520G (AMD A6-3410MX), it have "nothing" with backlight to do, if i use a flashlight i can see the screen is 100% off.

I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M APU. I've attached dmesg and lspci output of my laptop.

Created attachment 73234 [details]
a10-4600m_lspci

Created attachment 73235 [details]
a10-4600m dmesg

(In reply to comment #18)
> I have the same problem with HP Pavilion g6-2137sr laptop with A10-4600M
> APU. I've attached dmesg and lspci output of my laptop.
P.S. Kernel version 3.7.3

Still getting this.
Linux kernel 3.8.0 (9e2d59ad580d590134285f361a0e80f0e98c0207)
xf86-video-ati 343b01c9bf35b125cd0c3df8db7c01a5fb227bda

I had a similar problem with my x700 (rv410) radeon, and fixed it with:
  radeontool light off 
  radeonreg regset 0x00000284 0x1bd34208 
  radeonreg regset 0x000002d0 0x003c00a1 
  radeonreg regset CL:03 0x001c0007 
  radeonreg regset CL:04 0x0002004a 
  radeonreg regset CL:05 0x0002004a 
  radeonreg regset CL:06 0x0002004a 
  radeontool light on

Have you guys tried the radeontool light thingy?

(In reply to comment #23)
> I had a similar problem with my x700 (rv410) radeon, and fixed it with:
>   radeontool light off 
>   radeonreg regset 0x00000284 0x1bd34208 
>   radeonreg regset 0x000002d0 0x003c00a1 
>   radeonreg regset CL:03 0x001c0007 
>   radeonreg regset CL:04 0x0002004a 
>   radeonreg regset CL:05 0x0002004a 
>   radeonreg regset CL:06 0x0002004a 
>   radeontool light on
> 
> Have you guys tried the radeontool light thingy?

Please file a separate bug for this, this should be handled properly in the driver.  These registers are only relevant for very old radeons so they don't apply to newer asics.

*** Bug 61470 has been marked as a duplicate of this bug. ***

Created attachment 82347 [details] [review]
possible fix

Does the attached patch help?

(In reply to comment #26)
> Created attachment 82347 [details] [review] [review]
> possible fix
> 
> Does the attached patch help?

Have just tested, and it dont change anything.
I still also don't know what it have to do with backlight? The screen is completely turned off, if I use a flash light I can see the screen is 100% off.

These problems seem similar to the bug I reported: https://bugs.freedesktop.org/show_bug.cgi?id=42162 . One common thread is that many of the affected machines are HP laptops. Maybe the HP ACPI implementation does something funny?

I've the same issue on my HP4545s laptop (A4-4300M CPU).
At boot time I get 
...
[drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller
...
then the computer boots and works just fine (except the brightness control is @ /sys/class/backlight/radeon_bl0/brightness, commonly unrecognizable by the software) but after resuming I have totally black screen. I can still ssh to it: it resumes normally - the only thing that goes wrong is the screen remains off. (It goes off as soon as the resume process begins). Kernels 3.9.X still have the issue.
I'm not sure the absence of the ACPI-controllable brightness is relevant to the case.

Created attachment 84275 [details] [review]
possible fix 1/2

Does this patch set fix the issue?

Created attachment 84276 [details] [review]
possible fix 2/2

Please apply both patches in this set.

(In reply to comment #31)
> Created attachment 84276 [details] [review] [review]
> possible fix 2/2
> 
> Please apply both patches in this set.

Unfortunately these patches do not help.

Created attachment 85691 [details]
dmesg+Xorg.0.log

Same bug here...
HP laptop (dv6-6174la), dual GPU:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] [1002:9647] (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (prog-if 00 [VGA controller])
Linux hostname 3.11.0-7-generic #13-Ubuntu SMP Tue Sep 10 20:55:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

workaround: use an external monitor (HDMI and VGA worked, with some problems though, but that is unrelated [you can see some warning and backtraces] and didn't happen before)

attached: whole dmesg, Xorg.0.log files after two consecutive suspend/resume cycles plus some testing with external monitors, and .diff files (from other session) showing messages logged only after suspend to RAM.

I have the exact same problem here but with a radeon HD 7310. I can try patches.

Sorry, I forgot to precise it was with kernel 3.11 and dpm activated.

(In reply to comment #32)
> (In reply to comment #31)
> > Created attachment 84276 [details] [review] [review] [review]
> > possible fix 2/2
> > 
> > Please apply both patches in this set.
> 
> Unfortunately these patches do not help.

same for me, the patches didn't work.

Created attachment 86031 [details]
dmesg, xorg

I installed 3.12-rc1 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc1-saucy/ , it didn't help :(
Attached are the logs from dmesg (before and after running pm-suspend) and Xorg.0.log (there were no messages after resuming from suspend)

I'm not sure if I have the same issue. In particular, I could not find this error in my dmesg:
..
[drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller
..

But I do have the issue that my laptop does not wake up fully (the screen is black).

There is some noise starts in the notebook and led indicators start blinking, but the screen does not turn ON.

I know, there are many possible reasons, but it worked with Catalyst, so, I think it has to be connected to video driver (dri, kms, xf86-video-ati, whatever..).

$ lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G]
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]

$ uname -a
Linux pilat-book 3.11.1-2-ARCH #1 SMP PREEMPT Sun Sep 22 19:45:00 CEST 2013 x86_64 GNU/Linux

I use radeon.dpm=1 in the kernel options;


Here's the bug-report to Archlinux tracker, but they suggested to file the bug here:
https://bugs.archlinux.org/task/37078

Same issue with me.  I have an HP with an A8-3550MX (6620G graphics).  This issue as plagued me (and I am sure others) for quite some time.  I have pretty much relegated myself to using the fglrx binary blob.

Any process? This is the most annoying thing about using Linux..

Same issue for my A8-450M laptop with Integrated or Discrete GPU set.
I made some tests from kernel 3.8.0 to 3.12-RC6 on Ubuntu.
I got same result with other distro like ArchLinux or Fedora.

# lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1
fh) Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinit
y [Radeon HD 7640G]

Some other tests on my main kernel 3.11.6 (Ubuntu PPA)
(CPU and GPU firmware has been updated to latest version)
 
 - After suspend and resume, with ssh I can check brightness control on /sys/class/blacklight/radeon_bl0/brightness and change the value but nothing change on screen (always black screen)
 - no syslog entry give information on the problem
 - no more information with drm.debug on kernel     
 - fglrx doesn't have the same problem, suspend and resume work fine
   (but fglrx don't allow to change brightness). 

So, this concern seems to come from the drm driver and not from kernel or acpi,
but I don't have enough knowledge to go further to identify the root cause in xorg

I'm using kernel 3.13-rc0 from: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2013-11-14-trusty/
3.12.0-996-generic #201311140516
and this is still happening...
I guess I'll have to go back to fglrx.
I wished I could help devs, but this is driving me crazy. Not being able to resume from suspend is why I wanted to test the open-source driver in the first place...

Same problem here running on a HP Laptop Pavillion G7 with AMD A6-3400M CPU/GPU.

Currently running 3.12.5 kernel from openSuse Tumbleweed, though ive had this problem for ages.

This bug is really old and really annoying as it makes the laptops unusable for suspend -- what kind of traces would be required to understand the core of the problem, from what I can tell the display engine is in a severely hosed state, but I lack documentation to understand what is wrong.

Does setting out a bounty for this bug help? I'm willing to immediately cash in at $300.

Any updates one this?
Kernel 3.14-rc6 + mesa 10.2-git (I tested it a couple weeks ago), still the same.
Any clues on where to look for bugs and/or how to debug?

(In reply to comment #45)
> Any updates one this?
> Kernel 3.14-rc6 + mesa 10.2-git (I tested it a couple weeks ago), still the
> same.
> Any clues on where to look for bugs and/or how to debug?

I also want a status on this. This is 1% to make Linux 100% perfect.

Kernel 3.14-rc8 (with PRIME) + mesa 10.2-git (radeon driver with kms and dpm)
Still the same issue, suspend + resume works fine but the laptop's screen does not turn back on. Using an external monitor confirms that the system itself is functional after resume. When running fglrx, there is no issue.
HP dv6z 6100 CTO QE (ca. 2011). CPU: AMD 18-3510mx, iGPU: Radeon HD 6620g, dGPU: Radeon HD 6750m.

I got the same issue here. 

After I suspend my machine and try to wake up, the screen does not display anything else. And I'd have to blindly switch to tty terminal and type reboot.

Info:
Linux 3.13.8-1 (Arch linux)
Mesa - 10.1.0

Radeon 7520G

I have a similar issue with a samsumg series 3 laptop with "VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external monitor show the system is still responsive.

BUT I can make the screen turn on after suspend with the next command:
sudo pm-suspend --quirk-test --quirk-s3-bios

so if you can try and this work maybe we can kick this issue.

(In reply to comment #49)
> I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> monitor show the system is still responsive.
> 
> BUT I can make the screen turn on after suspend with the next command:
> sudo pm-suspend --quirk-test --quirk-s3-bios

whoa, that worked as well for me! I'll try to dissect unless someone else jumps to it, and then make good on my promise above :)

maybe the same issue? https://bugs.freedesktop.org/show_bug.cgi?id=42960

also, isn't pm-utils somehow deprecated?
if we add the parameter in /etc/pm/config.d/ will the command "systemctl suspend" be able to turn on the screen? i think that "systemctl suspend" doesn't rely on pm-utils

(In reply to comment #51)
> maybe the same issue? https://bugs.freedesktop.org/show_bug.cgi?id=42960
> 
> also, isn't pm-utils somehow deprecated?
> if we add the parameter in /etc/pm/config.d/ will the command "systemctl
> suspend" be able to turn on the screen? i think that "systemctl suspend"
> doesn't rely on pm-utils

I looked in the pm-utils sourcecode, and adding acpi_sleep=s3_bios to the cmdline fix it for me.

You can read a little about it here: https://www.kernel.org/doc/Documentation/power/video.txt

Seems to work for me too.  I'm sure one of Alex's patches helped out too, so thank you Alex.

I do get this on resume, but that's probably for another bug:
[  117.375124] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[  117.375127] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E442 (len 2585, WS 4, PS 4) @ 0xEB2C
[  117.436913] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max voltage
[  117.436914] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

Awesome. To spell it out a little more explicitly, here is what I did (Arch x86_64 3.14-mainline) to have this apparently accomplished automatically from now on:

sudo su

echo 'ADD_PARAMETERS="--quirk-test --quirk-s3-bios"' >> /etc/pm/config.d/00-fix_dv6z_suspend_screen

pm-suspend --quirk-test --quirk-s3-bios --store-quirks-as-lkw

Which should save the quirks, perhaps with some redundancy. Checking the contents of the (new)

/etc/pm/last_known_working.quirkdb

file should show the matches made against your particular system, especially e.g. hardware and firmware details. I guess these could be patched into (for my HP at least)

/usr/lib/pm-utils/video-quirks/20-video-quirk-pm-hp.quirkdb

with some of the returned information, given that this file is supposed to have a fairly up-to-date {white,black,broken}-list.

Obviously follow this only at your own risk, etc. I have no idea how this would work when it comes to fglrx, or even how stable it is against kernel/pm/upower/whatever updates. Here are some more good references for information:

https://trisquel.info/en/wiki/troubleshooting-suspendhibernate

https://wiki.archlinux.org/index.php/pm-utils

(In reply to comment #49)
> I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> monitor show the system is still responsive.
> 
> BUT I can make the screen turn on after suspend with the next command:
> sudo pm-suspend --quirk-test --quirk-s3-bios
> 
> so if you can try and this work maybe we can kick this issue.

GREAT, it works for me, thank you very much!
I did try pm-suspend with different flags some months ago.. I guess my testing was too conservative :(
@ klausenbusk@hotmail.com and austin.hoppe7@live.com , thank you too! and once again, thanks AMD devs :)

(In reply to comment #54)
> Awesome. To spell it out a little more explicitly, here is what I did (Arch
> x86_64 3.14-mainline) to have this apparently accomplished automatically
> from now on:
> 
> sudo su
> 
> echo 'ADD_PARAMETERS="--quirk-test --quirk-s3-bios"' >>
> /etc/pm/config.d/00-fix_dv6z_suspend_screen
> 
> pm-suspend --quirk-test --quirk-s3-bios --store-quirks-as-lkw
> 
> Which should save the quirks, perhaps with some redundancy. Checking the
> contents of the (new)
> 
> /etc/pm/last_known_working.quirkdb
> 
> file should show the matches made against your particular system, especially
> e.g. hardware and firmware details. I guess these could be patched into (for
> my HP at least)
> 
> /usr/lib/pm-utils/video-quirks/20-video-quirk-pm-hp.quirkdb
> 
> with some of the returned information, given that this file is supposed to
> have a fairly up-to-date {white,black,broken}-list.
> 
> Obviously follow this only at your own risk, etc. I have no idea how this
> would work when it comes to fglrx, or even how stable it is against
> kernel/pm/upower/whatever updates. Here are some more good references for
> information:
> 
> https://trisquel.info/en/wiki/troubleshooting-suspendhibernate
> 
> https://wiki.archlinux.org/index.php/pm-utils

Hmm. I just did:
sudo nano /etc/default/grub
found GRUB_CMDLINE_LINUX_DEFAULT and added acpi_sleep=s3_bios just before quiet
ctrl+o and ctrl+x
sudo grub-mkconfig -o /boot/grub/grub.cfg

(In reply to comment #55)
> (In reply to comment #49)
> > I have a similar issue with a samsumg series 3 laptop with "VGA compatible
> > controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD
> > 6620G]" and "VGA compatible controller: Advanced Micro Devices, Inc.
> > [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]". after resume an external
> > monitor show the system is still responsive.
> > 
> > BUT I can make the screen turn on after suspend with the next command:
> > sudo pm-suspend --quirk-test --quirk-s3-bios
> > 
> > so if you can try and this work maybe we can kick this issue.
> 
> GREAT, it works for me, thank you very much!
> I did try pm-suspend with different flags some months ago.. I guess my
> testing was too conservative :(
> @ klausenbusk@hotmail.com and austin.hoppe7@live.com , thank you too! and
> once again, thanks AMD devs :)

I see now... I DID test the '--quirk-s3-bios' flag, but I need '--quirk-test', which is not documented in the manpage...

from pm-utils-1.4.1/README.debugging:
"* To override the usual quirk filtering (for kernel modesetting, binary drivers, and exotic hardware), pass --quirk-test along with any other quirks you want to try.  This may make your system crash in new and exciting ways by conflicting with the kernel when suspending or resuming, but is very useful for debugging.  You have been warned."
Oh, well, I'm happy that someone found a solution and shared it with us all :D

*** This bug has been marked as a duplicate of bug 42960 ***