[gutsy] fglrx breaks over suspend/resume

Bug #121653 reported by theanalogkid on 2007-06-22
430
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.22 (Baltix)
Undecided
Unassigned
linux-restricted-modules-2.6.22 (Ubuntu)
Wishlist
Unassigned
Declined for Gutsy by Brian Murray
Declined for Hardy by Bryce Harrington
linux-restricted-modules-2.6.24 (Ubuntu)
High
Unassigned
Declined for Gutsy by Brian Murray
Declined for Hardy by Bryce Harrington
linux-source-2.6.22 (Ubuntu)
Undecided
Unassigned
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.

[lspci]
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:

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/46064

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 2.6.22.10 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?

best
Emanuel

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.

best
Emanuel

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:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/126214

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

Henry Gomersall (hgomersall) wrote :

I confirm failure to suspend on a Dell Inspiron 9400, Radeon X1400 with fglrx. No flashing cursor at the top left however as the original bug report states.

Charl P. Botha (cpbotha) wrote :

I am seeing the same behaviour on an HP NC8430 laptop (ATI X1600, Core Duo T2500, Gutsy Gibbon up to date on 2007-10-02, fglrx 7.1.0-8.37.6+2.6.22-12.4). Both suspend and resume don't even get to the flashing power light (this is how my laptop shows that it's in ACPI S3 suspend) stage, but everything is frozen hard (screen off, etc). I have to power-cycle to get back.

For me this is a show-stopper. I need GPU support (my day-job is doing Scientific Visualization) and I definitely need suspend/resume.

Charl P. Botha (cpbotha) wrote :

I understand that one is dependent on ATI for a fix. However, isn't it wise to include at least SOME kind of workaround or documentation in Gutsy concerning this problem? Will anyone even get around to that seeing that this bug has been classified "wishlist" ?

It really makes a fantastic impression when a computer locks up hard the first time the user tries to suspend or hibernate it. ;)

As I already mentioned you can prevent the fglrx kernel module from
being loaded.

Then you get some message like:
(EE) fglrx(0): atiddxDriScreenInit failed, GPS not been initialized.
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *
(WW) fglrx(0): ********************************************* *
in /var/log/Xorg.0.log as 3D acceleration will not work without the module.

Suspend however will work (at least on my machine).

2007/10/2, Charl P. Botha <email address hidden>:
> I understand that one is dependent on ATI for a fix. However, isn't it
> wise to include at least SOME kind of workaround or documentation in
> Gutsy concerning this problem? Will anyone even get around to that
> seeing that this bug has been classified "wishlist" ?
>
> It really makes a fantastic impression when a computer locks up hard the
> first time the user tries to suspend or hibernate it. ;)
>
> --
> [gutsy] Suspend to Ram does not work on Z61m
> https://bugs.launchpad.net/bugs/121653
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This is the path I'm planning to take (seems to be the only alternative on X1600 if you want full resolution), but as I said in my first post, I *need* the GPU (3D acceleration) support. Also, some sane default should be implemented, as fglrx + SLUB + suspend/hibernate guarantees a hard crash every time. Perhaps the suspend script can check for the presence of the fglrx module and refuse to suspend in that case... (with a comment documenting this)

Ali Sheikh (asheikh) wrote :

I can confirm this on Thinkpad T60p with ATI video card. When I try to suspend I see the blinking moon LED, the screen goes blank, but the thinkpad never suspends.

In my opinion this is a very important bug to be fixed before gutsy is released.

"Perhaps the suspend script can check for the presence of the fglrx module and refuse to suspend in that case... (with a comment documenting this)"

That's a pretty drastic solution to the problem, considering that it's caused by premature commitment to a brand new kernel feature (the SLUB allocator), particularly for a distribution with a reputation for "it just works" and "user friendliness". It's been confirmed both here and in the several duplicate bug reports that restoring the expected behavior (normally functioning suspend/hibernate/resume) is a simple as switching back to the SLAB allocator. Everything works again, and nothing seems to break. I haven't found a compelling argument for SLUB over SLAB yet other than "the simplified code is attractive" and a *claimed* "5-10% performance increase" (Emphasis mine - where are the benchmarks?).

Given that defaulting to SLAB until SLUB has been more widely tested is unlikely, it seems that a solution that doesn't put undue burden on the user would be preferable to the workarounds mentioned so far. Something like having the fglrx package depend on a SLAB version of the kernel (installed alongside the default SLUB version) along with a note to the user to boot into the SLAB kernel if they need suspend/resume to work with fglrx. Once it's been confirmed that a future version of fglrx is compatible, the extra dependency can be quietly eliminated.

Charl P. Botha (cpbotha) wrote :

Terry, I like the way you think, this would definitely be the way to go!

However, I'll bet you a beer (heck, make that two if you ever end up in my neck of the woods) that this doesn't get officially fixed before Gutsy gets released. :) There is too little time, I've seen irc logs where developers (BenC IIRC) have stated that the chances of them reverting to SLAB are slim (he he, say that quickly), and the changes that you propose are quite significant.

Personally I'm going to hold out for the next release... (I've disabled the kernel driver in order to get working suspend and resume, but then I lose 3D acceleration, which I do need. I've also given up on the power management; it's much improved with tickless, powertop and things like lesswatts.org but it still doesn't come even close to XP. Also, the dynamic display support still sucks. Hard. I should blog about this again sometime. End rant.)

Philipp Kern (pkern) wrote :

The kernel freeze is approaching. The only suggestion from the devs is to blacklist the fglrx module. I.e. add a `/etc/modprobe.d/blacklist-fglrx' with the content `blacklist fglrx' and reboot. This will deactivate 3D acceleration, but give you a working X graphics driver (which is not possible with free drivers for R500 onwards) with suspend enabled. That means that you got to decide: suspend or 3D acceleration. It's possible to switch between those modes by unblacklisting the driver, loading it, restarting X, and the reverse.

Same problem seen on my T60p with ATI MOBILITY FireGL V5200 running fglrx 8.37.6 on latest Gutsy. Suspend hangs with thinkpad-standby-led still blinking.
Previously worked in Feisty. Very bad regression.

"The kernel freeze is approaching. The only suggestion from the devs is to blacklist the fglrx module. I.e. add a `/etc/modprobe.d/blacklist-fglrx' with the content `blacklist fglrx' and reboot. This will deactivate 3D acceleration" ...

Not an optimal solution if a) you need 3D acceleration (game development, biomedical imaging, visualization, whatever), b) you want to run your display at full resolution (xorg's driver won't), c) You want to run Compiz, d) You want to use all the features of your expensive laptop that you paid for. I wonder if the response would be different if this didn't involve an eeeeevil binary-only driver. Yes, it should be open source (and thankfully that's happening), yes it's the driver that needs to be fixed, yes, open-source, non-proprietary drivers help prevent situations exactly like this, but anybody who does systems integration knows that ultimately it's not about which library or module is causing the problem, but whether the end product works. Broken is broken.

This has the beginnings of a fiasco in the making, since the frequency of confirming reports seem to be slowly increasing as the early adopters trickle in to give Gutsy Beta a try. Once Gutsy is released, the next portion of the bell curve will arrive to try things out, and soon we'll be reading endless articles about the latest reason Linux "isn't ready for the desktop". Maybe I'm wrong (I hope so) and ATI will come forth with a fix to fglrx that will eliminate the problem, but maybe someone needs to think things through a bit more. Ubuntu has a pretty big target painted on it's back at the moment.

(I'll note in passing that this isn't meant to be a rant against the devs because they aren't fixing *my* problem - I fixed the problem myself so I'm not deeply affected. Not everyone has the ability or the inclination to recompile a kernel, however, and my understanding of Ubuntu demographics suggests this describes the majority.)

Philipp Kern (pkern) wrote :

Compiz does not count as that won't run out-of-the-box with fglrx anyway. And as said, if you need 3D acceleration you could use it, but you can't use suspend.

The response would indeed be different if the source code had been available. Then the kernel devs would be willing to debug it. If you look at how suspend debugging works you would understand why this is difficult even with a driver where source is available (storing information in RTC). And it seems impossible with a binary blob.

Complain to ATI please. It seems that they did not even respond to the Ubuntu Kernel devs, or claimed that the thing they do is valid. At least you can't find any claims that the SLUB allocator is wrong.

has anyone run with slub_debug enabled as a kernel param and provided output?

can anyone link to an active defect raised in ATI / AMD ' s bug tracking system? (presuming they have one)

Philipp Kern (pkern) wrote :

At least there is http://ati.cchtml.com/show_bug.cgi?id=739 -- but there is no official bug tracker, only an unofficial one which is not used by ATI employees.

I think it's hard to debug this as my machine is dead when it tries to suspend. Network is down and the display is black with a blinking cursor.

Philipp Kern wrote:
> The response would indeed be different if the source code had been
> available.
*snip* [it's hard debugging a binary blob]

Agreed. No argument there. The situation totally sucks.
> Complain to ATI please. It seems that they did not even respond to the
> Ubuntu Kernel devs, or claimed that the thing they do is valid. At least
> you can't find any claims that the SLUB allocator is wrong.
>
I have done this (http://support.ati.com/ics/support/mylogin.asp),
though that's really irrelevant. ATI isn't readying Ubuntu Gutsy for
release. Ubuntu developers are. So that's who we (the participants of
this bug report) are (in theory) communicating with. Talking to ATI in
this case is like talking to Square Peg, Inc. because a manufacturer
decided to use the latest Round Hole widgets in their thingamajig
instead of the more compatible Square Hole widgets. The choice to use
incompatible widgets was the manufacturer's, so that's who you talk to
when the thingamajig doesn't work.

And this isn't complaining - it's a discussion of a known issue with a
beta release and possible solutions, along with some consequences of the
latter. Whatever the details, the result of the current path taken will
be that some fundamental features of modern computing systems won't work
for a significant portion of the userbase. If the Ubuntu devs are aware
of this and it's an acceptable outcome, I have no problem with that. At
least with Linux we have choices, which include fixing it ourselves (and
sharing the fix with others) or choosing another distribution that
doesn't exhibit the problem. That's a wonderful thing.

Link to "Linux Crew Driver Feedback" ... the more people that tell them about it the better

http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&type=web

Phil Estes (estesp) wrote :

I can confirm as an employee of a company with 1000s of Thinkpad users who use various distros, but lots of Ubuntu, this is going to really suck. I just decided to try Gutsy and this is the one thing that is a real downer to hear that no one really cares if ATI-based notebook users just can't suspend. I guess Ubuntu's position is "deal with it suckers" instead of the early Ubuntu days "make Linux just work".. oh well (and yes, I'm very aware of the issue that fglrx is involved, but Ubuntu has to answer for that as well as they package, ship, and "make it easy" to use restricted/non-open drivers.) I've CCed myself just in case happy news comes down the pike before gold..

Markus Vuori (lite) wrote :

I can confirm this. I'm running Gutsy on Lenovo T60 (1680x1050 wide screen) with fglrx driver and ati mobility x1400 graphics adapter. With Feisty suspend worked well, as well as with Gutsy running Feisty kernel (2.6.20).

I've tried the driver versions found in feisty's or gutsy's standard repositories, as well as 8.40.4 and 8.41.7.

All fglrx versions worked with feisty kernel, and none of them works with gutsy kernel. There's something wrong with gutsy kernels.

Now my T60 doesn't want to go sleeping. It goes in semi-sleep state the "moon" indicator led and cursor blinking on blank screen.

Gutsy is up-to-date running 2.6.22 generic kernel (2.6.22-13.40).

theanalogkid (mlyszczek) wrote :

Why can't Ubuntu just put out a kernel flavor for ATI users that uses SLAB instead of SLUB for the time being? Seems like a more productive workaround than just saying, ATI has to fix it.

Just to add to the other confirmation entries on here, I can confirm the problem occurs with both STR and STD running fglrx on a Dell Inspiron 9300 with ATI Mobility Radeon X300 graphics. The machine just hangs before it gets to actually suspend/hibernate and the only way to get the machine back up and running is with a hard reset.

Confirm that the "workaround" (disabling the fglrx kernel module) makes my machine suspend and resume. And it does so quicker and more reliably than feisty did, at least something. However it seems to me that certain 2D operations also suffer from the kernel module not being loaded, is that possible? For example it seems to me that scrolling in firefox has become slower. Does somebody know whether the kernel module's job is exclusively 3D operation or also 2D stuff?

Philipp Kern (pkern) wrote :

At least it disabled XVideo on my laptop which is quite a drawback when using mplayer.

Charl P. Botha (cpbotha) wrote :

I can confirm that 2D operations are somehow also affected (significantly slower). This is yet another reason why removing the fglrx kernel module is not really a workable solution.

Matthew Williams (number6) wrote :

On my HP NC6000, disabling fglrx also fixes the suspend problem but makes video playback incredibly bad. My 30 fps movie only gets refreshed at 10-15fps in a small window. This is not a workable work-around.

Then again, XV is broken in fglrx anyway. sigh... What worries me is that we are so close to release. No wonders to be expected from ATI and the readyness for making massive changes is probably not there from the Ubuntu side either... I really do hope this new open source driver comes along nicely and quickly then all this hassle is a thing of the past by somewhen next year.

Steve Dee (mrdomino) wrote :

This seems as though it has the potential to interact disastrously with <https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/89853>. If one or the other isn't fixed, then there may be quite a few people (myself included) left with a choice between no suspend or no graphics whatsoever.

Håvard H. Garnes (hhgarnes) wrote :

I hereby also vote to include some solution that gives me _both_ suspend and 3D.

I can also confirm the suspending behaviour on a T41p with fglrx + 2.6.22-14-generic .[ATI FireGL Mobility T2]
When trying to suspend the screen just goes black and the moon LED keeps flashing.

Going back to the open source ati driver makes suspend work, (though after waking up, I get some error message,
that suspend did not properly work)

Well you should be lucky, your flashlight is even blinking..
Just joking.

If i suspend the screen goes blank, can hear the harddrive powerdown and thats it. Just silence and glowing powerled instead of a blinking one.
Using latest fglrx and 2.6.22-13

Have tried the open source driver but ATI 200M/1150 doesnt like open source :O

nshaw (nathanashaw) wrote :

I have the same problem on a Toshiba Satellite A215-S4757. I got it to suspend by prevent the fglrx kernel module from
being loaded, but would very much enjoy 3D and suspend on gutsy.

Valentin Longchamp (longfield) wrote :

Just want to add another comment, to confirm that this issue really affects a lot of people and is a real regression.

I have had the same issue on my Thinkpad T60p. Since suspend is for me much more important than 3D support, I prevent the fglrx kernel module from being loaded and I can suspend again.

Hum ... when is the open-source ati driver based on ati specification going to be released ? I badly want an open-source driver for my video card (01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5250]) ....

Can confirm on IBM/Lenovo T60 which comes with AMD X1400, using proprietary driver 8.40.4. Will wait for final gutsy release to compile kernel without SLUB but would appreciate to have this fixed in gutsy as I don't think that AMD will drop a new driver in a shortly... The chipset seems to be quite popular across different vendors hence I assume this will affect a considerable number of users when 7.10 is out.

ddumanis (dave-davedumanis) wrote :

Confirming on a Dell D600. Suspend worked fine in Feisty, now it resumes with a black screen.

Charl P. Botha (cpbotha) wrote :

See the announcement of the Ubuntu 7.10 Release Candidate: http://www.ubuntu.com/testing/710rc

The fact that suspends with fglrx cause hard crashes is not even mentioned. However, "intermittent lockups" with i810 are mentioned, along with a workaround.

I have the feeling that ABSOLUTELY NOBODY officially involved with Ubuntu has been following the five hundred million reports (a slight exaggeration, of course) concerning the fglrx+suspend lockup. Nice! We don't even get a mention in the release notes.

(apologies if this sounds slightly sour. :)

Markus Vuori (lite) wrote :

Charl, no apologies needed. We're not sounding sour enough. >:)

I need fglrx also to get my dual head configuration to work. WHY NOT PUBLISH A SLAB-enabled kernel?

This is a really important issue and currently driving me pretty mad. I'm using Thinkpad, Ubuntu, fglrx and dual head for my daily work. I really need to install different distro until someone compiles and makes available SLAB-enabled kernels for gutsy (or ATI repairs it's drivers).

