Resume from suspend fails with FGLRX

Bug #84991 reported by scarecrow on 2007-02-13
44
Affects Status Importance Assigned to Milestone
xserver-xorg-driver-ati
Confirmed
Unknown
linux-restricted-modules-2.6.20 (Baltix)
Undecided
Unassigned
linux-restricted-modules-2.6.20 (Ubuntu)
Undecided
Unassigned
linux-restricted-modules-2.6.22 (Baltix)
Undecided
Unassigned
linux-restricted-modules-2.6.22 (Ubuntu)
Undecided
Unassigned

Bug Description

Running Feisty with all updates and using latest xorg-fglrx-driver on an ATI X700 graphics card. Laptop will suspend via buttons on power manager or when closing the the laptop, however, it will not resume from suspend to ram. All I get is a black screen and only a hard reboot via power switch will bring it back.

FIX

Successful sleep state is obtained by setting by modifying options in
/etc/default/acpi-support

Options for ATI X700:

SAVE_VBE_STATE=false
POST_VIDEO=true
USE_DPMS=false

Options for ATI X1300:

POST_VIDEO=false

scarecrow (bray) wrote :

Here is the output of dmesg and lspci.

scarecrow (bray) wrote :
Matt Zimmerman (mdz) wrote :

This is either a problem with the Linux kernel or with the fglrx driver. Can you try the vesa driver?

I get this, too. I have a Dell Inspiron 6400 w/Mobility Radeon X1400. I'm currently running FGLRX, but I'll try vesa.

I can't test with the vesa drivers... see Bug #85002.

Tried with the vesa driver--machine will resume. So its the fglrx driver?

Matt Zimmerman wrote:
> This is either a problem with the Linux kernel or with the fglrx driver.
> Can you try the vesa driver?
>
>

I also have problem with resume using the newest fglrx driver (version 8.33.6) on Feisty.
Resume works with the vesa driver and the fglrx driver used in Edgy (version 8.28.8)

FrejSoya (frej) wrote :

same

Other info:
suspend/resume only works after unloading fglrx driver.
This is tested from terminal with 'pmi action suspend' (No X11)

I've posted to ATI's "Linux Crew Driver Feedback Program" (http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&type=web)... hopefully they'll have somebody look at this issue.

Suspend to RAM is a really, really important feature for a lot of people. If nobody that uses Ubuntu with ATI drivers can recover from suspend... that's bad. That's really bad. In fact, it meets the definition of High imporance:

"Has a moderate impact on a large portion of Ubuntu users (estimated)" (from the <a href="https://wiki.ubuntu.com/Bugs/Importance">Ubuntu wiki</a>).

So, what's gonna happen here? If ATI doesn't fix this before April, we really need to revert to an older driver that doesn't exhibit this behaviour.

Seriously, it's getting embarrassing. I unplug my laptop and carry it to a meeting, at which point it's dead. What do the others at the meeting think?

"Gee, Linux doesn't seem very robust."

So, can we revert back to 8.28.8, or whatever the last version of FGLRX that worked is?

Lars Lunde (lars-lunde80) wrote :

I have been using version 8.28.8 (Edgy version) for a couple of weeks now.
With this version suspend/resume works every time.

I believe ati has released the 8.34.8 driver which they report fixed the
resume from suspend issue. However, it is listed as not compatible with
the 2.6.20 kernel, hence I cannot build the kernel modules using the
standard procedure at this point. Hopefully this will be resolved and
perhaps it can then make it into the feisty repositories.

Also, I cannot get the 8.28.8 to build on feisty and the package from
edgy does not work.

Alfredo Matos (alfmatos) wrote :

Could you try editing the following file, and the mentioned changes:

/etc/default/acpi-support

POST_VIDEO=true
to
POST_VIDEO=false

And then test if it works ?

Yes! My video hardware comes alive after rebooting!!

Alfredo Matos (alfmatos) on 2007-03-05
description: updated
scarecrow (bray) wrote :

