Screen stays black after suspend with AMD Fusion APUs and fglrx driver

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1082851

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.7 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc6-raring/

I installed kernel 3.7rc7 and I downloaded fglrx 12.10 from the amd website.
I used this patch, http://catalyst.apocalypsus.net/files/arch-fglrx-3.7.patch, to patch it for the 3.7 kernel.
Also version.h from the kernel needs to be symlinked to a different location (otherwise building dkms module fails):

ln -s /usr/src/linux-headers-3.7.0-030700rc7-generic/include/generated/uapi/linux/version.h /usr/src/linux-headers-3.7.0-030700rc7-generic/include/linux/version.h

After this fglrx installs fine, and suspend works like it is supposed to do.

step by step instructions for those who can't wait till an official solution:
http://askubuntu.com/questions/224663/how-to-patch-fglrx-for-installation-on-kernel-3-7rc7/224664#224664

Used the instructions provided by Gerhard Burger on Asus Eee PC 1215B (only the kernel was 3.7.0-030700rc8 i386). Closed the lid a few times, and it hung again. Had to remove battery for a while to make it boot-up properly.

Disclaimer: I am not sure if it is wise to use all the flags listed below as they may damage your computer and/or data. In other words, *do this at your own risk*...

Here's what has made my resumes work every time (so far dozens of resumes since last failed one, including some really adventurous, like suspending in a middle of a 3D program running and resuming just fine):

*Kernel 3.2.0-33 lowlatency (I don't think lowlatency is necessary but I use this computer for audio work so it is a must for me);
*Ubuntu 12.04;
*fglrx 12.11 beta11 driver (released on Dec. 3rd, 2012, which fixed all sporadic "ASIC hang happened" kernel panics for me, no patching was necessary to build a working dkms), and
*Boot kernel flags: quiet splash threadirqs acpi_sleep=s3_bios,s3_mode,old_ordering,nonvs,sci_force_enable pci=nocrs hpet=disable

I don't think I need all the flags in acpi_sleep, so one would need to weed out ones that don't matter, but out of desperation I added them all just to see. I know that s3_bios flag alone made things a bit better but not 100% (using that alone I had approx. 1 in 10 resumes freeze). But the latest flags pci and hpet have made it perfect (at least so far) on HP dm1z with AMD APU (HD6310).

If this holds up then my notebook has everything working (finally!), like it should :-)

P.S. Things I also tried, so others don't bother with, are:

*changing sleep scripts by adding 2 second delays and/or disabling them altogether;
*switching to virtual console 1 and back (via script by calling chvt 1 and chvt 7 respectively) during suspend (both going back and forth during single action and going to 1 right before suspending and back to 7 when resuming)
*using custom script and variations thereof that is currently floating online (20_custom_ehci-hcd) and moving things around in there
*trying to switch to metacity before suspending (via script) and then reverting to compiz

Forgot to mention, threadirqs flag is used to prioritize audio irqs and I don't think it has anything to do with the fix (likely neither quiet or splash do, but I haven't checked for sure).

Also, can anyone else confirm if this works for them as well? I had another freeze but am not sure if that was because of me tweaking things (which I have been trying to find the core fix), or whether I simply made the problem less pronounced...

I also had to add snd_hda_intel to the list of suspend modules to avoid artifacts in audio upon resume (they would go away fairly quickly but still, this seems to work better).

@Ivica: THis also works for me on the current kernel (3.2.0-34-generic), I will keep running this for a while to see if it is stable.

Used the instructions provided by Gerhard Burger on Asus Eee PC 1015BX. After a few suspends the computer hung again.

Used the instructions provided by Ivica and also after a few suspends the computer hung again.

@Ivica: Running with the flags `acpi_sleep=s3_bios,s3_mode,old_ordering,nonvs,sci_force_enable pci=nocrs` for some time now, seems completely stable. I don't need the pci=nocrs hpet=disable. Have not checked yet which flags for acpi_sleep I need.

Many thanks for the replies. As it turns out, my problems persist with various combination of scripts. They are sporadic but still present. I will try what @Gerhard has suggested and see if that makes any difference...

@Gerhard, are you using anything else (e.g. 20_custom_ehci-hcd script, or other modifications to the pm-suspend) apart from the flags posted above?

Still getting sporadic black screen on resume with Gerhard's combination, usually after having loaded a couple applications, including ones that are more resource hungry...

OK, so I just tried something entirely different. My grub options now look as follows:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs acpi_osi=Linux"

Now the resumes work without any of the other options and I've had a couple of them so far without any problems. Of course, I will need to do more testing but it seems that by informing BIOS that you're running Linux suspend appears to work without any additional workarounds/fixes (at least so far). My hardware is HP dm1z with ADM HD6310 APU, more specifically model dm1-4142nr.

I also learned today that you can spoof BIOS to think you are running Windows by passing kernel acpi_os_name option as apparently some BIOSes only enable all the necessary options if they detect "genuine" Windows running... How sad... But I digress... What I am trying to say is that this will be my next test in case acpi_osi fails.

acpi_osi=Linux also works for me

It seems for me nothing works... Yes, all these flags work for a couple of suspends and then eventually suspend fails to resume. It seems that acpi_osi=Linux (or any other OS variant) acpi=s3_bios pci=nocrs gives me the greatest mileage on average but all of them eventually fail. This means I could be fine for a day or two (up to 10-15 suspends) and then the thing will fail. In some configs, the suspend fails at suspend-time rather than resume.

I even went as far as trying to decompile dsdt (as per instructions provided online, see: https://wiki.archlinux.org/index.php/DSDT), fixed all the errors (there were several errors and warnings, courtesy of HP's lousy service), and recompiled with zero errors and warnings and then recompiled the kernel with the custom dsdt and still nothing. The behavior remains the same...

I also tried changing over to uswsusp package and while it seems faster at suspending/resuming (most of the time), it fails exactly the same way (eventually after several suspends).

At this point I am wondering what the heck is wrong. Can any kernel dev chime in here? Is this due to the fact that AMD APUs are still failry new, is it the fglrx driver, or something entirely different?

One thing to add (remind of) is that I am using latest lowlatency kernel. Could this have anything to do with it?

Gerhard Burger, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>