Download full text (4.0 KiB)

I have just reviewed all of the comments on this bug and I would like to attempt to formalise the argument for action over this bug. My apologies if this argument doesn't flow too coherently and also for the length of this post:

Philipp Kern said this way up the thread somewhere:
"Compiz does not count as that won't run out-of-the-box with fglrx anyway."

This was used as the main reason for marking this as a "wishlist" item awaiting a fix from ATI. However, the following statement is made on the 7.10 RC page that is linked to above:

"Compiz Fusion is enabled by default... Ubuntu 7.10 automatically detects whether the hardware is capable of running compiz; if not, it falls back to normal desktop."

I understand that there is an open-source ATI video driver that can be used, but all I can find on Google is how it causes instability and problems with Compiz, and doesn't perform as well as the closed-source driver (I am willing to be corrected if people have experience of this combination). When I did my fresh install, one of the first things to pop on to my screen was a bubble saying that there were "restricted drivers" that I could use (in this case the ATI fglrx and a software modem driver). I don't recall enabling or configuring anything else after that installation in order to get Compiz operational. This is backed up by this tutorial: http://ubuntu-tutorials.com/2007/10/04/compiz-fusion-on-ubuntu-710-gutsy-gibbin/ which complains that there wasn't much to write in the tutorial because "it took me *zero* configuration to get it going."

So, as I see it, one of the statements that I quoted at the beginning must be untrue. Either

1) Compiz *is* enabled out of the box and becomes active once fglrx is installed, and so people with ATI cards will encounter this suspend/hibernate bug without any prior warning. If this is the situation, then surely the Gutsy release should be held until the problem is either fixed by ATI or a workaround is made available and documented.

2) Compiz actually isn't enabled out of the box, in which case whoever writes the introduction page (currently http://www.ubuntu.com/testing/710rc for Gutsy) should perhaps amend the wording to reflect that fact

It would seem that the only courses that Canonical can take right now are:

a) Stick head in sand and ignore it.

b) Add an entry to the distribution caveat list so that people are at least warned about the problem so that they hopefully don't lose work when the find it out for themselves

c) Compile an alternative SLAB kernel which is installed only as a dependency of the fglrx package so that this whole mess goes away in the short term. This dual-pathing should be mergeable through the normal upgrade channels once the ATI driver has been corrected and released.

d) Probably too late now, but strongly encourage ATI to release a new driver version and get it tested before next week's release date.

e) Delay the release of 7.10 Gutsy until such a point as this issue is resolved.

Path a) seems to be the current choice. As a bare minimum Canonical need to move from path a) to path b). Path c) appears to give everyone what they want and surely can't be that difficult to...

Read more...

Henry Gomersall (hgomersall) wrote :

The title and description of this bug should be updated to refer to ATI and fglrx not be specific about the other hardware.

Matthew Garrett (mjg59) wrote :

This won't be fixed for gutsy. If AMD release a fixed driver, there's the potential for a stable release update later on.

description: updated
Colin Watson (cjwatson) wrote :

I have added a note about this to the release notes (http://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes). We do not have the resources to provide SLAB flavours at this point; we'd need to double the number of kernel flavours we provide, as there's no reason to expect that (e.g.) people using the -rt kernel and fglrx would be any happier with SLUB than anyone else.

Nice writeup - thanks.

Yes, path a) seems to be the current stance. I'll be more cynical than Charl and assert that this is probably deliberate, in part to punish ATI, in part to make a statement about closed source drivers in general and in part to punish users that didn't choose 100% FLOSS compatible hardware. There might be another part in that Ubuntu developers might not have any affected hardware due the last point, so aren't aware how widespread this hardware is. The irony of course is that ATI is now opening up, so they should be encouraged, not punished. These things take time.

I proposed path c) somewhere above, and I agree that it seems to be the least painful path that makes everyone happy (except for the kernel devs, perhaps). I have seen NO adverse effects to running a SLAB-enabled kernel, and no reports from anyone else about problems. Everything seems to work as it should. I could see hesitation over this approach if it had the potential to introduce serious bugs, but the allocators seem to be pretty interchangable without serious side effects. I'd still like to understand the justification for the headlong rush to SLUB. It doesn't solve any crucial issues that have a real visible impact - it just makes things slightly better and makes the kernel code cleaner. Good things to be sure, but things that can wait until absolutely stable.

Path d) was never a serious alternative, IMHO, since it's unreasonable to expect anyone, open-source or not, to make it a priority to support a brand new kernel option if it significantly alters their existing development schedule. Just because Linus pushes it out doesn't mean it's intended to be adopted right away, because sane people take a little care to ensure there are no unexpected site effects before jumping on the "ooh, shiny" bandwagon. The fact that the Canonical kernel devs expect the world to dance to their tune (we chose SLUB, so *you* have to support our decision) is a little disturbing, even if ATI is a popular scapegoat at present.

All in all, this is a nice reminder of the Faustian bargain that we strike when allowing people to develop essential tools for us. I chose Linux more than a decade ago as my OS of choice because I want control over what's important to me. I'm willing to trade some of that control for the convenience of not having to code or configure everything from scratch, but I'm also quite willing to walk away when developers get too full of themselves and forget that cooperation is a 2 way street.

Walter Huf (hufman) wrote :

Since Canonical and Ubuntu are not interested in maintaining a separate kernel release with the SLAB allocator, when will somebody start a repository of SLAB-enabled kernels, just for fglrx users?

Emanuel (emanuel-ngine) wrote :

If only it were that easy, i'd happily try, but i failed miserably at making all the other modules work on my SLAB kernel.

Elie Charest (archiesteel) wrote :

I don't know if this is a possible fix, but someone posted this on the LKML (and got some flak from kernel devs, since this is a patch to the ATI driver, not to the kernel);

http://www.gossamer-threads.com/lists/linux/kernel/829671

Note that this is for 2.6.23 kernels, but it may work for 2.6.22 kernels as well. Personally, I'm still on Feisty so I can't test it, but if someone who's already on Gutsy wants to rebuild the fglrx driver using these instructions and then report on his/her failure/success, that'd be great!

Here's the geist of it:

--For use with Kernel 2.6.23 (and possibly 2.6.22)

After installing fglrx-kernel-source, but before compiling the kernel module, make the following change in the file firegl_public.h, which is found inside the archive /usr/src/fglrx.tar.bz2, and installed in /usr/src/modules/fglrx/firegl_public.h:

--- firegl_public.h.orig 2007-10-11 23:43:26.000000000 +0200
+++ firegl_public.h 2007-10-11 23:53:08.000000000 +0200
@@ -172,7 +172,7 @@
#endif

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)
-#if !defined(CONFIG_SMP) || defined(CONFIG_SUSPEND_SMP) // ACPI not working on older SMP kernel (prior to 2.6.13)
+#if !defined(CONFIG_SMP) || defined(CONFIG_PM_SLEEP_SMP) // ACPI not working on older SMP kernel (prior to 2.6.13)
#define FIREGL_POWER_MANAGEMENT
#endif
#endif

Then compile. Hopefully, it should work...

Elie Charest (archiesteel) wrote :

Not that this is for use with the "manual" installation of fglrx, and not the automatic (i.e. deb from repositories) method, as outlined here:

http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide#Method_2:_Install_the_8.41.7_Driver_Manually

Matthew Williams (number6) wrote :

Semi-success. Using the fglrx module patch above, my NC6000 successfully gets into sleep mode. However, it hangs hard when waking up. The early stages of waking up go ok but then the machine locks up after what looks like a video mode switch.

FYI, the instructions on the web page need a couple of amendments:
- build the package for ubuntu/gutsy, not ubuntu/feisty
- delete the existing module in the volatile module directory, do not create the symbolic link

Also, to get this to work, you need to expand /usr/src/fglrx.tar.bz2, patch the header file and then rebuild the tarball so that when module-assistant expands the tarball, it gets a patched copy of the header file.

Elie Charest (archiesteel) wrote :

Okay, well that's interesting to say the least - on a test machine (which I don't have access to anymore) I couldn't even get it to suspend at all...so there might be hope yet (there are plenty of video-related options to play around with in /etc/default/acpi-support, maybe one of them would help).

Thanks for the corrections to the building process, I'll tinker around with it once Gutsy final is out and see how far I can get then.

I am 99% sure that this patch wouldn't (/shouldn't) do any good
because CONFIG_SUSPEND_SMP is still used in Gutsy's 2.6.22-14-generic
kernel. So the patch effectively disables the powermanagement
facilities of the fglrx module if applied to a kernel earlier than
2.6.23.

2007/10/14, Matthew Williams <email address hidden>:
> Semi-success. Using the fglrx module patch above, my NC6000
> successfully gets into sleep mode. However, it hangs hard when waking
> up. The early stages of waking up go ok but then the machine locks up
> after what looks like a video mode switch.
>
> FYI, the instructions on the web page need a couple of amendments:
> - build the package for ubuntu/gutsy, not ubuntu/feisty
> - delete the existing module in the volatile module directory, do not create the symbolic link
>
> Also, to get this to work, you need to expand /usr/src/fglrx.tar.bz2,
> patch the header file and then rebuild the tarball so that when module-
> assistant expands the tarball, it gets a patched copy of the header
> file.
>
> --
> [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.
>

Elie Charest (archiesteel) wrote :

Strange though, since Matthew managed to get the computer to sleep...

Does that mean there's a possibility that this could be resolved with kernel 2.6.23 (using this patch)? That would not be a simple workaround, but would at least be one - right now it seems as if we're stranded on a limb. I don't even know if I want to go to the trouble of installing Gutsy on my main machine - like many others here, I need both 3D and suspend-to-RAM... :-/

Matthew Williams (number6) wrote :

There are actually two differences between standard gutsy and what I tested. First, there's the patch. Second, it a different version of the fglrx package - 8.41.7 vs 8.37.6.

It's quite possible that the suspend issue is fixed by using the latest module in combination with the patch. There could be a completely separate issue causing my resume to fail OR it could be a issue with 8.41.7 in combination with gutsy. I would think it most likely to be the latter.

Now, I haven't stuck with 8.41.7 because there seems to be a bug with tv-out support and I require it. However, I would be willing to run additional tests if others have suggestions on what I can do to further diagnose 8.41.7.

Elie Charest (archiesteel) wrote :

Version 8.42 of the fglrx driver is supposed to come out next week, I believe. Perhaps it's best to wait, it's an entirely new driver and it's supposed to fix a few issues. Maybe we'll get lucky!

darthvader (sarmbruster) wrote :

maybe we should vote for the bug on ATI's bugzilla: http://ati.cchtml.com/show_bug.cgi?id=739

Timo Jyrinki (timo-jyrinki) wrote :

Mark Hatton, to clear some issues that seem to confuse some people:
> 1) Compiz *is* enabled out of the box and becomes active once fglrx is installed, and so people with
> ATI cards will encounter this suspend/hibernate bug without any prior warning. If this is the situation,
> then surely the Gutsy release should be held until the problem is either fixed by ATI or a workaround
> is made available and documented.
>
> 2) Compiz actually isn't enabled out of the box, in which case whoever writes the introduction page
> (currently http://www.ubuntu.com/testing/710rc for Gutsy) should perhaps amend the wording to
> reflect that fact

Compiz is enabled by default, and _works with the default, free/open source ATI driver_ that Ubuntu uses for most ATI cards ranging from 7500 to X850, except for some specific models with known problems where the driver is used but 3D is disabled by default (can be enabled). For example, on my Radeon X800 works fluently out of the box with Compiz in Ubuntu 7.10, with the open source drivers.

The closed, separetly installable fglrx drivers _do not support currently Compiz at all_, and those should not be used by users wishing to use 3D desktop. The newest released fglrx drivers, apart from the X2000-series-only release, support 3D on cards from 9500 to X1950, covering the extra X1000 range the open source driver does not yet support. However, most people see less 3D with fglrx anyway since the Compiz Desktop Effects do not work.

I understand that if your Mobility Radeon X300 is currently blacklisted in the open source driver for 3D (which would explain your writings), you'd want fglrx to work. However, the point is to get the open source driver work on all cards instead of trying to spend lots of times trying to workaround problems with the closed binary driver. It's not about punishing non-FLOSS users, it's the reality of open source drivers being more beneficial to work for, and from my point of view I'd say ATI's fglrx drivers have always had severe problems, lagging behind X.org and kernel releases, so they are really a poor example of even a closed source driver.

I personally waited 3 years for the fglrx drivers to fix my issues which still aren't fixed by ATI, and amazingly found it easier to bite the bullet and find out why the open source driver did not provide full 3D support for my card. I managed to find the culprit(s) during Ubuntu 6.10 and from 7.04 onwards my range of cards (X800) seem to have full 3D support and a lot less problems than what I had with the fglrx drivers.

I wrote this mainly because most people shouldn't think they _need_ to install fglrx driver for their ATI card. X1000-series need it for proper 2D acceleration, that is given, but so it was with Ubuntu 7.04 so there is no regression. For the Ubuntu 8.04, there will be open source support for both X1000 and X2000 series.

Thank you for listening.

Philipp Kern (pkern) wrote :

Could you please name the driver to install for (mobile) X1600 support? I thought that it is not probably supported by any available open source driver.

Charl P. Botha (cpbotha) wrote :

@Philipp Kern: There is no open source support for the X1600.

@Timo Jyrinki: Please stop with the apologetics.
1. Desktop effects DO work on fglrx, but you have to go the Xgl+Beryl path (I tested this on 7.04).
2. *WHO* exactly is going to stop wasting their time with workarounds and work on these opensource drivers? If there were a team of programmers diligently banging away at their keyboards, I'd agree with your statement, but there isn't, so you have no argument. ATI's fglrx, as crap as it is, is *lightyears* ahead of any open source effort, at least on my ATI Mobility X1600. It takes less effort and skill working around its problems than it takes getting open source drivers fully functional on a modern GPU. Yes, I do have some idea of what I'm talking about: I implemented the first Linux suspend/resume support for DRI-enabled ATI Radeon drivers, check the XFree86 and X.Org logs.
3. I had suspend/resume, desktop effects AND accelerated 3D under Feisty, now I have to give up two of them to get suspend/resume working. BIG REGRESSION.

Thank you for listening. :)

