[gutsy] fglrx breaks over suspend/resume

Bug #121653 reported by theanalogkid on 2007-06-22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.22 (Baltix)
linux-restricted-modules-2.6.22 (Ubuntu)
Declined for Gutsy by Brian Murray
Declined for Hardy by Bryce Harrington
linux-restricted-modules-2.6.24 (Ubuntu)
Declined for Gutsy by Brian Murray
Declined for Hardy by Bryce Harrington
linux-source-2.6.22 (Ubuntu)
Declined for Gutsy by Brian Murray
Declined for Hardy by Bryce Harrington

Bug Description

SLUB (the new kernel memory allocator delivered with Gutsy Gibbon) exposes a bug in fglrx that manifests itself as a failure over suspend/resume.

Note: This bug is sufficiently confirmed, please do not add new statements confirming it to the bug report.

00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
     Subsystem: Lenovo Unknown device [17aa:2015]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145] (prog-if 00 [VGA])
     Subsystem: Lenovo Unknown device [17aa:202a]

theanalogkid (mlyszczek) wrote :

2.6.20-16 dmesg.log

description: updated
description: updated
theanalogkid (mlyszczek) wrote :

2.6.22-6 dmesg

Although it seems nothing gets recorded that I suspended my machine in the dmesg.

theanalogkid (mlyszczek) on 2007-06-22
description: updated

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description doesn't yet have enough information.

Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks in advance!

Changed in linux-source-2.6.22:
assignee: nobody → amitk
status: New → Incomplete
theanalogkid (mlyszczek) wrote :

Linux matthew-laptop 2.6.22-6-generic #1 SMP Fri Jun 1 19:24:12 GMT 2007 i686 GNU/Linux

theanalogkid (mlyszczek) wrote :
theanalogkid (mlyszczek) wrote :

After further testing I narrowed it down to the fglrx module, but even using the latest drivers (8.38.6) it gives me problems under 2.6.22 but works flawlessly under 2.6.20.

Amit Kucheria (amitk) on 2007-07-17
Changed in linux-source-2.6.22:
assignee: amitk → nobody
laksdjfaasdf (laksdjfaasdf) wrote :

Same here on Thinkpad Z61m. Problem is maybe related with following bug:


theanalogkid (mlyszczek) wrote :

It might be, but I can't get it to suspend, let alone resume afterwards.

I am having the same problem on a IBM T41 after updating to gutsy.
Suspend-to-RAM worked fine in feisty, but after upgrading to gutsy tribe 4 suspend-to-RAM stopped working; the computer will not even suspend, it will stay in a semi-awake state (processor, fan etc. running, but screen is black). No response from pressing any keys (not even the Magic SysRq is responsive).
This happens no matter if I use the fglrx or the open source radeon driver.
Uname: Linux andreas-laptop 2.6.22-9-generic #1 SMP Fri Aug 3 00:50:37 GMT 2007 i686 GNU/Linux
Hardware configuration (lshw) is attached. What other information should I provide?

I have the same problem with the Gutsy suspend scripts, but I noticed that a simple echo mem >/sys/power/state works fine.

After the latest updates to the acpi, suspend-to-ram has started working for ma again on my IBM T42 (sorry, T41 in my last post was a typo).
acpi 0.09-3ubuntu1
acpid 1.0.4-5ubuntu8
acpi-support 0.96ubuntu1

Frank (frank-schaeffer) wrote :

Same here on Thinkpad Z61m with proprietary fglrx (tested with version 8.37.8 package from ubuntu as well as version 8.40.4 manually installed). Gutsy is up to date (64bit, Kubuntu but also tested with Ubuntu)
As suggested by Johan "echo mem > /sys/power/state" results in permission denied for both user action and sudo action, respectively. When I perform:
sudo -s
echo mem > /sys/power/state
the command results, metaphorically speaking, in a screen or better screenshot. The screen remains visible but the machine is lock down without the possibility of input or interaction. I've to perform a hard power off.

uname -r
Linux Newton 2.6.22-9-generic #1 SMP Fri Aug 3 00:20:35 GMT 2007 x86_64 GNU/Linux

Frank (frank-schaeffer) wrote :

And here the lspci