The suggest fix did not work on my machine. I have a Mobile Radeon X700
with Radeon Xpress 200P chipset.
> ** Description changed:
>
> Running Feisty with all updates and using latest xorg-fglrx-driver on an
> ATI X700 graphics card. Laptop will suspend via buttons on power manager
> or when closing the the laptop, however, it will not resume from suspend
> to ram. All I get is a black screen and only a hard reboot via power
> switch will bring it back.
> +
> + Fix:
> + In /etc/default/acpi-support replace
> + POST_VIDEO=true
> + by
> + POST_VIDEO=false
>
>

Alfredo Matos (alfmatos) on 2007-03-05
description: updated
Alfredo Matos (alfmatos) wrote :

Can you check what's going on in gnome-power-manager ?

killall -9 gnome-power-manager

gnome-power-manager --no-daemon --verbose > g-p-m.log

And then please report back with what is going on.

Changed in linux-restricted-modules-2.6.20:
status: Confirmed → Needs Info
scarecrow (bray) wrote :
Download full text (6.7 KiB)

Done. The g-p-m.log file came up empty. I am attaching the output from
terminal.

Alfredo Matos wrote:
> Can you check what's going on in gnome-power-manager ?
>
> killall -9 gnome-power-manager
>
> gnome-power-manager --no-daemon --verbose > g-p-m.log
>
> And then please report back with what is going on.
>
> ** Changed in: linux-restricted-modules-2.6.20 (Ubuntu)
> Status: Confirmed => Needs Info
>
>

merlin@merlin:~$ gnome-power-manager --no-daemon --verbose > g-p-m.log
[gpm_debug_init] gpm-debug.c:217 (12:26:21): Verbose debugging enabled
[main] gpm-main.c:205 (12:26:21): GNOME Power Manager 2.17.92

(gnome-power-manager:5702): Gtk-WARNING **: Theme directory 96x96/action of theme Human_Ultra_Red2 has no size field

[gpm_proxy_connect] gpm-proxy.c:101 (12:26:21): emitting proxy-status TRUE: org.freedesktop.Hal
[gpm_proxy_connect] gpm-proxy.c:101 (12:26:21): emitting proxy-status TRUE: org.freedesktop.Hal
[gpm_control_init] gpm-control.c:855 (12:26:21): Using a supressed policy timeout of 5 seconds
[gpm_refcount_add] gpm-refcount.c:101 (12:26:21): refcount now: 1
[gpm_refcount_add] gpm-refcount.c:102 (12:26:21): non zero, so sending REFCOUNT_ADDED
[gpm_power_refcount_added] gpm-power.c:138 (12:26:21): Data is now not trusted
[gpm_hash_new_kind_cache] gpm-power.c:1676 (12:26:21): creating cache
[gpm_hash_new_device_cache] gpm-power.c:1710 (12:26:21): creating cache
[gpm_warning_init] gpm-warning.c:260 (12:26:21): Using per-time notification policy
[gpm_proxy_connect] gpm-proxy.c:101 (12:26:21): emitting proxy-status TRUE: org.freedesktop.Hal
[gpm_cpufreq_set_governor] gpm-cpufreq.c:191 (12:26:21): Doing SetCPUFreqGovernor (ondemand)
[gpm_cpufreq_set_consider_nice] gpm-cpufreq.c:506 (12:26:21): Doing SetCPUFreqConsiderNice (0)
[gpm_cpufreq_set_performance] gpm-cpufreq.c:126 (12:26:21): Doing SetCPUFreqPerformance (85)
[gpm_proxy_connect] gpm-proxy.c:101 (12:26:21): emitting proxy-status TRUE: org.gnome.ScreenSaver
[gpm_idle_set_check_cpu] gpm-idle.c:306 (12:26:21): Setting the CPU load check to 0
[gpm_manager_init] gpm-manager.c:1564 (12:26:21): creating new inhibit instance
[gpm_manager_init] gpm-manager.c:1575 (12:26:21): creating new control instance
[gpm_manager_init] gpm-manager.c:1585 (12:26:21): creating new tray icon
[gpm_manager_init] gpm-manager.c:1594 (12:26:21): initialising info infrastructure
[gpm_hal_enable_power_save] gpm-hal.c:1397 (12:26:21): Doing SetPowerSave (0)
[gpm_hal_enable_power_save] gpm-hal.c:1404 (12:26:21): ERROR: No powersave method found
*** WARNING ***
[gpm_hal_enable_power_save] gpm-hal.c:1409 (12:26:21): SetPowerSave failed!
[gpm_idle_set_system_timeout] gpm-idle.c:357 (12:26:21): Setting system idle timeout: 0
[get_stock_id] gpm-tray-icon.c:680 (12:26:21): Trying CRITICAL icon: primary, ups, mouse, keyboard
[get_stock_id] gpm-tray-icon.c:704 (12:26:21): Trying CHARGING icon: primary, ups
[get_stock_id] gpm-tray-icon.c:721 (12:26:21): Trying PRESENT icon: primary, ups
[get_stock_id] gpm-tray-icon.c:736 (12:26:21): Using fallback
[gpm_tray_icon_sync] gpm-tray-icon.c:763 ...