michael37 (misha37) wrote :

@Timo Jyrinki.
"The closed, separetly installable fglrx drivers _do not support currently Compiz at all_, and those should not be used by users wishing to use 3D desktop." is a very misleading statement. I have observed a great effort by the Xgl team in Gutsy to automate detection of the fgrlx driver and enable 3D desktop with fully functional support of all Compiz plugins. If you are unfamiliar with Xgl, please see the link here: http://en.wikipedia.org/wiki/XGL

In a nut shell, in Gutsy one needs to undo all Xgl and Compiz customizations for prior versions and uninstall/reinstall xserver-xgl and Compiz, and then start Compiz. That's it.

@Charl P. Botha
"I had suspend/resume, desktop effects AND accelerated 3D under Feisty, now I have to give up two of them to get suspend/resume working. BIG REGRESSION."
I second that sentiment.

I would just like to add my twopenneth to this by restating that I am successfully using the automatically-installed (big popup balloon pushing me towards restricted drivers straight after the main installation) along with the automatically installed Compiz Fusion.

The main point of my original summary email, which seems to have been missed by some, was the lack of warning to users about a known problem. Any "normal" person with an ATI card (I presume) will get the same bubble that I did about available restricted drivers, and will more than likely install whatever is recommended to them. Nowhere in that process is the user warned that if they do this, that their machine will lock up if they attempt to use suspend/hibernate. If people are warned at the time of installation, then they have a choice as to whether they wish to proceed or not.

This has now been mitigated to some extent by an entry in the release notes, although I doubt many people read that page. I still think that any entry should be put in the main information page's caveat list (where I note there is an entry about suspend problems with an Intel graphics chipset).

Owen Williams (ywwg) wrote :

It should be pretty trivial to add code to the sleep script to check for fglrx and a newer kernel, and refuse to suspend if they are known bad.

Like, say, the attached script, which is no doubt hacky and awful, but at least it would prevent users from suspending their machines improperly.

AaronMT (aaron-train) wrote :

I would just like to add if not already known that my laptop, a Dell Inspiron 1501 (w/Radeon Xpress) embedded video card and Ubuntu 7.10 will not enter or resume from standby or hibernate. This bug unfortunately, if not fixed will ultimately force me to revert back to 7.04 because as a student in school, I need my laptop to enter and resume from standby or hibernate throughout the day.

I would like to know if any other Inspiron 1501 users have the same issue.

- Aaron T

Owen Williams (ywwg) wrote :

There's an easy workaround for this bug. Just use the 2.6.20 kernel from 7.04. That's what I'm doing and everything works fine. You have to manually install fglrx, but it's a lot easier than downgrading.

CheolHan Yoon (mait) wrote :

I have same issue with Inspiron 1501 and fglrx. I would try Xorg
radeon driver for suspend and hibernation.

2007/10/17, AaronT <email address hidden>:
> I would just like to add if not already known that my laptop, a Dell
> Inspiron 1501 (w/Radeon Xpress) embedded video card and Ubuntu 7.10 will
> not enter or resume from standby or hibernate. This bug unfortunately,
> if not fixed will ultimately force me to revert back to 7.04 because as
> a student in school, I need my laptop to enter and resume from standby
> or hibernate throughout the day.
>
> I would like to know if any other Inspiron 1501 users have the same
> issue.
>
> - Aaron T
>
> --
> [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.
>

--
마잇(Mait)

drjimmy42 (jjrussell) wrote :

The earlier workaround suggested of

Create this file:
   /etc/modprobe.d/blacklist-fglrx

Put this in it:
   blacklist fglrx

Reboot.

Worked famously. I know I can't use the cool compiz stuff or other 3D jazz, but for those who just need stuff to work in a basic way, this works around the problem.

Only problem with blacklisting fglrx is that dual head support breaks. Sure, you get the image on both monitors, but the second monitor's mouse pointer is only a giant square (it appears to be XORing with what's behind it) roughly 1"x1" on a 19", 1280x1024 screen.

drjimmy42 (jjrussell) wrote :

Xinerama works with the blacklist module thing. I know its not the same as dual head with fglrx, but we're all about compromise on this thread.

Xinerama really works? I tried using my Xinerama-like setup (mostly just like Xinerama except that I have separate desktops on both displays) and X kept coming up in low-res mode. I had to switch to the Feisty ATI drivers to get my preferred setup to work.

drjimmy42 (jjrussell) wrote :

Ok, I don't want to hijack the bug comments but if you're interested here's my xorg.conf for xinerama with fglrx which works with no kernel module as described. Config for my nvidia card is in there too so just ignore that. http://jjrussell.googlepages.com/xorg.conf

Timo Jyrinki (timo-jyrinki) wrote :

Yep, the restricted manager should warn users about problems with fglrx, in addition to release notes. Actually, I translated the restricted manager so that it gives a small warning about losing desktop effects when using fglrx, since most people think "3D drivers" would give them those by default. Anyway, restricted manager does warn people that using restricted drivers may be problematic because they cannot be fully supported.

Regarding desktop effects, I'm aware that Xgl works with fglrx for desktop effects, but I'm usually talking about ordinary user's perspective, sorry for not pointing that out. No ordinary user will ever install alternative X server, so for most users fglrx does not work with desktop effects. For those people knowledgeable enough to install and configure alternative X server, they can also probably hack away with workarounds that probably will appear for fglrx, or install their own fglrx drivers when the newest ones are released.

Regarding development resources, any time spend with workarounds for fglrx by the core devs would, in my opinion, be away from having top-notch gutsy otherwise, and problems with fglrx generally are frustrating to fix as no source code is available. Simply put, closed drivers should be fixed by the developing company, AMD in this case. Of course, anyone in the community is free to spend time improving fglrx support and offering solution, code and ready-made .deb packages and work on getting that in, but apparently no-one was interested enough or skilled enough to do just that for gutsy. It's too late to complain at this point of time.

And finally regarding X1600, like I stated open source drivers do not yet fully support it in gutsy which is unfortunate, but it's not a regression from Feisty either. There _is_ an experimental xserver-xorg-video-radeonhd for people to experiment with, though. AMD has only very recently decided to improve the situation, so it will take time until AMD/ATI cards are as well supported as eg. Intel graphics. Even NVIDIA provides a fully working open source 2D driver, even though it's obfuscated and their 3D is closed.

Anyway, this is in many ways going off-topic, but Mark's main point of not having proper warnings is a very good one, even though including the fglrx problem(s) in the Release Notes is a good thing.

Phil Estes (estesp) wrote :

It may be worth noting that looking to other new or upcoming releases of other distros is not going to help. Although I initially was frustrated with Ubuntu (and yes, there are other suggestions for improved communication of the problem to users), the frustration should be pointed towards AMD as CONFIG_SLUB=y is going to appear in every distro coming down the pike.. Fedora 8 has it on by default as well. So, on the bright side, maybe the next monthly drop of fglrx (coming soon?) will have a fix for latest (2.6.23 or greater) kernel support (which is really the root fix), and if not, hopefully they will soon hear it from every distro user (fedora, ubuntu, openSuSE at some point?) that they must be compatible with the slub allocator.

michael37 (misha37) wrote :

@Timo Jyrinki
Regarding desktop effects, I'm aware that Xgl works with fglrx for desktop effects, but I'm usually talking about ordinary user's perspective, sorry for not pointing that out. No ordinary user will ever install alternative X server, so for most users fglrx does not work with desktop effects. For those people knowledgeable enough to install and configure alternative X server, they can also probably hack away with workarounds that probably will appear for fglrx, or install their own fglrx drivers when the newest ones are released.

I would like to point out that enabling of alternative X server in Gutsy is accomplished with installing xserver-xgl package and a reboot. And that's it. The underlying complexity of using two displays and running two X servers is completely hidden from an average user. All the scripts are well packaged with the xserver-xgl from standard Ubuntu repositories.

Why am I defending Xgl? Because fgrlx+Xgl+Compiz is a not only capable of fast 3D graphics+desktop effects but also is the only usable combination on laptops with ATI cards and non-standard resolution (like mine, 1440x900 -- not supported by ati driver). And that raises the severity of this bug only greater since I can no longer use suspend on my laptop.

Øyvind Stegard (oyvinst) wrote :

Confirmed on Ubuntu Gutsy 7.10, IBM Thinkpad Z61m, fglrx 8.40.4, linux-image-2.6.22-14-generic_2.6.22-14.46. Suspend does not work, it hangs with black screen and suspend-indicator led blinking.

Martin Man (mman) wrote :

For those who want a viable workaround instead of political wars I managed to make 3d + compiz fusion + gutsy + fglrx working on my T41p with ATI Mobility T2 using the following steps:

1) get 2.6.20-16-generic linux-image and linux-headers from http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/
2) dpkg -i install them, you will also need linux-headers-2.6.20-16 to satisfy dependencies
3) update-grub as root to get 2.6.20-16-generic to the boot menu

reboot to 2.6.20-16-generic

4) apt-get source linux-restricted-modules-2.6.22-14-generic
5) cd linux-restricted-modules-2.6.22-2.6.22.4/
6) sudo sh ./ati-driver-installer-8.37.6-x86.x86_64.run

and install the fglrx version by pressing enter and following the instructions onscreen

reboot again and you should have 3d + compiz ready

of course don't forget to apt-get install xserver-xgl

Martin Man (mman) wrote :

Sorry guys, forgot to mention that this will make the gutsy + xgl + fglrx + compiz + 3d + suspend to ram working, I have verified that, suspend/resume as with feisty, plus desktop cube and others :-)

I assume using the latest Feisty Kernel after upgrading does exactly the same as your workaround?

Any reasons to upgrade to gutsy when keeping the old kernel?

Beryl - XGL running, so I have no need for another Desktop cube .

Paul Meathrel (paulmeathrel) wrote :

Just a another note to confirm this behavior on a Dell Dimension 5100 with a Radeon X600 running fglrx.

Another confirmation of this bug on a Lenovo T60. I upgraded from Fiesty to Gutsy today and suspend is now broken.

I downloaded the source for suspend-0.7 from sourceforge [1]. Installing libx86-dev and pciutils-dev, then doing a make/make install of suspend-0.7
does get me a suspend using s2ram. I'm trying the "blacklist fix" now as well.

With such great work going into Ubuntu, it's unfortunate that a well known breaking bug got rolled out (because of the freeze?)

[1] http://sourceforge.net/project/downloading.php?groupname=suspend&filename=suspend-0.7.tar.gz&use_mirror=superb-west

Workaround:

Following the instructions at the link below gets me a working suspend on a T60.

http://blog.paulbetts.org/index.php/2007/02/11/fixing-software-suspend-hibernate-with-uswsusp-in-ubuntu-feisty-and-edgy/

I take it back -- that workaround doesn't work. It's either suspend or fglrx, not both. I second Terry's post
( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121653/comments/51 )

DJNightRider (djnightrider) wrote :

Hi wisers!
I'm new to Linux and Ubuntu is my first distro.

HW: ASUS W3J Notebook (Core Duo, 1Gb, ATI X1600, Intel Wi-Fi, Intel HDA sound)
SW: Ubuntu 7.10 Gutsy + ATI restricted driver installed

Confirm - suspend/resume/hibernate never completes.
Tried a fix from Martin Man with some additional operations - did work for hibernate feature.
Things that do not work
  USB flash drive can not be mounted correctly
  suspend ok, but resume doesn't work

Martin Man scenario with some additions:
Step One:

#Get the Kernel
wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-image-2.6.20-16-generic_2.6.20-16.32_i386.deb
#Get headers
wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-headers-2.6.20-16_2.6.20-16.32_i386.deb
#Get general headers
wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-headers-2.6.20-16-generic_2.6.20-16.32_i386.deb
#Get restricted modules for kernel
wget http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.20/linux-restricted-modules-2.6.20-16-generic_2.6.20.5-16.29_i386.deb
#Get ATI driver (this look a bit wrong, cause the driver should be included in restricted)
wget --no-check-certificate https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-8.37.6-x86.x86_64.run
#Install kernel
sudo dpkg -i linux-image-2.6.20-16-generic_2.6.20-16.32_i386.deb
#Install Headers
sudo dpkg -i linux-headers-2.6.20-16_2.6.20-16.32_i386.deb
#Install General Headers
sudo dpkg -i linux-headers-2.6.20-16-generic_2.6.20-16.32_i386.deb
#Update GRUB (not really required, cause GRUB is updated during kernel install)
sudo update-grub
#Reboot - On start select the 2.6.20-16 kernel
sudo reboot

Step Two:
#During start select the 2.6.20-16 kernel
#Install restricted modules for kernel
sudo dpkg -i linux-restricted-modules-2.6.20-16-generic_2.6.20.5-16.29_i386.deb
#Install ATI Driver
sudo sh ./ati-driver-installer-8.37.6-x86.x86_64.run
#Reboot - On start select the 2.6.20-16 kernel
sudo reboot

Now my Compiz + xgl + fglrx work fine
Had to apply some fixes to make my HDA sound work - these actions are same as if I had 7.04 installed.
What else can be done:
  add feisty repository records to your sources.list - may help one day
  edit GRUB menu to make 2.6.20-16 kernel boot as default - DO NOT REMOVE THE 2.6.22 kernel from boot list - it may be required to perform failsafe operations while connected to power outlet
  wait for official bugfix/solution

Regards,
Yury

Emanuel (emanuel-ngine) wrote :

@DJNightRider / Yury

Your resume likely fails cause you have:

POST_VIDEO=true

in your /etc/default/acpi-support

Try changing it to false - i suspect this could do the trick for resume.

best
Emanuel

Philipp Kern (pkern) wrote :

Dear future bug commenters,

time to invoke my Ubuntu hat.

Please consider that you generate a lot of noise for many people if you comment on this bug. No more confirmations are needed. And please do not assume that the "usual" workarounds like "POST_VIDEO" and vbetool stuff will work here. The problem is confirmed, traced back to the problem and cannot be *solved* by Ubuntu developers except by either introducing a special kernel flavour which they already refused or by ATI releasing a fixed driver.

When you apply the workarounds stated here you are on your own. They might or might not work. If you are about to add another one, please consider if there is a sensible amount of new information in your comment (in contrast to the previous ones) and please don't just comment for the sake of it, subscribing to the bug does not need a comment but could also be done through the "Subscribe" action on the top-left of the bug page.

Kind regards,
Philipp Kern

description: updated
Joel Ebel (jbebel) wrote :

I think what many of us would like to hear is some reasons. I feel certain that there must be some reason that the Ubuntu kernel developers didn't want to just go back to using SLAB until this is fixed. Or some reason that they "refused" to make a special kernel version. But thus far in this bug, no such reasons have been given, and without them it simply appears that Ubuntu doesn't care. Perhaps because the kernel devs don't use ATI based laptops. I understand that making such decisions is a difficult task, and taking the time to explain all of your decisions is very time consuming, but in this case, the decisions made have a significant negative impact on a significant number of users, and without an explanation, they all feel left out in the cold with a significant functional regression from the previous version.