laksdjfaasdf (laksdjfaasdf) wrote :

Suspend to RAM works again, but with quirks! After resuming from suspend Gnome Power Manager shows a tooltip which says there where problems.

uanme -a:

Linux thinkubuntuz29 2.6.22-9-generic #1 SMP Fri Aug 3 00:50:37 GMT 2007 i686 GNU/Linux

What makes me wonder - in messages I have lots of audit error messages with missing access rights. I cut most of them out cause I do not want to show all my databases here in public.

Philipp Kern (pkern) wrote :

As I also own a Z61m but use Gentoo on it... I just tried an upgrade to 2.6.22, and I noticed just like [1] that the new SLUB allocator breaks fglrx. Reverting to SLAB fixes the problem for me and I can suspend/resume just fine.

Ubuntu sets CONFIG_SLUB=y in its generic 2.6.22 kernel. If this would be reverted to CONFIG_SLAB=y (instead of using still "experimental" code, although the problem probably lies in fglrx) suspend/resume should work again.

[1] http://lkml.org/lkml/2007/6/17/96

Frank (frank-schaeffer) wrote :

The issue is still there after kernel upgrade to on Gutsy 64bit. I've also tried the hacks from the Laptop Testing Team:

1. set POST_VIDEO=false instead of POST_VIDEO=true
2. set RADEON_LIGHT=true

But nothing works. The machine goes into sleep but the half-moon does not stop blinking. So I've to switch the power off hardly.

uname -a
Linux Thinkpad 2.6.22-10-generic #1 SMP Wed Aug 22 07:42:05 GMT 2007 x86_64 GNU/Linux

Frank (frank-schaeffer) wrote :

And at least the new dmesg.txt

Frank (frank-schaeffer) wrote :

I think we could assign this bug to Ubuntu Kernel Team and in consideration of numbers of people who has written a report we can change the status to confirmed.

Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-acpi
status: Incomplete → Confirmed
theanalogkid (mlyszczek) wrote :

Yeah, SLUB is the issue, I compiled a kernel with SLAB and it suspends and resumes without a hitch.

Emanuel (emanuel-ngine) wrote :

also tried it on a custom Gutsy kernel 22-11-generic from git yesterday, only changing SLUB to SLAB in the config. Suspends / Resumes fine, but its too much hazzle, as none of the restricted modules will work of course. Will this be reverted in gutsy, or will fglrx need to be fixed instead?


Emanuel (emanuel-ngine) wrote :

sorry for the spam, forgot to list my specs: Thinkpad z61p, x1600, ATI fglrx from gutsy repo

Philipp Kern (pkern) wrote :

I talked with BenC on yesterday's kernel meeting and he told me that he will try to contact ATI about that. It is obviously fglrx's fault and there is only a minimal chance that the allocator is reverted back to SLAB for Gutsy.

Henrik Nilsen Omma (henrik) wrote :

Setting importance to wishlist, since we are dependant on a fix from ATI for this.

Changed in linux-source-2.6.22:
importance: Undecided → Wishlist
laksdjfaasdf (laksdjfaasdf) wrote :

I don't think that this has to do with ATI - I have a Z61m with INTEL Dual Core with INTEL graphics card. That means these problems are on NON ATI machines.

The current behaviour here is:

after resuming from suspend to RAM, there is the desktop again. But after about 30 seconds, machine suspends to disk which is very annoying.

If you leave it as a wish item - shall I open another bug report?

Emanuel (emanuel-ngine) wrote :

Hi Felix,

i am almost sure you are seeing something not related to this bug at all. This bug's symptom is that you cannot even complete the suspending of the computer, e.g. the machine won't even enter sleep mode at all. Plus, my machine supends and resumes fine if i stop X and unload the fglrx module.


Heitzso (heitzso) wrote :

Ubuntu may want to consider this a show stopper for releasing gutsy, or at least flag all over the place this problem. Reason I say that is if 5% of all of your potential upgraders are laptops running ati graphics (just shooting in the dark re percentage, but if anything I assume the actual number is higher than 5%) then 5% of all Ubuntu users will feel badly burned by the upgrade to gutsy. A broken suspend, when suspend worked fine in Edgy, is a critical bug.