Read more...

Lars Lunde (lars-lunde80) wrote :

Yes!

It works for me too...

ATI MOBILITY FireGL V5200

Alfredo Matos (alfmatos) wrote :

> merlin@merlin:~$ gnome-power-manager --no-daemon --verbose > g-p-m.log

Well, guess g-p-m uses stderr:

Try instead: $ gnome-power-manager --no-daemon --verbos &> g-p-m.log

After having g-p-m running, suspend the laptop. Then check the file for errors. If you
need to paste the entire log file, please use the attachment tool.

Alfredo Matos (alfmatos) wrote :

$ gnome-power-manager --no-daemon --verbose &> g-p-m.log

(had a typo)

scarecrow (bray) wrote :

Okay, used the last command idea
gnome-power-manager --no-daemon --verbose &> g-p-m.log

Now there is output to the log file; not very interesting. Attached. I have also attached the part of syslog.

scarecrow (bray) wrote :

Whoops, here is the syslog-part

Check out Bug #42490 and https://help.ubuntu.com/community/NvidiaLaptopBinaryDriverSuspend... it looks like the POST_VIDEO option also messes up the NVidia binary driver.

Alfredo Matos (alfmatos) wrote :

Nice catch.

If that doesn't work, i can only assume that it is X700 specific. I would recommend that you take the following steps:

1. Try the new driver release 8.34.8 and see if it works. You can find information on how to install here: http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide

2. If nothing works, file an issue on the ATI Customer Care as already shown on this thread, or even on the unofficial bug report database http://ati.cchtml.com/

Other than this, we should probably close this bug, since it is a binary driver and cannot be fixed in Ubuntu.

I disagree with closing this bug. If an updated version of the driver exists, with a kernel patch to fix it with 2.6.20, then these should find their way into feisty ASAP.

Alfredo Matos (alfmatos) wrote :

We should probably open a UVF Exception.

Alfredo Matos (alfmatos) wrote :

Submited an UVF Exception see Bug #90961

Feel free to edit/add/comment on it.

Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
Alfredo Matos (alfmatos) on 2007-03-11
Changed in linux-restricted-modules-2.6.20:
status: Needs Info → Confirmed
scarecrow (bray) wrote :

With today's updates to Feisty, kernel 2.6.20.10 and fglrx 8.34.8, resume from suspend still failed with Post_Video =false or true, although with it true, resume would partial occur--screen would go light grey and then fade to black.

I now have in my /etc/default/acpi-support the following:

SAVE_VBE_STATE=false

POST_VIDEO=true

USE_DPMS=false

and the laptop suspends and resumes quite fine.

Alfredo Matos (alfmatos) on 2007-03-14
description: updated
Alfredo Matos (alfmatos) wrote :

Added these findings to http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide and to the upstream bug report, so that users can find them, not just here.