If Ubuntu is supposed to be openly and publicly developed, then information behind these decisions should be made available. And if Ubuntu is supposed to be about humanity to others, it would be nice to know why these decisions that seem particularly inhumane must be made. Ubuntu developers refusing is not a good enough reason.

I have a T60p, which the opensource ATI drivers don't support, so I have to use the vesa driver if I don't get fglrx working. There are all kinds of reasons I don't want to use the vesa driver. One of the largest visible ones is the lack of dpms support. I can't blank my screen to save power. So I'll just have to recompile a kernel without SLUB, but that's inconvenient for me, and I don't understand Ubuntu wouldn't want to offer this for me.

I know there's a good reason. Just please share it with us.
Thanks,
Joel

Philipp Kern (pkern) wrote :

The kernel developers did not share there insight into this with me. I'd guess from what I heard from them that SLUB is easier to debug and performing better than the old allocator.

I understand the reasoning why they do not provide special SLAB flavours, though: this would double the number of kernel flavours as every flavour in existence needs to be provided as a SLUB and a SLAB one. Now I already suggested to only provide SLAB flavours for generic variants, but the kernel developers repeatedly called me insane for the call for different flavours where only the memory allocator differs.

Isaac Su (me-isaacsu) wrote :

Is there anyway we can just pre-compile some kernels with SLAB (along
with whatever modules maybe needed), and just host it somewhere, or
maybe even seed it on a torrent? I'll be happy to seed it if someone can
provide the binaries/deb files.

Philipp Kern wrote:
> The kernel developers did not share there insight into this with me.
> I'd guess from what I heard from them that SLUB is easier to debug and
> performing better than the old allocator.
>
> I understand the reasoning why they do not provide special SLAB
> flavours, though: this would double the number of kernel flavours as
> every flavour in existence needs to be provided as a SLUB and a SLAB
> one. Now I already suggested to only provide SLAB flavours for generic
> variants, but the kernel developers repeatedly called me insane for the
> call for different flavours where only the memory allocator differs.
>

Elie Charest (archiesteel) wrote :

Philip: in other words, Kernel developers are basically saying that ATI
users should not in fact upgrade to Gutsy? I'm not sure that is very good
press for Ubuntu, considering the *large* amount of laptops out there that
have ATI chipsets...

It wouldn't be so bad if Gutsy didn't prompt users to install fglrx, which
then prevents use of Suspend/Resume.

This is disappointing, and hearing that kernel developers made that choice
so that things would be more convenient for *them* rather than us ATI users
is rather frustrating, to say the least. I at least hope they are
communicating with ATI to make sure the latter are working on a fix...

In the meantime, I suggest that *everyone* that is affected by this bug
register on the unofficial ATI bugzilla (linked above in this thread) and
vote for the bug. That looks like the best current way out of this mess.

On 10/20/07, Isaac Su <email address hidden> wrote:
>
> Is there anyway we can just pre-compile some kernels with SLAB (along
> with whatever modules maybe needed), and just host it somewhere, or
> maybe even seed it on a torrent? I'll be happy to seed it if someone can
> provide the binaries/deb files.
>
> Philipp Kern wrote:
> > The kernel developers did not share there insight into this with me.
> > I'd guess from what I heard from them that SLUB is easier to debug and
> > performing better than the old allocator.
> >
> > I understand the reasoning why they do not provide special SLAB
> > flavours, though: this would double the number of kernel flavours as
> > every flavour in existence needs to be provided as a SLUB and a SLAB
> > one. Now I already suggested to only provide SLAB flavours for generic
> > variants, but the kernel developers repeatedly called me insane for the
> > call for different flavours where only the memory allocator differs.
> >
>
> --
> [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.
>

--
Élie Charest

Wolfgang Glas (wglas) wrote :

This bug is not of wishlist importance, it is a major bug. If it cannot be resolved by your developers, assign it to the SABDFL and make him communicate with ATI about the poor quality of their driver. If this does not cure the problem, tell him to file a statement to press.

Regards,

   Wolfgang

arturj (arturj-freenet) wrote :

Maybe this bug is not related to ATI drivers only. This happens on my system with ATI-Onboard-Grafix:

Trying suspend from GNOME fails with the symptom described above (machine does not power off, only hard-reset helps). Unloading fglrx kernel module helps!

BUT: from recovery-mode command-line (where fglrx is not loaded) a simple "echo mem > /sys/power/state" leads to the same problem (machine does not power off completely) One the other hand, a "/etc/acpi/sleep.sh" suspends correctly.

Regards,

Artur

Cameron Gorrie (sastraxi) wrote :

Yeah, it's not working here either on an Inspiron 6400 with a Mobility X1400. Was working on Feisty.
I couldn't find this bug a month ago, so there's now another bug with a lot of the same stuff going on:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/140766
Maybe these can be marked as duplicates?
I haven't tried "s2both" seeing as I don't have a swap partition.

Oh, and I've tried 8.37, 8.40, and 8.41 drivers -- all have the same problem, and all drivers worked with Feisty.

Darin Barnes (darin-barnes) wrote :

Same problem, Suspend just performs "Lock Screen", Hibernate does the same with a keyring prompt on top of that. Worked 90% of the time in Feisty with 10% chance of dead keyboard. I tryed recompiling the kernel as a n00b to switch SLUB to SLAB, and it actually suspended, BUT didn't wake up.. and tryed it many times -> same result.... =(

Dell 6400, ATI Mobility X1400, Intel 3945abg, 1680x1050 LCD...

$uname -a
Linux bit-chass 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

$fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6747 (8.40.4)

Darin Barnes (darin-barnes) wrote :

I will repeat mentioned address for ATI Driver Feedback
http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&type=web
write to them maybe it will help.

montag (montag-fire) wrote :

Someone can check if the new Ati driver solves the problem?
http://www.phoronix.com/scan.php?page=article&item=887&num=1

Apparently the suspend issue is _not_ fixed

http://ubuntuforums.org/showpost.php?p=3616584&postcount=40

Gernot Pansy (notz) wrote :

no, the issue remains with 8.42.3

Phil Estes (estesp) wrote :

Yes, it was made clear in the release notes and article that the latest driver still does not have "2.6.23 kernel support", which is most likely a euphemism for not handling the SLUB allocator which is default in 2.6.23. However, the bright side according to the article is that next month's drop is supposed to include it.

As an aside, 8.42.3 does allow use of compiz without xgl since it has AIGLX support built into fglrx. You have to edit /usr/bin/compiz to add "fglrx" to the WHITELIST of drivers that are "allowed" to use compiz.

Marc Quinton (mquinton) wrote :

same hibernate problem with an ATI RC410 [Radeon Xpress 200] graphic card integrated in my mother-board. ATI driver has an other problem to. So I'm seek.

nclm (nclm) wrote :

Could someone perhaps provide packages with fglrx 8.40.4 (due to compatibility issues with firegl) and these two patches applied: http://www.phoronix.com/forums/showpost.php?p=15429&postcount=277

Spot the steady stream of duplicate bugs coming in now as poor Ubuntu users who upgraded to Gutsy presumed that there would have been no regressions and instead found their laptops no longer suspend.

We really need ATI/AMD to get a working fglrx out the door asap. Until then there will be a lot of Linux newbies breaking their machines trying to run on custom SLAB kernels.

aldebx (aldebx) wrote :

please have a try with latest AMD/ATi drivers ver. 8.42. these seem to fix this bug.
with those shipped with Ubuntu Gutsy 7.10 I experienced this problem as well, however after upgrading I can again suspend and hibernate without any issue.

a prepacked version from ubuntu repositories is not yet available (it will be in some time) in the meantime you can download them from: http://www2.ati.com/drivers/linux/ati-driver-installer-8.42.3-x86.x86_64.run

please remember to run aticonfig --initial after installing and also that after each further kernel update you will need to re install them as far as the package will not be provided directly from ubuntu repositories.

I still can't suspend with 8.42... I'm currently building a SLAB kernel to rule that out.

Alexey Borzenkov (snaury) wrote :

Are you all sure that recompiling with SLAB will actually help? I just did `apt-get source linux-source-2.6.22` to check that when I found that -rt kernel is already configured with SLAB, yet hibernate is not working for me! I'm on ASUS F3JP, gutsy amd64.

8.42 will not fix this bug.
It doesnt have 2.6.23 support, this kernel has in standard configuration SLUB.
Reports on the internet show that suspend will not work.
I hope that 8.43 solves this problem.

I installed this version of the driver and now my windows move very,
very slowly. My X is basically fubar'd with the ati driver. How can I
remove it and go back to the less busted version that came with Gutsy?

Thanks,
Clay

On Thu, 2007-10-25 at 18:19 +0000, aldebx wrote:

> please have a try with latest AMD/ATi drivers ver. 8.42. these seem to fix this bug.
> with those shipped with Ubuntu Gutsy 7.10 I experienced this problem as well, however after upgrading I can again suspend and hibernate without any issue.
>
> a prepacked version from ubuntu repositories is not yet available (it
> will be in some time) in the meantime you can download them from:
> http://www2.ati.com/drivers/linux/ati-driver-
> installer-8.42.3-x86.x86_64.run
>
> please remember to run aticonfig --initial after installing and also
> that after each further kernel update you will need to re install them
> as far as the package will not be provided directly from ubuntu
> repositories.
>

Clayton Taylor Dillard

http://hspcd.blogspot.com/

Attached please find my xorg.conf file with a "Generic Video Card"/vesa driver. This works on a Lenovo T60.

Copy this to /etc/X11/xorg.conf:
#sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup (back up your current X config file)
#sudo cp ~/Desktop/xorg.conf /etc/X11/xorg.conf (copy this one in)
restart X

X works nicely for me in Gutsy on my T60 sans "Normal" or "Extra" visual effects (System->Preferences->Appearance->Visual Effects)

Hope that helps, Clayton

"Are you all sure that recompiling with SLAB will actually help?"

Yes. I compiled my own kernel, exactly like Ubuntu's except for SLAB being enabled instead of SLUB, and now the machine suspends properly. It doesn't wake up properly, but that's another, older bug (Bug #84991).

"I installed this version of the driver and now my windows move very,
 very slowly. My X is basically fubar'd with the ati driver. How can I
 remove it and go back to the less busted version that came with Gutsy?"

Make sure that you put Option "TexturedVideo" "on" in the ServerFlags section of your xorg.conf. This changed my AIGLX performance radically.

"X works nicely for me in Gutsy on my T60 [with the vesa driver]"

Yup... this bug only applies to suspending with the FGLRX driver. My machine suspends (using hibernate-ram) with the new RadeonHD driver, whether I have SLAB or SLUB. When the FGLRX kernel module is loaded, however, it only suspends if I use a kernel with SLAB allocation.

Just in case anyone else wants to try it without an hour of compiling, I've put my SLAB kernel at http://screamingarmadillo.org/SLAB.

damagedspline (icpazi) wrote :

"Just in case anyone else wants to try it without an hour of compiling, I've put my SLAB kernel at http://screamingarmadillo.org/SLAB."

Xpress 200M on Fujitsu-Amilo A1650g with fglrx.

I've installed the kernel modules and suspend/hibernate does not resume here when POST_VIDEO=false.

FGLRX (8.42.3) is installed OK - I get AIGLX + compiz.

Does suspend/hibernate require that compiz will be off? Should the fglrx km be compiled with the CONFIG_PM_SLEEP patch?
What about the SAVE_VBE_STATE and USE_DPMS in /etc/default/acpi-support are they "true" or "false"?

"I've installed the kernel modules and suspend/hibernate does not resume here when POST_VIDEO=false."

Nope, resuming doesn't work for me, either (Bug #84991 is still an issue for me, no matter what's in my /etc/default/acpi-support file). The important thing for the purposes of this bug is that suspend works with a SLAB allocator.

As for actually resuming... sorry, I'm in the same boat as you. Suspend/resume used to work back in Edgy; I'm seriously tempted to go back just for working suspend and resume.

Right now I choose between eye candy (FGLRX + Compiz) or working suspend/resume (RadeonHD); I'm currently in eye candy mode, but who knows what tomorrow will bring?

Cameron Gorrie (sastraxi) wrote :

Apparently you can get everything working with Feisty -- at least, 8.41 did
working suspend/resume, one can only assume 8.42 on Feisty will as well
bring the working suspend/resume (and, of course, the "eye candy").