BTW, I'm running ati's latest stable release of fglrx and this suspend problem shows up in it as well. I switched to ati's fglrx from ubuntu's in the hope that the ati/glx slowdown would be fixed (wasn't, had to disable glx server).

jbj (jbj-ubu) wrote :

I too suffer from this problem, and for now have chosen to run fglrx driver without the kernel driver (kinda defeats the point, but it plays better with the console fonts than the vesa driver).

From Ubuntu's side, is it reasonable to revert to SLAB? Is anyone in ati saying that 8.42 or so might address the SLUB behavior?

lukas engelmann (lukeng) wrote :

I also suffer from this with a thinkpad t60 and ATI 1400. I really need the suspend-function working, so i started using only mesa-driver without fglrx ,3d-rendering and a lot of graphic problems....

I really would aprecciate, if there could be any information, what ATI will do about this...and when? what did they answered you about your questions?

I really like gutsy and i like to use it with graphics enabled and the suspend function working. would be perfect...:)

I can confirm the same behavior on my z61m (Intel Core 2 Duo/ATI X1400/latest Gutsy fglrx driver/2.6.22-12 kernel/fresh install of tribe 5 + updates, otherwise stock): initiating suspend results in a black screen, a blinking cursor in the corner and a blinking half moon LED. This happens during entry into suspend - it starts suspending and never completes. A hard reset with the power button is all that will bring the system back to life.

Could someone elaborate on the following statement from above: "also tried it on a custom Gutsy kernel 22-11-generic from git yesterday, only changing SLUB to SLAB in the config. Suspends / Resumes fine, but its too much hazzle, as none of the restricted modules will work of course."? I've no problem building a custom kernel while this gets resolved, but I'm not clear what exactly this will affect or what else would need possible rebuilding. The only 2 restricted modules installed on my system are fglrx and HAL. Would I need to rebuild these as well if running a SLAB kernel?

JoergMechnich (joerg-mechnich) wrote :

I am experiencing the same troubles on a Thinkpad T60p with an ATI Mobility FireGL 5200 (M56). Once I prohibit the fglrx kernel module from being loaded on X start by adding it to the DISABLED_MODULES variable in /etc/default/linux-restricted-modules-common, suspend-to-ram as well as suspend-to-disk are working. Btw the problem still persists with the most recent fglrx driver 8.40.4 that is supporting FireGL cards. I really hope that AMD will release a new driver soon that supports this cards AND fixes problems with suspend.

Morten Grouleff (mgr-trifork) wrote :

I can confirm this issue on my Z61m.

My daily work is a lot smoother with suspend working.

I would like to switch to the open source driver, but that is not an option, as the X1400 in Z61m is not supported by that driver. Right?

I have made the experiment of rebuilding the 2.6.22-12 kernel, the modules and restricted modules, changing from SLUB to SLAB. With this setup suspend works. Unfortunately the system is not stable after resume, but that may be an effect of something else being changed by the custom building of all those modules. Building the custom kernel was quite a lot more work than I expected, and the documentation on how to do so is somewhat sketchy - I did something along the lines of https://help.ubuntu.com/community/Suspend2Kernel.

So, are we out of luck until ATI fixes fglrx? What are the chances of X1400 support in the open source driver?

Philipp Kern (pkern) wrote :

We are out of luck until ATI fixes fglrx for Gutsy. Maybe radeonhd makes a leap in progress for Hardy. AMD released the specifications for the cards in Z61m (I have a X1600), so 2D support should come.

But I don't see that this will be fixed in Gutsy, because there won't be a revert to SLAB and most probably no fix in time from ATI. (I hope that I am proved wrong.)

laksdjfaasdf (laksdjfaasdf) wrote :

My Z61m with INTEL (!) GMA 950 graphics card suspends to RAM and resumes with newest kernel 2.6.22-12. Gnome-Power-Manager still reports problems after resume but the system keeps running now. It seems to be stable - I did 2 suspend to RAM and resumes and still work with it.

For me it looks like if system suspends too early. If I interpret syslog right, suspend finishes until after powering system on again and then it starts resuming!?

Philipp Kern (pkern) wrote :

Yes, only Z61m with ATI graphics are affected by this problem.