Resume from suspend was also broken in my Acer Travelmate 4021 with intel915 feisty beta

 although i dont use fglrx (card is not ATI) workaround suggested by scarecrow fixed this problem...seems that was something more general....

A lot of thanks :-)

I have a major regression (no changes to /etc/default/acpi-support help)... I'll try again with today's kernel updates.

No help from today's kernel updates... my X1300 gives a blank screen on resume.

Bono Lv (bonolv) wrote :

my card is x1300 mobille for ThinkPad R60

SAVE_VBE_STATE=false
POST_VIDEO=false
USE_DPMS=false

work for me , but haven't comprehensive test.

Still no joy on my X1400 (not X1300, as I said above). Is this likely to be fixed before Feisty comes out?

Greg Toombs (greg-toombs) wrote :

I can confirm that I have had a similar problem of failure to resume from suspend, and changing POST_VIDEO to false and SAVE_VBE_STATE to false fixed it. I have a Toshiba A100 laptop with ATI graphics.

So, given the date, it doesn't look like resume-from-suspend-to-RAM will work with my hardware (X1400) on Feisty. Is there any way to roll back to an earlier FGLRX using Feisty (kernel 2.6.20), or do I need to downgrade my whole system to Edgy?

Franz (franz-weiss-vr-web) wrote :

I use an ATI Mobility FireGL V5200 on a Fujitsu-Siemens CELSIUS Notebook Model H240.

SAVE_VBE_STATE=true [ is default ]
POST_VIDEO=false [ is changed ]
USE_DPMS=true [ is default ]

work on my Kubuntu-Feisty Installation with kdm as Display Manager.

hobbes (hobbes-poukram) wrote :

Bug confirmed on ATI X1600 mobile (on ASmobile S96J laptop), works with POST_VIDEO=false in /etc/default/acpi-support

RavanH (ravanhagen) wrote :

Have the same issue on Feisty AMD64 (kernel .15) with ATI Radeon Xpress 200M on Packard Bell EasyNote R3450 motherboard, and using the latest ATI drivers (8.36.5).

Tried about every option changed in /etc/default/acpi-support (inluding ACPI_SLEEP_MODE=mem > standby and HIBERNATE_MODE=shutdown > platform) without any satisfying results...

Anybody signed this petition yet: http://www.petitiononline.com/x200MLin/petition.html ?

Is this at all related to Bug #11919?

mehturt (mehturt) wrote :

I had this problem, but the POST_VIDEO=false works for me.
My NB is Toshiba Sattellite M100-222 with ATI X1400. I'm using Kubuntu Fiesty.

Simon Hepburn (sth) wrote :

I have the same issue, though in my case resume fails to work with either the open source ati driver or the binary fglrx driver so maybe this is a different problem. Hardware is a Compaq Evo 510 desktop and a Radeon 9550 [RV350 AS] AGP card. Additionally I cannot switch to Console mode and have to reboot. I have tried the two variations on /etc/default/acpi-support described above without success.

Resume works if I use the vesa driver. It also worked fine previously when I was using the onboard intel 845 graphics. Both with an unmodified /etc/default/acpi-support.

Simon Hepburn (sth) wrote :

The problem with the Xorg ati driver appears to be a separate issue. If I disable dri resume works fine. Will add comment to <a href="/bugs/23545"> #23545</a>. Disabling dri has no effect on resuming from standby with the fglrx driver. Still stuck with that one.

FrejSoya (frej) wrote :

As a follow up...
on feisty:

fglrx 8.36.5 +

SAVE_VBE_STATE=false
POST_VIDEO=false
USE_DPMS=true
works for me...

MacBook Pro with core duo 1

G. Wang (ek-lem) wrote :

Still doesn't work for me, on my laptop Dell E1505/6400, Core Duo T2300E, ATI X1300, BIOS version A14. The POST_VIDEO=false trick doesn't do it. The last time this trick worked was with Feisty Beta version, but has stopped working since the final release. I always get a blank screen on resume, keyboard partially works in that I can turn the capslock on and off, but that's it. I have tried fglrx in the repo 8.34 and also manually tried 8.36, none of them worked. I have always tried a variety of different settings in acpi-support file, and none helps, this is really getting pretty frustrating.