On 27/10/2007, Jon Anderson <email address hidden> wrote:
>
> "I've installed the kernel modules and suspend/hibernate does not resume
> here when POST_VIDEO=false."
>
> Nope, resuming doesn't work for me, either (Bug #84991 is still an issue
> for me, no matter what's in my /etc/default/acpi-support file). The
> important thing for the purposes of this bug is that suspend works with
> a SLAB allocator.
>
> As for actually resuming... sorry, I'm in the same boat as you.
> Suspend/resume used to work back in Edgy; I'm seriously tempted to go
> back just for working suspend and resume.
>
> Right now I choose between eye candy (FGLRX + Compiz) or working
> suspend/resume (RadeonHD); I'm currently in eye candy mode, but who
> knows what tomorrow will bring?
>
> --
> [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.
>

@Jon Anderson
Why is your linux-image so big? 200 MB are quite much...

arturj (arturj-freenet) wrote :

@Thomas
Yeah, this is a really bad documented issue when building a custom kernel. Ubuntu ships the kernel config file with ENABLED debug info, although the kernel is build without this feature, (see Kernel-Hacking category) which you have to disable first. I have search a long time to find this out, posted tens of questions into forums and nobody seemed to know this as nobody answered. Finally I found the answer in the official Ubuntu WIKI (search for "custom kernel").

stevieh (stevieh) wrote :

@John
I am even to dumb to get the radeonhd driver running. Is this the one included in gutsy? Could you place your xorg. conf for that somewhere?

Elie Charest (archiesteel) wrote :

@stevieh
This is a bug report - not the place for support. Try
www.ubuntuforums.organd/or
www.ubuntuguide.org.

On Nov 1, 2007 6:43 PM, stevieh <email address hidden> wrote:

> @John
> I am even to dumb to get the radeonhd driver running. Is this the one
> included in gutsy? Could you place your xorg. conf for that somewhere?
>
>

ATI release the Catalyst 7.11 driver for Linux yesterday [1] (there was a name/version change from fglrx 8.xx.x -> Catalyst x.x). It's supposed to bring the "Kernel 2.6.23 support". So I was of course very eager to try it out. So I downloaded it, made my *.debs and installed it. But my machine *still* hangs on suspend. Could somebody please try as well - maybe I'm just not capable of installing it properly.

[1] http://www.phoronix.com/scan.php?page=article&item=922&num=1

cement_head (andorjkiss) wrote :

Did you completely remove the existing driver, before installing the updated driver?

I made *.deb's, they just overwrite the old version. Anyway, I found other people complaining in the Phoronix forums, so it seems ATI simply didn't fix what they promised to fix.

roofone (roofone) wrote :

Doesn't work for me either. I get the same blinking moon on my Thinkpad.

Cameron Gorrie (sastraxi) wrote :

Same for me, and this one is a fresh install.

On 22/11/2007, roofone <email address hidden> wrote:
>
> Doesn't work for me either. I get the same blinking moon on my Thinkpad.
>
> --
> [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.
>

Sean McIntyre (s-mcintyre0) wrote :

Yep. Catalyst 7.11 didn't fix suspend on my machine either.
Good times.

aflores (arflobow) wrote :

I tried installing ATI Catalyst 7.11, but I get extremely choppy video. Didn't even try to suspend/resume because something was obviously wrong. I had the same problem when installing the previous version of ati's driver. Anybody else have this kind of problem?

roofone (roofone) wrote :

I had choppy video when I did the express install. It works pretty well after uninstalling and reinstalling manually with deb packages. I have a mobility 9600.

-----Original Message-----
From: aflores <email address hidden>

Date: Fri, 23 Nov 2007 00:37:22
To:<email address hidden>
Subject: [Bug 121653] Re: [gutsy] fglrx breaks over suspend/resume

I tried installing ATI Catalyst 7.11, but I get extremely choppy video.
Didn't even try to suspend/resume because something was obviously wrong.
I had the same problem when installing the previous version of ati's
driver. Anybody else have this kind of problem?

--
[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.

Kyle M Weller (kylew) wrote :

I had an ati x1300 pci and I had to take it back to the store because ubuntu
doesnt support it and ati's drivers are a shame because its proprietary, the
only thing they are hiding is bad code

Aaron Sarna (shoofy) wrote :

The way around the choppy video is to switch the video player to using X11 video instead of XVideo. Apparently this is only a problem when using compiz. X11 is somewhat lower quality in my experience, but it's a usable workaround for now.

aflores (arflobow) wrote :

how do i switch to x11 video? i'm still pretty new to linux, just switched over 4 weeks ago.

Aaron Sarna (shoofy) wrote :

It's different for every video player pretty much. http://wiki.compiz-fusion.org/VideoPlayback gives instructions for the most popular ones. Ignore the fact that it's discussing black screens.

flynn (flynn) wrote :

@aflores
Try this: Just press the key "F2" and enter "gstreamer-properties" then click
execute. In the Video tab you can change the plugin to x window system
(without xv).

flynn (flynn) wrote :

The App-Launcher shortcut is of course "alt + F2" or start gstreamer-properties from the terminal.
Sorry for the double post.

aflores (arflobow) wrote :

ah, you guys misunderstood me. When I said "choppy video" I didn't mean choppy video in video player, I meant choppy video in general. Maybe the term "choppy video" is the wrong term to use. If I tried to move an open window, it would respond extremely slow, the movement of the window was "choppy" as in I could see the window first in one place, then half a second later, it would be in a different part of the screen. So something was obviously very wrong with my installation. Furthermore, if I typed fglrxinfo in console, it would restart xwindows (not reboot). Something went even more wrong the next time I tried to install the ati catalyst driver, I couldn't even log in. Every time I tried to log in, my laptop would reboot. I had to boot in recovery mode and remove the driver, sigh...

roofone (roofone) wrote :

I had the exact same issues. Uninstalling and reinstalling using .deb packages solved them.

Also, removing xgl via apt-get helped too.

-----Original Message-----
From: aflores <email address hidden>

Date: Fri, 23 Nov 2007 17:24:51
To:<email address hidden>
Subject: [Bug 121653] Re: [gutsy] fglrx breaks over suspend/resume

ah, you guys misunderstood me. When I said "choppy video" I didn't mean
choppy video in video player, I meant choppy video in general. Maybe
the term "choppy video" is the wrong term to use. If I tried to move an
open window, it would respond extremely slow, the movement of the window
was "choppy" as in I could see the window first in one place, then half
a second later, it would be in a different part of the screen. So
something was obviously very wrong with my installation. Furthermore,
if I typed fglrxinfo in console, it would restart xwindows (not reboot).
Something went even more wrong the next time I tried to install the ati
catalyst driver, I couldn't even log in. Every time I tried to log in,
my laptop would reboot. I had to boot in recovery mode and remove the
driver, sigh...

--
[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.

aflores (arflobow) wrote :

Is it appropriate to ask when this might get fixed in this forum? I know that this is but is dependant on a fix from ati, has anybody from Ubuntu development team heard from ati if they plan to fix this soon? Also, I realize that the latest version of xorg-fglrx-driver you get from synaptic is 8.37.*, when will the newer versions get incorporated to synaptic? I believe ATI's latest version is 8.43 or 7.11 now that they've changed the version numbering system.

If these types of questions also do not belong here, kindly let me know.

David Mc Nally (david-gmta) wrote :

I installed ATI's latest version of their proprietary driver and this fixed the suspend/resume-bug on my Z60m with and ATI X600 and Gutsy Gibbon.

Charl P. Botha (cpbotha) wrote :

@David McNally:

As far as I can see from http://ati.amd.com/support/drivers/linux/linux-radeon.html version 7.11, released on November 21 2007, is the latest. According to a number of reports earlier on in this thread, this driver does NOT fix the problem.

Could you double-check? Which version of the driver are you using?

Yan Li (yanli) wrote :

David, this is really good news. Could you please tell us the version
number of the driver you are using? Thanks!

David: is your 3D acceleration working?

I tried the latest FGLRX with Gutsy, and /var/log/Xorg.log.0 said that it couldn't load DRI because it requires a more recent version of the X server. If DRI doesn't load, then perhaps suspend/resume might work, but you might as well be using RadeonHD if there's no 3D acceleration.

David Mc Nally (david-gmta) wrote :

@Charl & Yan

I'd love to post info about the driver I'm using, just tell me what you need and how I find it. ;) I've only suspended/resumed once after I installed the driver but I'm sure it worked as it should and I'm sure it didn't work before. I'll try again when leaving the office and let you know if it stalls.

David Mc Nally (david-gmta) wrote :

@Jon

I don't really need 3D accel, I just needed it to be easy to switch between internal and external output and change resolution. How do I check 3D accel?

David:

You can open a terminal window and run the "fglrxinfo" command. If you get this:

display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6958 Release

then your 3D acceleration is working. If the OpenGL vendor string says something about Mesa, then your acceleration isn't working.

David Mc Nally (david-gmta) wrote :

In that case the 3D accel is not working. :|

[david@minus] ~ > fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.1)

Guess I'll have to look into that later. :)

Rocko (rockorequin) wrote :

@David: I found the same as you initially - it *appeared* to fix suspend, but in fact fglrx just hadn't loaded at bootup.

I installed Catalyst 7.11 via ATI's installer (which installs fglrx 8.43.2) and added various xorg.conf options (eg load "dri", load "glx", option "AIGLX" "on"). But I could see from both fglrxinfo and the ATI Catalyst Control Center that it was still using Mesa for opengl.

To get it to work properly, I had to do a few other things:

1. When I ran "modprobe -vf fglrx", it said something like "install /sbin/lrm-video fglrx" (it should say nothing). I commented out the line containing fglrx in /etc/modprobe.d/lrm-video and this fixed it.

2. In the log (dmesg | grep fglrx) there was a message that said something like "fglrx: ... firegl_stub_register failed". I removed radeontool using Synaptic and rebooted.

After this, it was using fglrx for opengl. Of course I still had to whitelist fglrx in /usr/bin/compiz to get compiz working.

The nice thing about fglrx is that with compiz off, 2D rendering is significantly faster (eg displaying images in GQView) than the open source drivers, and 3D apps like Google Earth work (when I try running Google Earth using the open source drivers, it runs chronically slow and often freezes the desktop completely so I have to reboot the PC).

But I find fglrx still has the same suspend problem and compiz performance problems that others have mentioned earlier:

1. Suspend is still broken.

2. With compiz on, animations are 'jerky' (eg when moving windows or minimising to taskbar). Sometimes they are lightning fast, other times they stop briefly half way through so the animations don't flow smoothly like they do using the open-source drivers.

3. With compiz on, apps like Google Earth flicker badly during animations (like when it starts up, showing a spinning Earth).

4. With compiz on, x-video doesn't work (eg no video appears in Totem) even though fglrx says it is a xv provider. If you turn off xv (ie using gstreamer-properties), zoomed video is pixellated, and in any event it's unwatchable on my system because the frame rate is about 1 frame per second.

5. With compiz on, generally 2D rendering is slower, eg it's very noticeably slower to redraw the screen when you restore Firefox or Thunderbird from the taskbar.

naught101 (naught101) wrote :

is there a chance that this problem could appear in the intel driver as well? I can't tell if the symptoms are similar, because they aren't described very accurately here.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/134680

Henrik Nilsen Omma (henrik) wrote :

Has anyone confirmed this with the Hardy 2.6.24 kernel?

Changed in linux-source-2.6.22:
importance: Undecided → Unknown
status: New → Incomplete
Changed in linux-source-2.6.22:
status: New → Invalid
Rocko (rockorequin) wrote :

Suspend in Gutsy still hangs with the latest fglrx release, Catalyst 7.12/fglrx 8.44. (Furthermore, it won't display 1650x1080 anymore on my system. Top effort, ATI.)

I wonder if they are working on it, because the suspend problem doesn't even appear on their list of known issues.

ideefixe (ivan-babkin) wrote :

2Rocko: that's strange. It seems to be fixed in 7.12 fglrx release, at least for me.

Charl P. Botha (cpbotha) wrote :

I've checked and double checked, it does seem that I can suspend and resume (with about 66.6% success rate) with the new fglrx 7.12 release. On this HP NC 8430 with X1600 mobility, I have an up to date Gutsy install with the latest ATI drivers installed via Envy. Setting "DOUBLE_CONSOLE_SWITCH=true" in the /etc/default/acpi-support greatly increased my success rate (from about 1 in 3 tries to 2 in 3 tries).

I would have been quite happy, were it not for the fact that my laptop has a 1680x1050 panel, and this new driver somehow can't activate this resolution (known issue).

I'd be curious to hear about other suspend/resume experiences using this combination.

Some basic info:
$ uname -a
Linux meep2 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1600
OpenGL version string: 2.1.7170 Release

$ glxinfo | grep direct
direct rendering: Yes

From my Xorg.0.log:
(II) fglrx(0): Kernel Module Version Information:
(II) fglrx(0): Name: fglrx
(II) fglrx(0): Version: 8.44.3
(II) fglrx(0): Date: Dec 19 2007
(II) fglrx(0): Desc: ATI FireGL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.

Nicolás Schubert (nischg) wrote :

I installed the 7.12 driver today and at first suspend didn't work for me. Later I reinstalled using envy and now suspend works, however resume doesn't work though. I just get a black screen.
It seems at least we are heading in the right direction.

Erkin Bahceci (cornelius1) wrote :

Tried fglrx 7.12 on a Dell Inspiron 6000 with Mobility X300, 1680x1050 native-res LCD, Ubuntu Gutsy. Stand by and Hibernate finally both work with Gutsy (survived 9 stand by's in a row). Before 7.12, when I tried to suspend, it would stop indefinitely at a black screen. Now it works just fine. Though I'm stuck at 1280x800 max resolution with the new driver.

roofone (roofone) wrote :

Suspend/hibernate is still broken with 7.12 for me on my Mobility Radeon 9600 (IBM T42 Thinkpad): Video flickers and the screen goes black, but neither the screen nor the laptop shuts off, and i can't resume.

On the bright side, my glxgears framerate has jumped from ~1900 fps to ~2600 fps.

$ uname -a
Linux thor 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY RADEON 9600/9700 Series
OpenGL version string: 2.1.7170 Release

Working fine here :O

In previous versions suspend would crash before the laptop could reach suspend (Got 200M/1150). But now everything works as it should!
So they must have fixed something!?! but why not everything...

$ uname -a
Linux nuxWeb 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon Xpress Series
OpenGL version string: 2.1.7170 Release

Cameron Gorrie (sastraxi) wrote :

Suspend has started working with Ubuntu gutsy, the Mobility X1400, and the 7.12 catalyst driver. I think once when it came back the laptop's built-in keyboard and touchpad were not working and I had to re-suspend and re-wake it to make them come back, but it hasn't happened again.

Rocko (rockorequin) wrote :

@ideefixe: I only tested suspend once with 7.12, since the 1280x800 screen resolution is a show-stopper for me, and the compiz effects were still a bit choppy.

I've got a Mobility Radeon 9600 card, like roofone, and I get the same results (ie screen and laptop fail to shut off). I wonder if the latest fglrx works for some cards and not others?

Cameron,
    I installed the latest via Envy but had crummy video performance.
Dragging windows was very slow and compiz did not work.

I have a Lenovo R60 with an ATI x1400 so could you tell us what steps
you performed to get the new ATI driver working with good performance,
suspend & resume working? Did you also use Compiz?

Thanks,
Clay

On Sun, 2007-12-23 at 17:17 +0000, Cameron Gorrie wrote:

> Suspend has started working with Ubuntu gutsy, the Mobility X1400, and
> the 7.12 catalyst driver. I think once when it came back the laptop's
> built-in keyboard and touchpad were not working and I had to re-suspend
> and re-wake it to make them come back, but it hasn't happened again.
>

Clayton Taylor Dillard

http://hspcd.blogspot.com/

Sven Müller (svenho) wrote :

I have a T60 with a X1400 and it doesn't work at all. The display becomes black, the Suspend led is blinking all the time and that's it! :-/

Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!

I just tested with Hardy Heron Alpha2 LiveCD. The bug still exists.

On Gutsy it fails while suspending. On Hardy it managed to suspend, but resuming failed - fans turned on, screen got lit, but nothing else worked, had to hard reset it.

Thinkpad T60, Ati X1300 (fglrx 7.11)

@ E_rulez:
Maybe the fact that Hardy failed on resume is linked to wrong settings in /etc/default/acpi-support? The bug we had before the last driver update didn't let us suspend at all. I'll try again tomorrow with the latest driver on Gusty and check acpi-support because last time I tried, suspend work but it got stuck on resume (And I went back to the old driver because of my resolution is missing...)

westbywest (westbywest) wrote :

Has anyone tested the tuxonice (aka suspend2) kernel patch with the fglrx module? I was unable to get both suspend and hibernation to work with the fglrx module packages in linux-restricted-modules, or with the ATI-supplied module in Catalyst v7.11 and v7.12. In each instance, suspend and hibernation (i.e. tuxonice-enabled resume) would lock up. This has compelled me to roll back to the open source ATI driver.

My specs:
HP NW8240 Laptop, BIOS version 68DTV Ver. F.16
ATI Technologies Inc Radeon Mobility X700 (PCIE)
Ubuntu v7.10
linux-image 2.6.22-14-pentm+suspend2 (tuxonice patch, compiled for Pentium M)
xserver-xorg-video-ati :6.7.197-1ubuntu1~tormod (patched version to fix problem with LCD refresh rate)
xserver-xorg 7.2-5ubuntu13

Rocko (rockorequin) wrote :

I can confirm that suspend works fine with kernel 2.6.24-2-generic (ie Hardy's kernel) using an ATI Radeon Mobility 9600 card. But like E_rulez found, resume fails. The PC starts resuming, turning on screen etc, and then freezes at some point - on one attempt I got as far as trying to log into a console using CTRL-ALT-F2, but it froze before asking me for my password.

I tried both Catalyst 7.11 and 7.12, with the same result.

It is interesting to note that fglrx's compiz performance is *much* smoother under 2.6.24. However, the open-source radeon driver also run smoother under 2.6.24. I can even run Google Earth at acceptable speed (with compiz on) using the open-source driver! On 2.6.22 it flickers horribly and rotates the globe extremely slowly.

stevieh (stevieh) wrote :

AFAIK everything has been said since a long time. Either the kernel configuration has to be changed or the fglrx (closed source) driver from ATI/AMD has to be changed. I am still wondering why the kernel configuration is not changed as I guess there are really many ATI gfx chipset users out there with laptops. Is there a reason for that?

Meanwhile you could fix the standby issue it by

a) Changing from SLUB to SLAB in the kernel konfiguration and rebuild the kernel (and of course all the restricted modules). For me a good starting point was http://www.thinkwiki.org/wiki/Installing_Ubuntu_(Gutsy_Gibbon)_7.10_on_a_ThinkPad_R60 (with the additional change from SLUB to SLAB) but you should understand what you are doing before you start on it...

b) use the radeonhd driver (which I was not able to manage, but it sound not too promising right now)

c) use unaccelerated drivers (which is really a pain)

So, I went out for a) and everything works fine since then. Of course I have to pin now all kernel related stuff until the issue is solved in gutsy or hoary or whatever...

Oh and before someone starts to complain about giving non bug related support in this list here: yes, I know :-)