It's not just z61m - I think this bug report just self-selected for z61m users. Other systems seem to be experiencing the same problem, so I think this is a more general problem. See:


ATI + fglrx + SLAB + x.org seems to be the common element, along with some as yet unclear other factor (Core 2 Duo?).

If this is widespread enough (as it's beginning to appear) it does beg the question of whether sticking with SLAB is the best choice for Gutsy, given that this breaks the "it just works" aspect of Ubuntu that is one of it's biggest strengths (and what caused me to switch from Gentoo, at least on my notebook). Non-functional power-management is a pretty serious issue for notebook users, who I'm guessing make up a decent chunk of the userbase. What alternatives are there to custom-compiling a SLUB kernel + modules? Could gutsy offer SLUB-enabled kernels and modules alongside the default SLAB-enabled ones temporarily until this is fixed upstream in fglrx? It's a bandaid and a royal PITA, but at least hardware would work as expected, and this wouldn't provide new fodder for "Linux isn't ready for the desktop" articles.

Sigh. Proprietary binary-only modules really *are* evil. And to think I originally developed a preference back in the day for ATI because they supported open-source drivers and NVidia didn't. At least things are slowly coming full circle.

laksdjfaasdf (laksdjfaasdf) wrote :

OK, I added my problem description to another bug report which I already opened for Feisty and which fits better to my problem (#128852).

At the risk of being redundant, I'll confirm that installing a custom compiled SLAB-enabled kernel and restricted modules restores suspend/resume on my machine.

(Hmm. Seem to have gotten SLAB/SLUB confused in my last post. Sorry - distracted by other stuff going on around me).

Nicolás Schubert (nischg) wrote :

I can confirm this behavior on my Dell Inspiron 6400 with Radeon X1300 running fglrx. Suspend/resume should really work for notebook users.

I can also confirm this behavior on a Dell Latitude D810 with a Radeon X600 running fglrx. Such a pity.

MadsBuus (online-buus) wrote :

I can confirm this behavior with Lenovo T60p (ATI fireGL card) fglrx driver. Suspend hangs with blinking moon icon..
Worked in feisty

Matthew Garrett (mjg59) on 2007-10-12
description: updated
Philipp Kern (pkern) on 2007-10-19
description: updated
Changed in linux-source-2.6.22:
importance: Undecided → Unknown
status: New → Incomplete
Changed in linux-source-2.6.22:
status: New → Invalid
Changed in linux-restricted-modules-2.6.24:
assignee: nobody → ubuntu-kernel-team
importance: Unknown → High
status: Incomplete → Triaged
Changed in linux-restricted-modules-2.6.24:
status: Triaged → Fix Released
Timo Aaltonen (tjaalton) on 2008-02-07
Changed in linux-restricted-modules-2.6.22:
status: Confirmed → Won't Fix
Changed in linux-restricted-modules-2.6.24:
status: Fix Released → Confirmed
Changed in linux-restricted-modules-2.6.22:
status: New → Invalid
Changed in linux-restricted-modules-2.6.24:
status: Confirmed → Won't Fix
Wolfgang Glas (wglas) on 2008-02-25
Changed in linux-restricted-modules-2.6.22:
status: Won't Fix → Confirmed
234 comments hidden view all 314 comments

Hello Chad,

I hadn't got time yet to test with radeon driver. However, today I upgraded
my memory chips to 4GB and now I'm using no swap at all (!). With this
configuration I can perfectly resume after suspend with iowait at only 2-3%.
That's why I suspect that this bug has nothing to do with fglrx, and is more
related to kswapd.

I will recheck one of these days with radeon plus something to eat huge
chunks of memory.



On Thu, Feb 28, 2008 at 9:40 PM, Chad Johnson <email address hidden>

> Jaime,
> I asked the person who started that thread in the linux.kernel link, and
> he gave me the following response:
> -
> it seems to me that your issue might be completely different. Are you
> sure it isn't an issue in X and/or fglrx driver?
> If I were you, I'd boot the machine without X (not just kill X, fglrx
> must not have been loaded since the last power cycle), try
> suspend/resume from there and if the problem persists, it's likely that
> our issues are same. If it works when suspending form console, it's
> likely that it's just fglrx causing problems.
> In the meanwhile, I've got my laptop memory expanded and I also switched
> form fglrx to new xf86-video-ati and driver "radeon" which got support
> for modesetting recently, so so I unfortunately can't help you with fglrx.
> -
> I have not had time to try yet, but have you been able to reproduce this
> issue without the machine running X or fglrx loaded?
> --
> [gutsy] fglrx breaks over suspend/resume
> https://bugs.launchpad.net/bugs/121653
> You received this bug notification because you are a direct subscriber
> of the bug.


Ningún bit ha sido maltratado durante la creación y envío de este mensaje.
No bit has been injured in the creation and sending of this message.

cement_head (andorjkiss) wrote :

after resume from hibernation (not from suspend) always one core at 50% +.

HP6910p, Intel Core2Duo, 2 GB ram

Chad Johnson (chad-d-johnson) wrote :


It seems the same exact issue is present in OpenSUSE 10.3. I suspend, and the system is slow as hell. The status code for kswapd is set to D< .

So what I/we are experiencing is, like you said, more than likely not related to this bug.

chad . d dot johnson AT(@) gmail.com

Jaime (jaime-lopez) wrote :

Chad, I definitely agree with you, this must be unrelated.

Right now I am not able to reproduce the (supposed) kswapd mysterious bug
with Ubuntu 64 bits and more RAM, even with heavy swapping used. So, if you
are able to get some traces, please forward them to the Linux kernel thread.



Chad Johnson (chad-d-johnson) wrote :

What command do I run to get traces?

Did you recently switch to 64-bit (i.e. did switching from 32-bit to 64-bit solve this for you)?

Henry Gomersall (hgomersall) wrote :

Entering sleep using:

sudo /etc/acpi/sleep.sh force

allows the machine to resume fine. There is something subtle going on here.

Hardy on Dell Inspiron 9400 with x1400.

Does it work suspending using the "pm-suspend" command?

This command uses HAL to suspend; so if sleep.sh works but pm-suspend doesn't, it is most likely a bug in HAL regarding one of your hardware devices.

Bernhard Gehl (bernhard-gehl) wrote :

@awen, Henry:

Confirm: suspend and resume works using the sleep.sh script as well as the pm-suspend command.

Hardy kernel 2.6.24-12 w/ latest fglrx from repos, ATI Mobility Radeon X1400 (Inspiron 9400 like Henry Gomersall). I confirm that

sudo /etc/acpi/sleep.sh force


sudo pm-suspend

both successfully suspend and resume my machine with POST_VIDEO=false and SAVE_VBE_STATE=false.

How do I make either of these commands run on lid close? Feel free to email me.

Bernhard Gehl (bernhard-gehl) wrote :

Sorry for being inconcise yesterday - I was kind of in a hurry...

Suspending with the sleep.sh script works but breaks the network-connections after resume (as I suppose it should...) while everything else seems to resume fine. Suspend over HAL via pm-suspend does work as well as does resuming (with working network).

Hardware: Radeon Mobility x1600 (in a LG S1 Dual Pro)
Kernel: image 2.6.24-12.22 generic, restricted modules generic, fglrx 7.1.0-8-3+2.6.24-11-12.31

Being no linux-crack, I have a few questions:
1. I assume the "acpi-support" config file in /etc/default is not read/considered by pm-suspend - is that correct?
2. In what way does the gnome-power-manager define what to do at shutdown?
3. Which package/package maintainer would be the correct one to address with this problem, since the kernel itself doesn't seem to be responsible for the breakage?

infodroid (infodroid) wrote :

@Bernhard Gehl: Whenever you are in doubt about the cause of any bug, just blame dbus.

Nearly correct in this case also ;-)
g-p-m uses dbus/dcop to contact HAL.