Daniel (elenius) wrote :

POST_VIDEO=false

also solves the problem for me, on a x1400 (Thinkpad z61m).

Wolfgang Glas (wglas) wrote :

I experience a slightly different problem on my IBM T42p laptop. Resume works fine aforehand, but starting a GLX-Application causes kernel corruption, display totally frozen, hard power-off is my only solution. googlearth is crashing after suspend/resume, glxgears freeze my display eternally...

Chipset, as reported in /var(log/Xorg.0.log

(--) fglrx(0): Chipset: "ATI MOBILITY FIRE GL T2/T2e" (Chipset = 0x4e54)

Why the hell is ATI unable to deliver a fully functional Linux driver after all these years? susepnd/resume is part of the kernel driver API for at least 2 years now...

Eddie Hung (eddieh) wrote :

I'm on Feisty 32 bit, using the feisty repos fglrx drivers, and suspend does not work for me. I have an ATI x800, and a nForce2 motherboard, on a desktop.
I have tried various combinations of options, with and without:
MODULES_WHITELIST="fglrx"
POST_VIDEO=false
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=true
SAVE_VBE_STATE=true
all to seemingly no avail.
It seems to suspend successfully (monitors turn off due to no signal), but then it does not awake again (monitors stay off).
I have also tried various combinations of options for hibernate too, and that doesn't seem to work either.

Eddie Hung (eddieh) wrote :

Another question: does editing /etc/default/acpi-support require a restart before the change takes effect? (and if this is yes - I've just noticed that /etc/init.d/acpid and /etc/init.d/acpi-support both exist - could you avoid a full restart by just restarting these? Not that it really makes a difference - seeing as my computer hard locks up most of the time whilst testing this anyway!)

Premier (premiersullivan) wrote :

I made the changes to to acpi-support and the computer started working instantly, no reboot, in response to Eddie. I suggest future distrubutions of xorg-driver-fglrx edit this file to correct the issue automatically until the fglrx driver works correctly.

Vaidotas Zemlys (mpiktas) wrote :

OK, I can confirm on Feisty 32 with ATI x1700 when setting

SAVE_VBE_STATE=false
POST_VIDEO=false
USE_DPMS=false

suspend is working. Other combinations results in hanging after trying to resume.

Mikey Cooper (mikey-bluey) wrote :

Issue happens for me on Feisty with an RV530 Radeon x1600 card in my desktop. When resuming from suspend, monitor remains black system is unresponsive. Trying all the various options listed above in acpi-support did not fix the issue for me.

TimMadden (timmadden) wrote :

I have an ATI Radeon Xpress 200M in my Toshiba A135-S2386 Laptop with the ATI driver 8.34.8 driver installed from the repository. I have tried the various options suggested above to no avail. It suspends ok, but the display does not come back when I resume. Hibernate seems to work ok.

Erik Meitner (e.meitner) wrote :

I'm curious to know if for those people who can suspend and resume, is DRI enabled? I can only suspend if I disable the fglrx drivers using the restricted manager and then reinstall xorg-driver-fglrx. This allows me to run fglrx without the kernel module thus preventing DRI from working. Without DRI the system suspends just fine. Of course video performance is awfull...

Do:
$ grep 'WW..fgl' /var/log/Xorg.0.log
and look for:
    (WW) fglrx(0): * DRI initialization failed! *
If you see this you do not have DRI.

Daniel (elenius) wrote :

DRI and suspend/resume works for me.

On 7/21/07, Erik Meitner <email address hidden> wrote:
>
> I'm curious to know if for those people who can suspend and resume, is
> DRI enabled? I can only suspend if I disable the fglrx drivers using the
> restricted manager and then reinstall xorg-driver-fglrx. This allows me
> to run fglrx without the kernel module thus preventing DRI from working.
> Without DRI the system suspends just fine. Of course video performance
> is awfull...
>
> Do:
> $ grep 'WW..fgl' /var/log/Xorg.0.log
> and look for:
> (WW) fglrx(0): * DRI initialization failed! *
> If you see this you do not have DRI.
>
> --
> Resume from suspend fails with FGLRX
> https://bugs.launchpad.net/bugs/84991
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

scarecrow (bray) wrote :

I am now testing Gutsy on the same machine; ATI Radeon Express 200P chipset, X700 graphics card. Again using the fglrx driver that comes with Gutsy (8.37.6). I consider the behavior to be a regression. Upon suspend to ram or disk, the screen goes blank with a blinking cursor and nothing but a hard reboot will bring it back. In other words, the machine will not even suspend or hibernate in the development release.
If I use the vesa driver, suspend and resume both work, although a message pops up on resume giving a error that the machine failed to resume (even though it did). This system won't work with the open source ati drivers.

I tried building the latest ATI driver with no success. I also attempted to apply the debugging scheme given at https://wiki.ubuntu.com/DebuggingKernelSuspend
however nothing was learned (No Magic number line in the output).

Am attaching the output of lspci and dmesg.

Any thoughts?

xtknight (xt-knight) wrote :

Same here with NVIDIA proprietary drivers. Maybe it only happens with prop. drivers?

krammer (erickrengel5) wrote :

Has anyone else tried this in Gutsy? I'm on Kubuntu Fiesty with x700. This worked when DRI was disabled:

SAVE_VBE_STATE=false
POST_VIDEO=true
USE_DPMS=false

But since I got DRI working, it is back to the blank screen.

Although, what I seem to have different from everyone else is a Merged FB setup, and only 1 of my monitors blanks out, which is my LCD tv. If i fake change the resolution and put it back to how it was and hit apply, I can get the monitor to come out of suspend without rebooting or restarting X.

ScislaC (scislac) wrote :

Gutsy w/ stock fglrx 8.37 (and running xserver-xgl) - I can confirm that my system hangs on suspend or hibernate (therefore resume does not work).

Changed in linux-restricted-modules-2.6.22:
status: New → Confirmed

Ditto for the new 8.42.3: it hangs on suspend (whether I use KDE
suspend, /sbin/hibernate-ram, echo mem > /sys/power/state, etc.).

Changed in xserver-xorg-driver-ati:
status: Confirmed → Unknown

The Gutsy suspend issue is probably Bug #121653. FGLRX doesn't support 2.6.23, which could really mean "doesn't support the new SLUB allocator" (which Ubuntu uses in 2.6.22).

On resuming from suspend (I compiled a SLAB kernel, so now I'm past Bug #121653), I get these lines:

Oct 24 11:59:59 nick kernel: [ 7358.636000] [fglrx:firegl_addmap] *ERROR* existing map 0xdfb56000 (handle 0xf8eb1000)
Oct 24 11:59:59 nick kernel: [ 7358.636000] [fglrx:firegl_addmap] *ERROR* existing map 0xc190f080 (handle 0x00000000)
Oct 24 11:59:59 nick kernel: [ 7358.636000] [fglrx:firegl_addmap] *ERROR* existing map 0xdf889d00 (handle 0xf8ee0000)
Oct 24 12:06:48 nick kernel: [ 7767.400000] [fglrx:firegl_addmap] *ERROR* existing map 0xdfb56000 (handle 0xf8eb1000)
Oct 24 12:06:48 nick kernel: [ 7767.400000] [fglrx:firegl_addmap] *ERROR* existing map 0xc190f080 (handle 0x00000000)
Oct 24 12:06:48 nick kernel: [ 7767.400000] [fglrx:firegl_addmap] *ERROR* existing map 0xdf889d00 (handle 0xf8ee0000)

firegl_addmap is in the binary blob... could this have something to do with my problem?

Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
Yan Li (yanli) wrote :

With the launch of PPA (Personal Package Archive) service, is it possible for us to build and release a community-supported customized Kernel with SLAB enabled just for ATi users? With PPA, we can easily set up a apt source for it and leverage community forces to build/test this custom Kernel and future updates.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.