jkyamog (jkyamog) wrote :

For the resume problem have you guys edited your /etc/default/acpi-support ?

With my nx8220 (ati x600) I had to set the following :
POST_VIDEO=false
SAVE_VBE_STATE=false

for it to resume on ati (oss) driver. fglrx driver already froze on suspend. I just sold my nx8220 and now have a 6910p (ati x2300) using radeonhd drivers. I also had to edit my /etc/default/acpi-support for resume to go through. If Hardy kernel is suspending and having a problem with resuming, then maybe its worth a look into playing with /etc/default/acpi-support

I can confirm that what jkyamog suggests is working with my setup.

Ubuntu 7.10 with ATI x1400 and ATI 7.12 drivers. (Dell Inspiron 6400)

placing

POST_VIDEO=false
SAVE_VBE_STATE=false

in /etc/default/acpi-support works for me.

My computer suspended like it should but resuming gave me a black
screen. Now it works.

Linux portable-dell 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC
2007 i686 GNU/Linux

vincent@portable-dell:~# fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 1.4 (2.1.7170 Release)

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

According to Ingo Molnar, SLAB is the better allocator anyway: http://lwn.net/Articles/261868/
Could the Hardy kernel please be reverted to use SLAB?

stevieh (stevieh) wrote :

If this is the case, is there any reason not to convert to SLAB in Gutsy? Are there any usage numbers of ubuntu on ATI driven Laptops?

Changed in linux-restricted-modules-2.6.24:
assignee: nobody → ubuntu-kernel-team
importance: Unknown → High
status: Incomplete → Triaged
steky45 (skyriacou) wrote :

Why isn't this considered closed - i tried the

POST_VIDEO=false
SAVE_VBE_STATE=false

in /etc/default/acpi-support as given abave by jkyamog and it works for me too (t43 ubuntu upgraded 7.10).

I think the solution should be put in the summary so people dont have to go through all these posts

Thanks a lot to jkyamog for the solution.

2GooD (david+launchpad) wrote :

steky45: It still doesn't work on my T60p with ATI Technologies Inc M56GL [Mobility FireGL V5200].

When I tried kernel 2.6.22-14.47, fglrx 8.443.1 and jkyamog's settings it did not suspend properly on my T60p. Before suspend I captured the fglrxinfo output:

display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY FireGL V5200
OpenGL version string: 2.1.7170 FireGL Release

What works properly is an old Feisty kernel, 2.6.20-16.32, with fglrx 8.40.4-1. Using fglrx 8.443.1 with that kernel was terribly slow for some reason.

DMG46664 (danielmgerson) wrote :

Pardon my ignorance: Will a new restricted driver be released for the apt-get system, so that I don't have to install the catalyst 7.12 driver manually (breaking apt).

DMG

steky45 (skyriacou) wrote :

Ok maybe my comment above that
POST_VIDEO=false
SAVE_VBE_STATE=false
in /etc/default/acpi-support as given abave by jkyamog is the solution, needs to be corrected:

Now when i do
$ fglrxinfo I see:

Xlib: extension "XFree86-DRI" missing on display ":0.0".
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.1)

ie i am using the mesa open-source driver ...
and lsmod does not show the fglrx driver anymore -

I believe before i added those two lines in /etc/default/acpi-support , i saw fglrx in lsmod listing.

westbywest (westbywest) wrote :

@DMG46664
You can compile the closed-source ATI Catalyst drivers into deb files using the following instructions on the unofficial wiki:
http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide

I was able to successfully create and install debs using these instructions, but the latest proprietary driver didn't work with Compiz, and it appeared to break suspend/resume.

dirken (dirkvranckaert) wrote :

I got the hibernate working on a dell inspiron 6000 notebook with integrated ATI x300 card.
What i did in ubuntu gutsy gibbon was downloading the newest fglrx driver i could find from debian: http://packages.debian.org/sid/fglrx-driver
I removed the gflrx driver from ubuntu using the restricted driver manager, then installed the debian i just downloaded from debian.

I also configured the file: /etc/default/acpi-support
by changing the values POST_VIDEO and SAVE_VBE_STATE both to false.

One reboot and i could suspend and hibernate!

One strange thing: fglrxinfo gives me this info:
dirk@chuck:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 7.0.1

Before changing the driver (which is exactly the same, just a new version) ATI was mentioned here :/
Anyone who knows what i possible did wrong?

dirken (dirkvranckaert) wrote :

forgot to say something, in orde for compiz to be running withouth to much problems i had to uninstall xserver-xgl

westbywest (westbywest) wrote :

@dirken
You are indeed supposed to see "ATI Technologies" reported by fglrxinfo and glxinfo. The "DRI R300 Project" that you're seeing may indicate you are somehow still loading the open source ATI driver, since that is what I see reported by glxinfo, and I am only using xserver-xorg-video-ati, not fglrx or xserver-xgl. Did you just uninstall the fglrx/xserver-xgl packages, or did you purge them too?

tupac (vi-pea-no) wrote :

Just wanted to report that after installing the latest ati driver via envy and setting the options suggested by jkyamog, 3D accelaration and suspend/resume
work perfectly on my toshiba laptop with Ati Radeon Xpress 200 M. Before suspending I still have some weird blurring of the screen but afterwards the computer manages to suspend and resume as expected

Emanuel (emanuel-ngine) wrote :

@tupac: not for me. Tried the very same thing on a Thinkpad z61p with ATI x1600 - machine won't suspend, usual symptoms as described above.

Daddy_Cavy (cavy-thecave) wrote :

Hi, I have a T60p, wonderful machine, running a great OS, Gusty. But!!!! I followed all the helps, fixes etc and have come to the conclusion it's still broke.
I've upgraded from 8.37 to 8.44 and the resolution goes to 1280x1024(crappy), yes I've tried to manually set my monitor res etc, but vbe and ddc are built into the fglrx driver and there is no way to turn it off on 8.44 and I get suspend/hibernation perfectly, or I can stay with 8.37 and have great 1680x1050 res but no suspend/hibernation.

Gee what a dilemma, so I'm stuck.

So I guess I'm looking for someone who has got one solution on a T60p working well.
Pls help Obi-wan, your our only help... SW IV :-)

Emanuel (emanuel-ngine) wrote :

ATIs own Wiki has a few words on this in regards to 7.12:

http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide#Suspend.2FHibernation_work_with_7.12

Apparently, it works since 7.12 now for all but a few (including my own, grumble) chipsets.

quote:
 Suspend/Hibernation work with 7.12

With Gutsy release, there was a big problem using the ATI proprietary drivers. The Suspend/Hibernate function stopped working. The problem was due to the new SLUB allocator incorporated in 2.6.22 / 2.6.23 Kernel.

The problem has been solved in the AMD Catalyst 7.12 driver release. Suspend/hibernate is not working for FireGL 5250. For FireGL 5200, suspend works with the 7.12 fglrx kernel module loaded (which did not work before this release) , but does not work if X is running.

For Thinkpad T60 with ATI X1400, to get the laptop to wake up from suspend, I had to change the following in /etc/default/acpi-support:

SAVE_VBE_STATE=false

POST_VIDEO=false

Jaime (jaime-lopez) wrote :

The issue is fully covered in: ThinkWiki
http://www.thinkwiki.org/wiki/Installing_Ubuntu_7.10_(Gutsy_Gibbon)_on_a_Thinkpad_T60

It works with 7.12 but in my experience it is much slower with XGL than
8.40.1