@Bernhard Gehl
You should report it against HAL afaik. HAL uses its knowledge about the hardware to try to suspend/resume correctly.

FrejSoya (frej) wrote :

Current hardy, macbook pro 1,1 15"
I made the same but shorter comment in bug #202814. Thanks tip of pm-suspend to get this working Bernhard :)

So after messing around it seems it's because acpi-support isn't used at all and pm-utils is. So /etc/apci-support does not do anything!!!!
See /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux (Assuming this is called)

Calling "pm-suspend" works since it's called with no quirks (see pm-suspend --help). But hal on my machine has 'power_management.quirk.vbe_post = true' because of 20-video-quirk-pm-apple.fdi changing it to false fixes resume/supend from System->Quit "logout window"
You can check with lshal |grep quirk and see what quirks is set and change the corresponding fdi files for you machine.

This bug is caused by either:
  * Hal quirks is wrong for fglrx platforms with kernel 2.6.24.
  * Hal is supposed to use acpi-support on ubuntu but patch isn't applied ?

I also had to set

keeping network working. Since madwifi sucks too ;)

Suspend/resume also works for me now, on Hardy, with default Ubuntu fglrx module (pm-suspend only, not KDE suspend, but that's Bug #202814).

Since so many people have this working on Hardy, it seems as though the SLAB/SLUB issue is fixed. Should it be marked as "Fix Released"?

damagedspline (icpazi) wrote :

FrejSoya wrote:
> in
> /usr/lib/pm-utils/defaults
> I also had to set
> keeping network working. Since madwifi sucks too ;

I suffer from this issue as well, please report it separetly.

flynn (flynn) wrote :

I noticed that with todays update suspend and resume is working with fglrx driver ati 8.3 from repro. Before i had a blackscreen after resume. It's working with and without compiz fusion. It could be the new acpi update that makes suspend/resume running. Thanks for fixing that issue.

Bernhard Gehl (bernhard-gehl) wrote :

Actually it was a bug in pm-utils/hal - well not even a real bug, but rather a patch doing the right thing in many cases but the wrong thing for fglrx-driven machines. The recent updates to hal, libhal* and pm-utils fixed it. Thanks, folks!

What hardware are you running?
Is this with Gutsy Gibbon or Hardy Heron?


On Fri, Mar 21, 2008 at 4:34 PM, gnubuntu <email address hidden> wrote:
> I noticed that with todays update suspend and resume is working with
> fglrx driver ati 8.3 from repro. Before i had a blackscreen after
> resume. It's working with and without compiz fusion. It could be the new
> acpi update that makes suspend/resume running. Thanks for fixing that
> issue.
> --
> [gutsy] fglrx breaks over suspend/resume
> https://bugs.launchpad.net/bugs/121653
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

flynn (flynn) wrote :

@ Chris Stoughton: I use Hardy Heron Beta now. Fresh install on a notebook Amilo xi1546 with ATI x1800. I only change this options: POST_VIDEO=false and SAVE_VBE_STATE=false

DaveAbrahams (boostpro) wrote :

Uh-oh. Like SixedUp I have: IBM Thinkpad T60p, with an ATI Mobility FireGL V5200, and I was really excited about the possibility of working suspend/resume in Hardy.

I just did a fresh install of hardy and made the POST_VIDEO and SAVE_VBE_STATE edits in /etc/default/acpi-support. Suspend works, but I get no display upon resume. Otherwise, the machine *appears* to be working.

Some possibly-relevant tidbits:

1. my current installation is on an LVM volume

2. I installed hardy on an external USB drive (actually an ipod 60G) a few days ago, and suspend/resume worked ... except that the drive disappeared upon resume, so you couldn't do anything. However, the display was visible.

  Is it even conceivable that the use of LVM or USB affects whether fglrx resumes properly?

3. Incidentally, suspend/resume *does* finally work on my old Dell inspiron 9300 using fglrx under Hardy.

cement_head (andorjkiss) wrote :

I need a few mods to acpi-support to get suspend/hibernate to work on my HP6910p


# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
# Note that network cards and USB controllers will automatically be unloaded
# unless they're listed in MODULES_WHITELIST
MODULES="ehci_hcd uhci_hcd ohci1394 ndiswrapper"

# Uncomment the next line to switch away from X and back again after resume.
# This is needed for some hardware, but should be unnecessary on most.

DaveAbrahams (boostpro) wrote :

Update: I take it back; T60p/FireGLv5200 works under Hardy. I was confused because this installation was done with the Hardy nightly build which apparently references a different set of repositories than the hardy beta CD does (!)

When I switched to the sources.list from hardy beta I got fglrx 8-3 and suspend/resume worked. However, there was a disconcerting error when suspending to disk: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/120310

DaveAbrahams (boostpro) wrote :

I take it back again: my success was with the 8-1 driver under an earlier Hardy. By the time Hardy updated to 8-3 my suspend was broken again :(

DaveAbrahams (boostpro) wrote :

Furthermore, disabling fglrx in the "Hardware Drivers" application (and rebooting, of course) did not make suspend work again. Something happened between the April 15 daily build and tonight's state of the hardy repositories. The one other possibility I can think of is that it's something in my xorg.conf that is unrelated to fglrx.

DaveAbrahams (boostpro) wrote :

My problems may not have anything to do with l-r-m; I'm in the process of determining whether it's related to https://bugs.launchpad.net/ubuntu/+bug/218760. Will report back.

DaveAbrahams (boostpro) wrote :

OK, absolutely current Hardy, without fglrx and without anything plugged into my dock's USB ports: suspend/resume work fine. I have


in /etc/default/acpi-support. With fglrx, suspend "works," but resume doesn't. The screen never comes back. I can fortunately do ctrl-alt-del and get a clean reboot, but that's small consolation. If I add


then suspend works ONCE, but fails thereafter.

Next I'm going to roll back to fglrx 8-2 and then 8-1 if necessary to see what happens.

DaveAbrahams (boostpro) wrote :

Oh, for the record, here's the system version and the usual logs:

Linux mcbain 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

DaveAbrahams (boostpro) wrote :
DaveAbrahams (boostpro) wrote :

Fails also with fglrx 8-2, which incidentally is tricky to build for Hardy as things stand now (see below). Everything (basically) seems to work except that the screen never comes back. Occasionally there will be a one-line message on the console, sometimes about a soft lockup (!) which you can see in the attached dmesg. I can ssh into the machine, but the only way to regain control is to kill Xorg, unload fglrx, and reload it, then start up GDM :(. Everything works so closely to the way things were working with Hardy's own fglrx 8-3 that I think I'd find the same thing when ssh'ing in after a resume with that driver.

Next I'll try the 8-1 driver that was part of the distro on the 4/15 daily build CD.


To install 8-2 on Hardy, you need to install dkms, extract the installer files using

  sh ati-driver-installer-8-02-x86.x86_64.run --extract x,

add a symlink to a shared object:

  cd x
  pushd arch/x86/usr/X11R6/lib # x86_64 if you have that architecture
  ln -s libfglrx_gamma.so.1.0 libfglrx_gamma.so.1

then run the build process via

  ./ati-install.sh 8-2 --buildpkg Ubuntu/hardy

DaveAbrahams (boostpro) wrote :

The same build procedure applies to the 8-1 driver, but I was unable to get it to work. I'll probably try that again in a few minutes, along with the 8-4 driver.

However, I did get the 8-3 driver to work! I just have to disable compiz before suspending. See https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/197209

Is there somebody out there with suspend.d fu who can easily write the scripts to do that while we wait for a real fix?

DaveAbrahams (boostpro) wrote :

Whatever problems remain (for me) are all described more precisely by https://bugs.launchpad.net/ubuntu/+bug/197209 and https://bugs.launchpad.net/ubuntu/+bug/218760, so I'm marking it fixed in the upcoming Hardy release. I will attach workarounds to #197209 tomorrow when my head is clear.

Changed in linux-source-2.6.22:
status: Invalid → Fix Committed
Phil Estes (estesp) wrote :

if it helps your investigations, 8.4 is the first in the 8.x series that works reliably for me on suspend/resume and various crashes/hangs I was getting on any earlier version of fglrx. I have now had a 5 or 6 days of uptime on 8.4 and multiple suspend/resumes (with no changes to the acpi defaults about post video/save state, etc.) with absolutely no issues. This is all on hardy latest (-16 kernel, etc.) on an older chipset (FireGL Mobility T2), so YMMV as usual

Chad Johnson (chad-d-johnson) wrote :

This problem is NOT fixed using the 8.4 Catalyst drivers with the Hardy release candidate. The first time after resuming from suspend using the 8.4 drivers, 100% of the CPU was being used (according to htop), and running '/etc/init.d/gdm stop' brought usage back down immediately. I believe I am having the issue described by this bug as reverting to the Feisty kernel with Gutsy did resolve this issue entirely.

Please please please vote on this bug: http://ati.cchtml.com/show_bug.cgi?id=739. I cannot believe ATI is ignoring this bug.

I am going to try, once again, to compile a kernel--for Hardy this time. If all goes well, I will try to make it downloadable for everyone.

stel (stel-onshore) wrote :

suspend/resume with fglrx 8.4 on hardy works for me (t60 with 1400) as long as some usb devices are not attached, notably my scanner. i got fglrx 8.4 (and other updates) from this backport. install the backport modules. it's mentioned on comments on another bug regardling the switch from the ipw3945 wifi module to the iwl3945 in case you're wondering.


Chad Johnson (chad-d-johnson) wrote :


Thanks...did you just add

deb http://ppa.launchpad.net/tjaalton/ubuntu hardy main

to your sources.list, run apt-get update, and then install the packages? Can you be more specific on the packages you installed? Did you install xorg-driver-fglrx-tdfx? linux-restricted-modules? Firmware?

Makar (n8makar) wrote :

I've noticed since Hardy beta lots of people have been posting on here about hardy suspend/resume. I read most of the posts, but was wondering if the issue was ever really resolved in gutsy?

I switched back to Gutsy for reasons other than this issue. I had other Ati problems dealing with an unstable system and sound. However, when using Hardy I had suspend and hibernate working with the latest Ati drivers, but they were slower than molasses. Plus the sound died on the system after each task executed.

I have Gutsy with kernel 2.6.22-14-generic and just the restricted drivers enabled (Ati radeon Xpress 200m). To be honest I'm a little scared to mess around with the drivers since everything else (like compiz and other 3D rendering) works so BRILLIANT! Obviously, neither hibernate nor suspend work for me and give all the exact symptoms that have been reported above over and over again.

So maybe somebody found a loop hole and I missed it on here? Probably not, but hey with such a stable system I'm not complaining too much. I still think Gutsy is better than Hardy.

Bryce Harrington (bryce) wrote :

[This is an automated message]

As of Intrepid (8.10), we have a dedicated package 'fglrx-installer' for fglrx bugs, which now includes a process for upstreaming bugs to AMD.


To transition your bug into the new fglrx-package, we need your help. Please do the following:

 a. Verify the bug occurs in Intrepid.
     (Intrepid ISOs: http://cdimage.ubuntu.com)
 b. If you haven't already, please include in the bug:
     * Your /var/log/Xorg.0.log
     * The output of `lspci -vvnn`
     * Steps to reproduce the issue
 c. Click 'Also affects distribution'
 d. Set 'Source Package Name' to 'fglrx-installer'
 e. Click Continue

Thank you. This will assist us in reviewing and upstreaming your fglrx bug, as appropriate.

[We'll expire the fglrx bugs in l-r-m-* in a month or so.]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Bryce Harrington (bryce) on 2009-01-16
description: updated
Timo Jyrinki (timo-jyrinki) wrote :

Should be "Won't fix" (2.6.22 in Ubuntu 7.10 not supported anymore) but I don't seem to have that option.

Changed in linux-source-2.6.22 (Ubuntu):
status: Fix Committed → Invalid
Changed in linux-restricted-modules-2.6.22 (Ubuntu):
status: Confirmed → Invalid
CheolHan Yoon (mait) wrote : hi !

Hi,what is up?
my friend that works at chinese electronic corporation called
"VIP-SHIMAO" tell me: their company is carrying out a promotion
there are phone,notebook,LCD TV and so on,not only all of goods are
new and original ,but also the price so cheaper,they have received
from customers high praise in the worldwide,
today i get the digital camera that ordered,their service team are so
excelent,shiping time take less than one week,i am very satisfied with
their goods and service.
now i share with you the good news,i believe that you can find what
you need or like there : www.vip-shimao.info
i trust that you will not despair and will get surprising,wish
shopping happily!!

Curtis Hovey (sinzui) on 2012-04-09
Changed in linux-restricted-modules-2.6.22 (Ubuntu):
assignee: Registry Administrators (registry) → nobody
Displaying first 40 and last 40 comments. View all 314 comments or add a comment.
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.