My T60 suspends perfectly fine changing /etc/default/acpi-support and a
custom build of the kernel (I can provide deb's) with SLAB enabled.

On Jan 6, 2008 12:03 PM, Emanuel <email address hidden> wrote:

> ATIs own Wiki has a few words on this in regards to 7.12:
>
>
> http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide#Suspend.2FHibernation_work_with_7.12
>
> Apparently, it works since 7.12 now for all but a few (including my own,
> grumble) chipsets.
>
> quote:
> Suspend/Hibernation work with 7.12
>
> With Gutsy release, there was a big problem using the ATI proprietary
> drivers. The Suspend/Hibernate function stopped working. The problem was
> due to the new SLUB allocator incorporated in 2.6.22 / 2.6.23 Kernel.
>
> The problem has been solved in the AMD Catalyst 7.12 driver release.
> Suspend/hibernate is not working for FireGL 5250. For FireGL 5200,
> suspend works with the 7.12 fglrx kernel module loaded (which did not
> work before this release) , but does not work if X is running.
>
> For Thinkpad T60 with ATI X1400, to get the laptop to wake up from
> suspend, I had to change the following in /etc/default/acpi-support:
>
> SAVE_VBE_STATE=false
>
> POST_VIDEO=false
>
> --
> [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.
******************************************

The widescreen problem is a known issue with this edition of the driver (as usual, I'm waiting for next month's driver). If suspend/resume works, however, that should be it for this bug.

@Daddy_Cavy

I put together an article, describing how to get fglrx+compiz+suspend running on Gutsy. It's a hack, but a workaround until these problems are fixed in any way. See here: http://lanpartei.de/archives/2008/01/701/ .

Basically: Install old 2.6.20-15 Kernel from Feisty and run fglrx 8.40.4

Jaime (jaime-lopez) wrote :

I've uploaded a full bundle of custom deb's with SLAB enabled for the
Thinkpad T60.

The file (115MB)

http://www.gigasize.com/get.php?d=zv54tcjp2gb

It is named 2.6.22-14-thinkpad, but I suppose it will work for other laptops
with ATI x1300. It also includes restricted-modules. The only diference from
the originial ubuntu kernel in the custom build is the SLAB option.

In the bundle there are also debs of fglrx 8.40.1 (the most stable ever)
built with module-assistant (script included). Works like charm with the
kernel above. There is also a copy of my /etc/default/acpi-support and my
/etc/X11/xorg.conf if you want to inspect.

Everything works fine under XGL.

On Jan 6, 2008 12:17 PM, Jaime López <email address hidden> wrote:

> The issue is fully covered in: ThinkWiki
> http://www.thinkwiki.org/wiki/Installing_Ubuntu_7.10_(Gutsy_Gibbon)_on_a_Thinkpad_T60
>
> <http://www.thinkwiki.org/wiki/Installing_Ubuntu_7.10_%28Gutsy_Gibbon%29_on_a_Thinkpad_T60>
>
> It works with 7.12 but in my experience it is much slower with XGL than
> 8.40.1
>
> My T60 suspends perfectly fine changing /etc/default/acpi-support and a
> custom build of the kernel (I can provide deb's) with SLAB enabled.
>
>
>
> On Jan 6, 2008 12:03 PM, Emanuel <email address hidden> wrote:
>
> > ATIs own Wiki has a few words on this in regards to 7.12:
> >
> > http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide#Suspend.2FHibernation_work_with_7.12
> >
> >
> > Apparently, it works since 7.12 now for all but a few (including my own,
> > grumble) chipsets.
> >
> > quote:
> > Suspend/Hibernation work with 7.12
> >
> > With Gutsy release, there was a big problem using the ATI proprietary
> > drivers. The Suspend/Hibernate function stopped working. The problem was
> > due to the new SLUB allocator incorporated in 2.6.22 / 2.6.23 Kernel.
> >
> > The problem has been solved in the AMD Catalyst 7.12 driver release.
> > Suspend/hibernate is not working for FireGL 5250. For FireGL 5200,
> > suspend works with the 7.12 fglrx kernel module loaded (which did not
> > work before this release) , but does not work if X is running.
> >
> > For Thinkpad T60 with ATI X1400, to get the laptop to wake up from
> > suspend, I had to change the following in /etc/default/acpi-support:
> >
> > SAVE_VBE_STATE=false
> >
> > POST_VIDEO=false
> >
> > --
> > [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.
> ******************************************

--

******************************************
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.
******************************************

RavanH (ravanhagen) wrote :

With the new 7.12, Suspend and Hibernate still do not work for me on a Packard Bell with Radeon Xpress 200M... :(

Martin Man (mman) wrote :

Tried catalyst 7.12 over the weekend on Thinkpad T41p with ATI Mobility
T2, 2.4.22-generic from gutsy as well as 2.4.24-generic from hardy.

Kernel module loads, X works fine, but any GL applications segfaults
with dmesg showing some strange mutex lookup errors from kernel fglrx
module.

Haven't tried suspend/resume since 3d was not working anyway. This seems
to be related to the fact that 7.12 is the first catalyst release after
many months to support this old Mobility T2 board again.

HTH,
Martin

Raphael Kimmig (rkimmig) wrote :

Jaime wrote on 2008-01-06:
> I've uploaded a full bundle of custom deb's with SLAB enabled for the
> Thinkpad T60.
Thanks for your efforts !
Suspend/Resume now works flawlessly on my Dell Inspiron 6000 (x300).

regards

raf

drjimmy42 (jjrussell) wrote :

When I think of "fixed" I think of, the little orange starburst in the panel came up, I updated and now it works.

Is that ever going to happen on Gutsy or will this fix have to wait for the H* release?

Phil Estes (estesp) wrote :

ATI released Catalyst 8.1 this morning (at least my RSS feed updated this AM with the news).. big claims in the readme:
 - Ubuntu 7.10 shown as supported
 - 2.6.23 suspend/resume issues (to ram or disk) fixed

I will be trying it out this morning, but if this is a winner, I hope that Ubuntu will take the time to update it's fglrx driver to this level--in this bug alone there has been enough anguish for ATI h/w users and suspend/resume. It also includes support for my hardware (Mobility T2) so it seems like Catalyst as of this release now has broad enough support to be a valid replacement for the Gutsy current fglrx. If nothing else, hopefully this will be in hardy-backports or some other reasonable location to get updates and not have a separate installation of the driver.

Oh..and for those who have mentioned the mess up with resolution (1680x1050 unsupported) that is claimed as fixed as well..

Just installed 8.01
Looks good on 200M
Thought I messed something up because the GDM font was looking big again but they fixed the small letters (but i liked the small letters :( )

No more corruption in lower corner ( 30 min and counting, usually i have them in 15 min ) and suspend still works like a charm.
My screen is only 1280x800 so no report on big screen here and removed hardy by gutsy so no report on that kernel

Rocko (rockorequin) wrote :

On my system with the ATI Radeon Mobility 9600 card:

* They've fixed the 1680x1050 problem.

* Suspend still works on the 2.6.24-3-generic kernel. (ie I'm not using the default Gutsy kernel)

* Resume still fails.

* Videos still fail to play in totem with compiz turned on (ie using xv).

* Moving windows around on the screen with compiz on is still not as 'smooth' as with the open source drivers.

This version is definitely better: I am no longer experiencing screen corruption on the lower right nor near the cursor, which seemed to occur after a certain length of time. Miraculously, composite actually works, allowing compiz to run under a normal xorg session, however there are a number of issues:

* The refresh rate with compiz enabled is terribly slow, video is almost unwatchable due to slow frame rate. Without compiz enabled, everything is fine (I am even getting amazing rates for hardware acceleration.

* With compiz enabled, after a certain length of time (it seems to occur most with a terminal open), the window painting becomes desynced compared to the actual window position (that is, when you try to move a window, you realize it is actually about 300px to the left), and moving the window leaves traces on the windows behind. This may be a compiz problem, but I had never experienced it before using the newer driver.

These problems make compiz unusable, which is a shame.
Also:

* Suspend works, in that it goes to sleep (after a fast blinking of the screen, which is probably due to a 'fade out' effect gone wrong), and stops the computer. It appears to take a little longer than before, but its not really an issue.

* However resume fails. Computer restarts ok, but then never reaches X again. Sometimes, even Sysreqs don't work, showing a major kernel freeze. This is bad, as the previous version of the driver worked about one in three times (though sometimes causing the HD to grind, making everything too slow).

So in conclusion my current experience with the latest driver causes better graphics than the older one, and better overall stability. However compiz is too slow to use, and resume fails. This may be a configuration issue, so if anyone has any tips,...

I am using the generic 7.10 kernel, and have an ATI RADEON X700 embedded card.

Have you tried:

/etc/default/acpi-support:

SAVE_VBE_STATE=false

POST_VIDEO=false

Because mine would not resume without this.

cement_head (andorjkiss) wrote :

a few questions about upgrading here: http://ubuntuforums.org/showthread.php?p=4166067#post4166067

-thanks

I believe BUGS.launchpad.net is for reporting bugs, but in your thread I posted a comment.. good luck and try to use launchpad like it is suppose to

Alexei Colin (alexei.colin) wrote :

System: Ubuntu Gutsy 7.10 (Kernel 2.6.22-14-generic) on Thinkpad T60, ATI Mobility Radeon X1400

- Installed 8.01 using Method 2 from here:
http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide#Method_2:_Install_the_Catalyst_8.1_Driver_Manually
- Changed /etc/default/acpi-support as suggested by osteenbergen above.

Suspend and Hibernate both work great! Yay!

But they only work when System->Preferences->Appearance->Visual Effects
is set to None. Otherwise, the effects are pretty, but the computer does not
suspend/hibernate. Do settings in Visual Effects tab have *anything* to do with
compiz? (I never installed compiz, but compiz is a valid shell command)

On a separate note, installing xserver-xgl package makes things
worse: computer freezes upon logout. So, I have it uninstalled now.

Some other observations: mplayer plays well in both x11 and xv; Google
Earth works smoothly; fgl_glxgears says: "4683 frames in 5.0 seconds = 936.600 FPS"

SixedUp (disposable01) wrote :

IBM Thinkpad T60p, with an ATI Mobility FireGL V5200, running with a fresh install of Gutsy 7.10 (Kernel 2.6.22-14-generic), to which I added nothing but the 8.01 fglrx using the manual install method from wiki.cchtml.com.

Despite trying most combinations of the previously recommended changes to /etc/default/acpi-support, both with and without compositing enabled, I still can't get the machine to even suspend (let alone resume). System ends up with the screen blank, the suspend LED blinking (it never gets to solid-on), but with the screen backlight running and the fan on. At that point the system is unresponsive and needs to be power-cycled. Looking at the release notes for 8.01, it looks like suspend/resume with the FireGL 5200 requires a 2.6.23 or higher kernel.

Are there any pre-canned 2.6.23+ kernels available for Gutsy (backported or otherwise), or am I going to be faced with compiling a custom kernel?

Rocko (rockorequin) wrote :

If you add the hardy repositories, you can install the 2.6.24 kernel.

ie add

deb http://archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse

to /etc/apt/sources.list and do 'sudo apt-get update' (or you can do it via the Repositories / Third-Party software and Reload button in Synaptic).

I didn't install all the updates, only the latest linux-image, libc, and the gcc/g++ compilers (libc etc so I could recompile various apps without complaints). If you disable the hardy repositories afterwards, the update manager won't keep telling you there are hundreds of updates available.

SixedUp (disposable01) wrote :

IBM Thinkpad T60p, with an ATI Mobility FireGL V5200. Software stack is now a fresh Gutsy install, with the kernel upgraded to the Hardy kernel (2.6.24-4) using the mechanism suggested by Rocko, and the latest (8.01) proprietary ATI fglrx drivers manually installed. I now have working hardware acceleration, with both compiz-fusion (set to full effects) and suspend/resume apparently working cleanly. I will need to wait until I get into the office tomorrow before I can try the VGA port to see if I get a working secondary display too, but at the moment it's looking *extremely* promising.

Bernhard Gehl (bernhard-gehl) wrote :

Wow, that sounds like extremely good news! However, I cannot reproduce this on my LG S1 Express Dual (Radeon Mobility x1600, fglrx 8.01, generic Gutsy kernel). :-(

Could you post your /etc/default/acpi-support and xorg.conf ?

SixedUp (disposable01) wrote :

Changes to /etc/default/acpi-support are limited to those recommended in thinkwiki (and earlier here). Namely I have reversed the following two settings, making them now read:
SAVE_VBE_STATE=false
POST_VIDEO=false
Everything else is original, as it was installed by the Gutsy installer.

My xorg.conf is also original, apart from the change to enable the fglrx driver rather than the vesa driver (my only other option). I've attached it anyway, hope that helps.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux-restricted-modules-2.6.24 - 2.6.24.6-4.13

---------------
linux-restricted-modules-2.6.24 (2.6.24.6-4.13) hardy; urgency=low

  [ Timo Aaltonen ]
  * nvidia: Update to 169.09
    - Fixed a problem causing the fan on some GPUs to always run
      at full speed. (LP: #184914)
    - Fixed a bug that caused the X driver to crash if the X.Org
      GLX extension module was loaded intead of NVIDIA's.
    - Improved the X driver's awareness of the current notebook
      docking status.
    - Fixed brightness control on HP Compaq notebooks.
    - Fixed a bug in the Linux/i2c algorithm driver implementation
      that prevented core transfer types from succeeding.
  * fglrx: Update to 8-01 (LP: #177829, #148345)
    - Corruption will no longer be noticed in the lower right corner
      of the display or on the mouse pointer after the system is
      running for a long period of time. (LP: #106148)
    - Connecting a display device that supports 1680x1050 to a system
      running Linux will no longer result in a maximum display resolution
      of 1280x1024 only being available.
    - Custom mode lines in xorg.conf will no longer be ignored by the
      fglrx driver.
    - Suspending to RAM or DISK on kernel version 2.6.23 or later no
      longer fails. (LP: #121653)
  * nvidia/nvidia-glx-config: Remove, not needed anymore and only confuses
    people and breaks keyboard setups (LP: #152486)
  * control.stub.in: Add fglrx-amdcccle dummy package for easy transition
    from packages generated by the ATI installer.
  * fglrx-control:
    - Remove fireglcontrol*.desktop, and install amdcccle*.desktop from
      the extracted installer instead.
    - Install amdcccle in this package, not the driver.
    - Conflicts/Replaces xorg-driver-fglrx <= $previousversion.
  * fglrx.xsession: Obsolete by now, removed.
  * Drop obsolete build-dependencies: libxxf86misc-dev, libxtst-dev,
    libxxf86vm-dev, libxinerama-dev, libstdc++5, libqt-mt-dev.

  [ Johan Kiviniemi ]
  * nvidia_supported: New version to support the latest NVIDIA
    release. (LP: #182237)

 -- Timo Aaltonen <email address hidden> Wed, 23 Jan 2008 11:41:54 +0200

Changed in linux-restricted-modules-2.6.24:
status: Triaged → Fix Released
trikrasne (trikrasne) wrote :

is it posible to install only linux-restricted-modules-2.6.24 on gutsy, or must i also install any other package (linux-image ... ?) to make it work?

I've got the new ATI driver installed and it works just fine on my
Lenovo R60 with an x1400. Suspend and resume work as well. What's the
trick to getting Compiz to work now? And, will enabling Compiz break
suspend/resume?

Thanks,
Clay

On Wed, 2008-01-23 at 08:44 +0000, SixedUp wrote:

> Changes to /etc/default/acpi-support are limited to those recommended in thinkwiki (and earlier here). Namely I have reversed the following two settings, making them now read:
> SAVE_VBE_STATE=false
> POST_VIDEO=false
> Everything else is original, as it was installed by the Gutsy installer.
>
> My xorg.conf is also original, apart from the change to enable the fglrx
> driver rather than the vesa driver (my only other option). I've attached
> it anyway, hope that helps.
>
> ** Attachment added: "xorg.conf"
> http://launchpadlibrarian.net/11492647/xorg.conf
>

Clayton Taylor Dillard

http://hspcd.blogspot.com/

SixedUp (disposable01) wrote :

359: I'm not an expert, but you need to install the 2.6.24 kernel, plus the modules, plus the kernel headers and the compilers to enable you to make the ATI install packages. You'll need to install them, then boot into the new kernel, and then make and install the new ATI driver. For me, that initial boot into the new kernel seemed to have mis-matched driver/xorg stuff that resulted in a broken GUI too, so expect to need to do that in a virtual console (or at least, that's what I had to do). I'm still feeling my way as to what else I might need to upgrade at the moment.

Clayton: I can't remember exactly, but I have a strong suspicion it was as simple as System -> Preferences -> Desktop Effects, and ticking the appropriate box.

BTW, I've also run across this problem that FrancoisBotman reported, so the drivers are still a work in progress, but at least they're working better than they ever have (for me!) before:

[quote]
* With compiz enabled, after a certain length of time (it seems to occur most with a terminal open), the window painting becomes desynced compared to the actual window position (that is, when you try to move a window, you realize it is actually about 300px to the left), and moving the window leaves traces on the windows behind. This may be a compiz problem, but I had never experienced it before using the newer driver.
[/quote]

Alexei Colin (alexei.colin) wrote :

System:
Ubuntu Gutsy 7.10 (Kernel 2.6.24-4-generic) on Thinkpad T60, ATI Mobility Radeon X1400,
ATI's fglrx v8.01, Compiz via AIGLX (xserver-xgl package NOT installed)

Suspend/resume works with Compiz! It takes about 15sec to suspend.

Compiz runs smoothly. BUT
- glxgears - messed up output (not attached to window)
- fgl_glxgears - segmentation fault
- xv video output flickers and is also not attached to window
- x11 output works well

Christian Assig (chrassig) wrote :

I can hardly believe it, but it looks like I finally have fglrx working again after years, together with suspend and resume on my notebook with an ATI Mobility Radeon 9600.

I'm running Kubuntu Gutsy, and I followed the advises from this bug, including:
- Updating the kernel to 2.6.24-5 (see http://ubuntuforums.org/showthread.php?t=646755 for instructions)
- Installing the following hardy packages from http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.24/ :
fglrx-amdcccle, fglrx-control, linux-restricted-modules, linux-restricted-modules-common, xorg-driver-fglrx, xorg-driver-fglrx-dev
- Editing /etc/default/acpi-support to include:
SAVE_VBE_STATE=false
POST_VIDEO=false

I'm have not tried running Compiz yet, but I'm glad to have Google Earth back :)

Suspend is working fine on Gusty and Hardy, but not resume. I always end up with a black screen and some white and orange "artefact" at the top left and bottom right of the screen when the computer resume and I can't do anything, except hitting the power switch.

I just upgraded to Hardy alpha 3 (from Gusty) two days ago to see if it worked better (and test it by the way), but I end up at the same place with the same black screen every time. I tested it with kernels 2.6.24-5, 2.6.24-4 and gusty kernel (2.6.22-13 I think). I also tried every possible combinaison in acpi-support...

I have and ATI Radeon X1600 card. Direct rendering is ok and Compiz isn't activated (Something related to another bug...)

malou@Ubuntu:~$ glxinfo | grep "direct rendering"
direct rendering: Yes

malou@Ubuntu:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: Radeon X1600 Series
OpenGL version string: 2.1.7276 Release

malou@Ubuntu:~$ uname -r
2.6.24-5-generic

I attached my acpi-support file and my xorg.conf file.

Tried Today on a fresh install of Gusty (kernel 2.6.22-14-generic), and everything is working fine. I tried the same configuration on my old install and it still hang...

I'm using Catalyst 8.01 with Ubuntu 7.10 and a Mobility Radeon X1400.

Suspend/resume works when the fglrx module is loaded (previously it didn't).

Switching to an FGLRX VT, whether it's the only X session or not, locks my machine up hard. I can't even change to a text VT and shut down that way.

Any suggestions?

Does this have anything to do with it?

Jan 27 19:06:27 nick kernel: [ 4653.876000] [fglrx] PCIe has already been initialized.
 Reinitializing ...
Jan 27 19:06:27 nick kernel: [ 4653.888000] [fglrx] Reserve Block - 0 offset = 0X7ffb
000 length = 0X5000
Jan 27 19:06:27 nick kernel: [ 4653.888000] [fglrx] Reserve Block - 1 offset = 0X0 le
ngth = 0X1000000
Jan 27 19:06:27 nick kernel: [ 4653.888000] [fglrx] Reserve Block - 2 offset = 0X7fbb
000 length = 0X40000

Rocko (rockorequin) wrote :

I managed to get resume working intermittently with Ubuntu 7.10 and the 2.6.24-4 kernel, Catalyst 8.01 when I set SAVE_VBE_STATE and POST_VIDEO both false as suggested earlier.

It worked fine the first time but it failed to resume the second time.

I also tried on Hardy alpha 4 with the 2.6.24-5 kernel and Catalyst 8.01, but couldn't get resume to work. I tried

(a) the default acpi settings,

(b) both SAVE_VBE_STATE and POST_VIDEO set to false,

(c) POST_VIDEO set to true, and

(d) with the command 'vbetool post' in /etc/acpi/sleep.sh immediately after the echo command that puts the system to sleep (since I found in Gutsy tribe 5 that this was the only way to get it to resume with the open-source drivers).

But in all cases in Hardy I just got a blank screen on resume, although it seemed (judging by the USB activity) that my drives were mounting etc.

By the way, it seems that compiz/fglrx doesn't work in Hardy because fglrx doesn't support AIGLX on xorg-server v1.4 - see bug 173663. (Gutsy uses xorg-server v1.3.)

Timo Aaltonen (tjaalton) wrote :

reopening for hardy.

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
cement_head (andorjkiss) wrote :

Gutsy Gibbon, Catalyst 8.1; ATI x2300; HP 6910p laptop

Seem to need to explicitly dump the "usb" and "ndiswrapper" (wireless) modules on suspend and hibernate to get it to work (S & H) consistently.

Everything else seems to work ok - other than the compiz issues.

from /etc/default/acpi-support:

# 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"

- CH

Changed in linux-restricted-modules-2.6.22:
status: New → Invalid
Ben Collins (ben-collins) wrote :

There's not much we can do here. We aren't reverting SLUB, and we can't fix the fglrx driver.

Changed in linux-restricted-modules-2.6.24:
status: Confirmed → Won't Fix
sagyvolkov (sagyvolkov) wrote :

Maybe I lost track here, but do you mean, the Ubuntu community will never
fix this bug or just in older versions?

On Mon, Feb 25, 2008 at 9:37 AM, Ben Collins <email address hidden> wrote:

> There's not much we can do here. We aren't reverting SLUB, and we can't
> fix the fglrx driver.
>
> ** Changed in: linux-restricted-modules-2.6.24 (Ubuntu)
> Status: Confirmed => Won't Fix
>
> --
> [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.
>

stevieh (stevieh) wrote :

On Mon, Feb 25, 2008 at 9:37 AM, Ben Collins <email address hidden> wrote:

> There's not much we can do here. We aren't reverting SLUB, and we can't
> fix the fglrx driver.

Congratulations. But at last for my records: could you give us a pointer for the decision not to revert SLUB?

Regards
 Steve

Jan Rüegg (rggjan) wrote :

Well, I have to say, that THIS was the reason that I left Ubuntu after being with it since Hoary Hedgehog.

I switched to Gentoo because a Laptop without suspend is useless in everyday use at university...

Wolfgang Glas (wglas) wrote :

Well, this is a major problem and you *can* do something in order help the large number of users out there.
Here are some suggestions:

1) Provide a seperate SLUB kernel package in gutsy-updates and ive the users the chance to use this kernel instead of the default kernel.
2) Provide a newer version of the fglrx-driver (a recent catalyst release, e.g.) in gusty-backports with an option for user to choose this newer version or the older one bundled with gutsy.

Ignoring this issue will seriously deteriorate the reputation of ubuntu as the distribution of choice for humans ;-)

TIA very much for taking the long list of subscribers as a motivation for helping users rather than ignoring their problems.

  Wolfgang

Changed in linux-restricted-modules-2.6.22:
status: Won't Fix → Confirmed

I think Wolfgang's 2nd suggestion is reasonable, or maybe a 3rd option.

3) include a working version of fglrx in hardy.

Ben Collins (ben-collins) wrote :

Here's my responses to each suggestion:

1) Providing a SLAB kernel flavour means we also have to provide lum, lbm and lrm for this kernel, and keep security updates for it. Way too much overhead.

2) Updated fglrx for gutsy-backports does not pass SRU policies, plus it is impossible to just include an updated lum in gutsy backports because of ABI skew between gutsy-security. Not to mention, we are less than 2 months away from hardy release. Users can easily upgrade to hardy now or later

3) (Brad's suggestion): We've already included the latest fglrx in hardy (perhaps a new one has become available recently, in which case we will get to including that one before release).

I cannot explain in enough detail here why it is not easy to supply a "fixed kernel for gutsy" or "backports fglrx" for gutsy. It is very complex, and very time consuming. We are in the final stretches of hardy. The main reason for our 6-monthly release cycle is to make bugs like this less important, since a fix is "just around the corner". If this affected an LTS release, we would be more prone to fixing the issue.

Thanks for the understanding. I would be very interested in whether this affected current hardy kernel. It would be much more appropriate to continue reporting and commenting on this bug with ATI directly, as they are the ones that can fix it. Using SLUB, which allows for better performance across all systems, is an option we chose because it is a huge benefit. Just because a proprietary driver is broken in this condition is not a reason for us to revert it, penalizing all users. Instead, the driver needs to be fixed.

westbywest (westbywest) wrote :

I agree with Ben's points about the Ubuntu team's apprehension with branching their kernel more than already done, especially if the user base affected by further diluting developer resources is larger than the user base affected by the buggy fglrx package.

I was also affected by many of the fglrx bugs mentioned in this thread, and I ultimately chose to revert back to the open source ATI driver in package xserver-xorg-video-ati. A kernel package with SLAB support would be of no use to me, since I must already recompile the stock Ubuntu kernel with the suspend2/tuxonice patch just to get suspend/resume to work. The issues with fglrx certainly helped break the suspend function on my laptop, but it wasn't the only cause.

cement_head (andorjkiss) wrote :

I must also agree with Ben's comment & explanation. I use Gutsy on a laptop with the 8.2 Catalyst drivers manually installed and suspend and hiberanate with no problems at all.

I've checked the Hardy repos and if I'm correct they've included 8.2 Catalyst drivers - so problem solved.

Manually installing drivers is not as friendly as could be, but then again makes life interesting.

- CH

Bismark (bismark-foofus) wrote :

> Ben Collins: <snip> I would be very interested in whether this affected current hardy kernel.

I can confirm that it is affect the current Hardy x86_64 build I'm running. I have switched to uswsusp to get suspend\hibernate working. It isn't "pretty" but it's functional.

sagyvolkov (sagyvolkov) wrote :

so Hardy Alpha5 does *not* support compiz+suspend?

On Mon, Feb 25, 2008 at 5:19 PM, Bismark <email address hidden> wrote:

> > Ben Collins: <snip> I would be very interested in whether this
> affected current hardy kernel.
>
> I can confirm that it is affect the current Hardy x86_64 build I'm
> running. I have switched to uswsusp to get suspend\hibernate working.
> It isn't "pretty" but it's functional.
>
> --
> [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.
>

Yan Li (yanli) wrote :

Why "Won't Fix" for 2.6.24? It's already fixed.

I've installed Hardy's 2.6.24 kernel and fglrx on my Gutsy system running on a IBM ThinkPad T43p with ATI Mobility FireGL V3200, the suspend and hibernation work very well.

The only problem I see with Hardy's kernel and fglrx driver is it flickers during fade-in before activating screensaver. Though ugly, it doesn't affect usability.

Aaron Sarna (shoofy) wrote :

I also installed the Hardy kernel on Gutsy, but on a Dell E1505 with an ATI Mobility Radeon X1400 and I still can't suspend or hibernate successfully with fglrx 8.02.

As an added bonus, it seems that if I close the laptop lid with gnome-screensaver running and fglrx installed, the Xserver crashes and the screen doesn't turn back on, so I have to do a hard reboot. Without fglrx (or with version 7.11 or earlier) this doesn't happen.

Given that, I'd say calling this "fixed" is a little generous.

Yan Li (yanli) wrote :

Shoofy, I understand your situation. Suspend/hibernation is a very complex function and highly hardware-related. On my own machine I have to do some hacks to make it work flawless.

What I meant is that the problem mentioned in _this_ bug report is fixed. The problem here is that "suspend breaks on all machine running Ubuntu due to kernel/driver incompatibility." So as to my understanding, if the work on kernel side is done, with latest ATI driver shipped, that makes the suspend/hibernation on some users' machine possible, we can close this bug.

And I'm sure there's many other people's computer still can't suspend/hibernation with the latest kernel, then I think the best way to solve their problems is to *fill bugs for each special hardware* so they can talk with people with similar hardware and the problem would be handled in a more efficient and reproducible way. Like "suspend doesn't work on IBM ThinkPad X60" or "suspend doesn't work on Dell E1505."

HTH.

Aaron Sarna (shoofy) wrote :

That would require that bugs like "suspend doesn't work on Dell E1505" stop getting marked as duplicates of his one, which currently they consistently are.

This is not a poke at Ubuntu since I use it on my work laptop and love
it, but why can Microsoft support Suspend/Resume on any computer made
but Linux Ubuntu cannot?

Reading these posts does not give me much hope that my Lenovo R60 with
Radeon X1400 will properly suspend/resume with Compiz under Hardy.

- Clayton Dillard

On Tue, 2008-02-26 at 09:03 +0000, Yan Li wrote:

> Shoofy, I understand your situation. Suspend/hibernation is a very
> complex function and highly hardware-related. On my own machine I have
> to do some hacks to make it work flawless.
>
> What I meant is that the problem mentioned in _this_ bug report is
> fixed. The problem here is that "suspend breaks on all machine running
> Ubuntu due to kernel/driver incompatibility." So as to my understanding,
> if the work on kernel side is done, with latest ATI driver shipped, that
> makes the suspend/hibernation on some users' machine possible, we can
> close this bug.
>
> And I'm sure there's many other people's computer still can't
> suspend/hibernation with the latest kernel, then I think the best way to
> solve their problems is to *fill bugs for each special hardware* so they
> can talk with people with similar hardware and the problem would be
> handled in a more efficient and reproducible way. Like "suspend doesn't
> work on IBM ThinkPad X60" or "suspend doesn't work on Dell E1505."
>
> HTH.
>

Clayton Taylor Dillard

http://hspcd.blogspot.com/

Dara Adib (daradib) wrote :

Clayton Dillard: Drivers, drivers, drivers . . .

Most devices are designed for Microsoft Windows. Additionally, drivers are provided by the hardware manufacturers for these functions to work.

Dara Adib (daradib) wrote :

Clayton Dillard: you may also want to check Bug 50031, Bug 92461, and Bug 68199 (which is currently marked as a duplicate of Bug 63418) regarding the suspend/resume support on your Lenevo X1400, in case the problem is not (or at least not just) the Radeon card.

William Cattey (wdc-mit) wrote :

No ATI Catalyst 8 driver exists yet for the ATI Mobility FireGL V5200.
The ati-driver-installer-8.443.1 run file creates an fglrx driver that does NOT work with the SLUB kernel.
So on the IBM /Lenovo Thinkpad T61, suspend/resume wont work with the 2.6.23 kernel.

I don't know if it's intentional, but when I upgraded from 7.04 to 7.10, a 2.6.20 kernel was left in place.
Booting that kernel gives me a working suspend/resume, but the Mesa GL layer. (Probably because I didn't run the run file to create a kernel driver for the other kernel.)

Two questions:

1. Can someone point me to the procedure to disable this driver and revert to the free driver?
I thought I knew how to do it, but I kept coming up in 800x600, and I KNOW the free driver works better than that.

2. Can someone point me to where on the ATI web site I can vote, "PLEASE Hurry up and release Catalyst 8 for the FireGL V5200"?

Or is there someone who has gotten this hardware to suspend / resume without rebuilding the kernel?

Dara Adib (daradib) wrote :

Clarification to my previous comment: Bug 92461 is about fglrx as well. That is why it appears to be very much related.

Chad Johnson (chad-d-johnson) wrote :

I may have the same issue with my Acer Aspire 5050. Does this sound like the same problem?

Whenever I suspend and then resume, more than half of the time, the CPU is at 100%, but top/htop output does not show me what is using the CPU that much. If I kill X (ctrl+alt+backspace), the CPU jumps back down below 100%.

Some threads I started on Ubuntu forums but so far have come across no working solution:

http://ubuntuforums.org/showthread.php?p=4405588
http://ubuntuforums.org/showthread.php?t=686172

Jaime (jaime-lopez) wrote :

Please check with top if iowait is at 100% (or at 50% if you have dual core)
I have the same problem, and might have nothing to do with fglrx but with
this bug related to a broken kswapd in 2.6.21

http://groups.google.com/group/linux.kernel/browse_thread/thread/910c08e97eb0357e

Whenever I suspend and then resume, more than half of the time, the CPU
> is at 100%, but top/htop output does not show me what is using the CPU
> that much. If I kill X (ctrl+alt+backspace), the CPU jumps back down
> below 100%.
>
> Some threads I started on Ubuntu forums but so far have come across no
> working solution:
>
> http://ubuntuforums.org/showthread.php?p=4405588
> http://ubuntuforums.org/showthread.php?t=686172
>
> --
> [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.
******************************************

André Carezia (carezia) wrote :

Em Tue, 26 Feb 2008 14:14:46 -0000
Clayton Dillard <email address hidden> escreveu:

> This is not a poke at Ubuntu since I use it on my work laptop and love
> it, but why can Microsoft support Suspend/Resume on any computer made
> but Linux Ubuntu cannot?

This is not true. Some of my clients have Dell Latitude D610
notebooks. Windows XP does *not* handle suspend to RAM on these
notebooks. Official response from Dell: use suspend to disk.

--
André Carezia
Eng. de Telecomunicações
Carezia Consultoria - www.carezia.srv.br

Rafal Kwasny (mag) wrote :

Current status on my R61p

I've installed hardy yesterday - done a clean install

Suspend is working perfectly - with of without enabled compiz
Hibernation - system hibernates correctly, but Xorg doesn't work after resume
my card is:
01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200]

Chad Johnson (chad-d-johnson) wrote :

Jaime,

I have one single-core processor (Turion 64), and after resume, iowait is above 50% (anywhere between 60% - 90%).

Are we experiencing the same issue? Is yours *always* at 100%?

Thanks for the lead. I'll try to post back if I get any results.

Jaime (jaime-lopez) wrote :

After resuming, mine is always at, at least 50%. That is, one of the cores
is at 100% itself and the other is at the usual values (nonzero). The
average is the value shown by top, >=50%

I think we have exactly the same issue. In my case it is always repeatable.

Regards,

On Thu, Feb 28, 2008 at 3:19 PM, Chad Johnson <email address hidden>
wrote:

> Jaime,
>
> I have one single-core processor (Turion 64), and after resume, iowait
> is above 50% (anywhere between 60% - 90%).
>
> Are we experiencing the same issue? Is yours *always* at 100%?
>
> Thanks for the lead. I'll try to post back if I get any results.
>
> ** Attachment added: "iowait"
>
> http://launchpadlibrarian.net/12275121/Screenshot-chad%40atlas%3A%20%7E.png
>
> --
> [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.
******************************************

Chad Johnson (chad-d-johnson) wrote :

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?

Jaime (jaime-lopez) wrote :

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.

Regards,

Jaime

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

> 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 :

Jaime,

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.

Regards,

Jaime

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.

@Henry
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

and

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...

Details:
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 2.6.24.11-12.31 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.

@infodroid:
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 ?

PS
in
/usr/lib/pm-utils/defaults
I also had to set
SUSPEND_MODULES="ath_pci"

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
> SUSPEND_MODULES="ath_pci"
>
> 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?

Thanks.

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

try...

# 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.
DOUBLE_CONSOLE_SWITCH=true

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

  POST_VIDEO=false
  SAVE_VBE_STATE=false

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

  USE_DPMS=false

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
  popd

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.

http://ppa.launchpad.net/tjaalton/ubuntu

Chad Johnson (chad-d-johnson) wrote :

@stel

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.

  http://bugs.launchpad.net/ubuntu/+source/fglrx-installer

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
activity,
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
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.