Ubuntu

[Dell Studio 17] Everything gets swapped out after resume from suspend using fglrx drivers

Reported by Luke Plant on 2009-06-24
246
This bug affects 47 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

Bug Description

After resuming from suspend, hard disk activity goes crazy, and the machine is very unresponsive. Looking at what is happening in htop, it seems that the system is moving many pages to swap -- I can see swap usage increasing several Mb/second, and resident memory usage decreasing similarly.

I have 3 Gb physical memory, 9 Gb swap, and in my normal usage, 'free' often reports zero usage of swap - everything fits comfortably in RAM. So I cannot see any reason why the system would need to do this. From a look at syslog, it seems this time the system was using about 600 Mb of swap immediately after resume. It then moved about 1 Gb out of RAM to swap for no apparent reason. Final stats (once the disk stopped churning) from 'free' are in 'free_output.txt', and the output of 'ps -eF' is in 'ps_eF_output.txt'. A look at the virtual/resident figures in the latter shows that many processes have been almost entirely swapped out.

This has happened several times, though not every time I suspend/resume. I don't think it happens the first time I suspend/resume after rebooting. Previously I just gave up and rebooted, since the system did not show any sign of becoming usable. This time it has actually become usable after about 15 minutes (which is obviously unacceptable - I consider suspend/resume to be broken on this machine).

My machine is a Dell Studio 17 laptop. This started occurring when I switched from the open source video driver to fglrx, previously I never experienced it. I'm also using a patched xserver, as provided by Bryce Harrington from https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill due to bug #351186 (since I'm affected by that bug). I don't know if it happens without that xserver, I suspect it is unrelated.

/var/logs/syslog is in syslog.txt. The resume occurred at Jun 24 09:32:57

There is a crash of some kind in that log.

After a bit more usage of my machine, I'm finding that physical memory usage has returned to nearly 100%, but swap usage hasn't gone down. I have no idea what is going on here.

WORKAROUND: Do not use the fglrx drivers.

Luke Plant (spookylukey) wrote :
Luke Plant (spookylukey) wrote :

This is still happening very regularly (about 50% of the time I resume from suspend).

I've found that if I disable swap, something similar happens — very unresponsive system, massive disk activity, very high CPU activity (without it being attributed to any one process - according to top it's spending 95% of the time waiting for IO, but no processes are using much of the CPU). Without swap however, it takes 'forever' to recover - I waited an hour and then gave up.

I've found that the only thing which seems to help restore responsiveness is killing X with Ctrl-Alt-Backspace.

Some other possibly related info: I was recently on holiday using the laptop often without the power cable plugged in, which gives me different power settings, and I found for the week, this problem very rarely occurred. It might have been fluke, or it might have been related to the different power settings.

Download full text (3.6 KiB)

I think I have the same problem. My system seems to swap everything in after resume from S3 sleep.

Even though this is marked as a duplicate, I think this is possibly unrelated. I am using the fglrx module. This is on Jaunty, with an Asus F6V.

I see this in the dmesg on the machine:

[1052262.236206] ACPI handle has no context!
[1052262.252119] [fglrx] Power down the ASIC .
[1052263.399713] pm-suspend: page allocation failure. order:10, mode:0x4020
[1052263.399717] Pid: 24948, comm: pm-suspend Tainted: P 2.6.28-15-generic #49-Ubuntu
[1052263.399718] Call Trace:
[1052263.399729] [<ffffffff802b6e1e>] __alloc_pages_internal+0x3ee/0x500
[1052263.399731] [<ffffffff802b6fae>] __get_free_pages+0x1e/0x60
[1052263.399735] [<ffffffff802e3587>] __kmalloc+0x107/0x110
[1052263.399857] [<ffffffffa003ed9e>] KCL_MEM_SmallBufferAllocAtomic+0xe/0x10 [fglrx]
[1052263.399893] [<ffffffffa0052639>] firegl_save_fb+0x49/0x180 [fglrx]
[1052263.399931] [<ffffffffa0054241>] ? firegl_cail_powerdown+0x91/0x110 [fglrx]
[1052263.399964] [<ffffffffa0041751>] ? fglrx_pci_suspend+0x81/0x140 [fglrx]
[1052263.399971] [<ffffffff804313c0>] ? pci_legacy_suspend+0x30/0x80
[1052263.399973] [<ffffffff80431605>] ? pci_pm_suspend+0x95/0xd0
[1052263.399977] [<ffffffff804be422>] ? pm_op+0x162/0x1b0
[1052263.399980] [<ffffffff804bead3>] ? suspend_device+0xf3/0x180
[1052263.399982] [<ffffffff804bec28>] ? dpm_suspend+0xc8/0x140
[1052263.399984] [<ffffffff804becc2>] ? device_suspend+0x22/0x30
[1052263.399988] [<ffffffff80280395>] ? suspend_devices_and_enter+0x55/0x180
[1052263.399990] [<ffffffff802806d9>] ? enter_state+0xe9/0x120
[1052263.399993] [<ffffffff802807ca>] ? state_store+0xba/0x100
[1052263.400011] [<ffffffff80419207>] ? kobj_attr_store+0x17/0x20
[1052263.400014] [<ffffffff80347b65>] ? sysfs_write_file+0xc5/0x140
[1052263.400017] [<ffffffff802e821b>] ? vfs_write+0xcb/0x130
[1052263.400019] [<ffffffff802e8370>] ? sys_write+0x50/0x90
[1052263.400022] [<ffffffff8021253a>] ? system_call_fastpath+0x16/0x1b
[1052263.400023] Mem-Info:
[1052263.400025] DMA per-cpu:
[1052263.400027] CPU 0: hi: 0, btch: 1 usd: 0
[1052263.400028] CPU 1: hi: 0, btch: 1 usd: 0
[1052263.400029] DMA32 per-cpu:
[1052263.400030] CPU 0: hi: 186, btch: 31 usd: 104
[1052263.400032] CPU 1: hi: 186, btch: 31 usd: 81
[1052263.400034] Active_anon:275413 active_file:53666 inactive_anon:83167
[1052263.400035] inactive_file:217385 unevictable:2 dirty:0 writeback:0 unstable:0
[1052263.400036] free:27064 slab:77634 mapped:20832 pagetables:6845 bounce:0
[1052263.400038] DMA free:6644kB min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_
[1052263.400040] lowmem_reserve[]: 0 3013 3013 3013
[1052263.400044] DMA32 free:101612kB min:7016kB low:8768kB high:10524kB active_anon:1101652kB inactive
[1052263.400046] lowmem_reserve[]: 0 0 0 0
[1052263.400048] DMA: 1*4kB 2*8kB 4*16kB 5*32kB 4*64kB 2*128kB 3*256kB 2*512kB 0*1024kB 0*2048kB 1*409
[1052263.400053] DMA32: 20894*4kB 758*8kB 437*16kB 61*32kB 21*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 0*
[1052263.400058] 423428 total pagecache pages
[1052263.400060] 148114 pages in swap cache
[1052263.400061] Swap c...

Read more...

Yes, the swapping goes away completely after converting to the open source driver.

Unfortunately the open source driver leaves artifacts in tons of places (the mouse, the Firefox buttons, and so on). Hopefully either the closed source driver will avoid the swapping in Karma, or the open source driver will fix the artifacts!

I wasn't able to get the Karmic CD to boot on the laptop. :(

But, I was able to install the closed source drivers from Karmic, from these two packages:

http://packages.ubuntu.com/karmic/xorg-driver-fglrx
http://packages.ubuntu.com/karmic/fglrx-kernel-source

It looks like the problem has been fixed:

[ 185.049261] fglrx_pci 0000:01:00.0: setting latency timer to 64
[ 185.056112] [fglrx] Preparing resume fglrx in kernel.
[ 185.239527] [fglrx] Resuming fglrx in kernel completed.
[ 185.239531] [fglrx] Power up the ASIC

No more swapping after resume! Life is good.

Luke Plant (spookylukey) wrote :

Thanks Shane - that fixed it for me too. This makes life a lot better for me :)

Luke Plant (spookylukey) wrote :

Cancel that, it's still occurring, though perhaps less regularly, and perhaps only when I leave it suspended over night. I'll do more tests.

Yes, I also noticed this today. I saw the scary fgrlx error message again in the dmesg log. It *does* seem slightly better somehow, but is definitely not fixed.

Okay, I found a solution that seems to work for me. (I will report back here if it fails, but so far so good.)

An updated version of the open source drivers for the card in my laptop works pretty good. There are no weird artifacts, the fan turns off when it is not cooling, and, well, it seems to Just Work. (I am only looking at 2D stuff, I installed Extreme Tux Racer to see how the 3D is and got something like 4 frames per second - it's basically a slideshow.)

I used the instructions here:

http://wiki.cchtml.com/index.php/Ubuntu_Jaunty_Installation_Guide#Installing_Open_Source_Edge_Drivers

Using the PPA for Tormod Volden did seem to install a bunch of other gorp. I don't know if this is good or bad, so it may be worth it to try to install only the xserver-xorg-video-radeonhd package. I noticed that the package for Karmic is actually one version later, so maybe the best thing is to try that:

http://packages.ubuntu.com/karmic/xserver-xorg-video-radeonhd

Luke Plant (spookylukey) wrote :

Some more info to diagnose this:

I think it is basically some kind of memory leak. With the fglrx drivers, my system uses up more and more RAM. On this 3 Gb machine, by the end of a 1 or 2 days, I have no free RAM left, and the X server process can often be using well over 1 Gb RAM.

Sometimes the reported behaviour (swapping everything out to disk) can occur even without suspending and resuming.

Having switched back to the open source driver (mainly to get support for multiple monitors or output to projectors), I've had no such problems. I've had my computer on for 5 days, just suspending and resuming overnight, and by RAM has plateaued at something sensible given the number of applications I've got open, with over 1 Gb completely free.

So basically, at the moment with ATI cards you have the choice between:

fglrx: memory leaks, broken suspend, broken support for multiple outputs
open source driver: no OpenGL/3D acceleration.

This bug still hasn't been resolved yet. Any new info?

On 2010-01-21 14:23, ChillyWilly wrote:
> This bug still hasn't been resolved yet. Any new info?

Well, as I indicated, I am using the open source drivers and the laptop
works just fine now.

Although I haven't tried any 3D games on it of course. ;)

I don't know if the ATI drivers have fixed this bug, and since this is
my work laptop I don't really need 3D - that's my recommendation unless
you want to play games (or use Google Earth).

--
Shane

I have same bug with Karmic on my AsusF8V laptop with Radeon HD 3400. I use fglrx:

[169219.330103] [fglrx] Power down the ASIC .
[169219.330165] [fglrx] Preparing suspend fglrx in kernel.
[169219.331466] pm-suspend: page allocation failure. order:10, mode:0x4020
[169219.331470] Pid: 29237, comm: pm-suspend Tainted: P W 2.6.31-19-generic #56-Ubuntu
[169219.331472] Call Trace:
[169219.331482] [<ffffffff810e07bc>] __alloc_pages_slowpath+0x4cc/0x4e0
[169219.331486] [<ffffffff810e091e>] __alloc_pages_nodemask+0x14e/0x150
[169219.331490] [<ffffffff8110cfa2>] alloc_pages_current+0x82/0xd0
[169219.331493] [<ffffffff810df909>] __get_free_pages+0x9/0x50
[169219.331497] [<ffffffff811163d5>] __kmalloc+0x125/0x1d0
[169219.331562] [<ffffffffa0159cf8>] ? KCL_MEM_AllocAtomic+0x18/0x20 [fglrx]
[169219.331595] [<ffffffffa015a54e>] KCL_MEM_SmallBufferAllocAtomic+0xe/0x10 [fglrx]
[169219.331632] [<ffffffffa0169f49>] firegl_save_fb+0x49/0x180 [fglrx]
[169219.331670] [<ffffffffa01692f0>] ? firegl_pm_save_framebuffer+0x1f0/0x270 [fglrx]
[169219.331708] [<ffffffffa016bb93>] ? firegl_cail_powerdown+0xb3/0x1c0 [fglrx]
[169219.331737] [<ffffffffa01560f2>] ? fglrx_pci_suspend+0x82/0x140 [fglrx]
[169219.331744] [<ffffffffa0483252>] ? azx_suspend+0x112/0x130 [snd_hda_intel]
[169219.331750] [<ffffffff8128e9f5>] ? pci_legacy_suspend+0x45/0xe0
[169219.331753] [<ffffffff8128f365>] ? pci_pm_suspend+0xd5/0x130
[169219.331758] [<ffffffff8132554a>] ? pm_op+0x13a/0x180
[169219.331761] [<ffffffff81325b8a>] ? device_suspend+0xda/0x140
[169219.331764] [<ffffffff81325cb6>] ? dpm_suspend+0xc6/0x140
[169219.331768] [<ffffffff81325d52>] ? dpm_suspend_start+0x22/0x30
[169219.331772] [<ffffffff810931bc>] ? suspend_devices_and_enter+0x5c/0xe0
[169219.331776] [<ffffffff81093318>] ? enter_state+0xd8/0x110
[169219.331779] [<ffffffff810928d2>] ? state_store+0x92/0x100
[169219.331783] [<ffffffff81274807>] ? kobj_attr_store+0x17/0x20
[169219.331788] [<ffffffff81184e00>] ? sysfs_write_file+0xe0/0x160
[169219.331792] [<ffffffff8111f3d8>] ? vfs_write+0xb8/0x1a0
[169219.331796] [<ffffffff8152c814>] ? do_page_fault+0x194/0x370
[169219.331799] [<ffffffff8111fe8c>] ? sys_write+0x4c/0x80
[169219.331804] [<ffffffff81012002>] ? system_call_fastpath+0x16/0x1b

Aldoo (aldo-public) wrote :

Still happening in Karmic with AMD Catalyst 10.1, Radeon HD mobility 4570.

Marius (mm473) wrote :

The fglrx from the Karmic repositories (8.66, which is secretly somewhere between Catalyst 9.08 and 9.12 I think) along with 2.6.31-14 (not sure if kernel really matters...) works well for me. As a workaround you guys might consider downgrading. Its very stable, whereas the newest ~3 versions kind of suck.

Marius (mm473) wrote :

I should add that without 8.66 I have the bug mentioned here.

Roland Schulz (roland-rschulz) wrote :

For me 8.66 has the same problem.

I'd suggest to leave a comment on the Dell website about this problem. I did and they contacted me about this. So they seem to care. Hopefully if enough people write they make AMD fix their ATI driver.

Just go to your product page. E.g. http://www.dell.com/pd.aspx?refid=laptop-studio-1555 and click "Sign In To Write A Review". Write you review including mentioning this problem.

Aldoo (aldo-public) wrote :

Still happening in Lucid, Catalyst 10.04.

Dell, why not...
But isn't Canonical even more concerened? For all I know they are working quite closely with AMD guys (Ubuntu Lucid was the only disto to have preversions of the Xorg 1.7 compatible Catalyst 10.04 during the beta stage, AFAIK).

Vadym Krevs (vkrevs) wrote :

Same problem with Dell Studio 1747, ATI HD 3650 and openSUSE 11.2 for x86_64.
https://bugzilla.novell.com/show_bug.cgi?id=597613

Josh Hill (ingenium) wrote :

I can confirm it still happens in Lucid with Catalyst 10.4. Running on a Thinkpad T400, ATI Mobility Radeon HD 3400.

This bug seems to be fixed for me.

I am *not* seeing this problem in Lucid, using whatever fglrx drivers are installed via the "Hardware Drivers" thingy. As before, this is on an Asus F6V with an ATI Mobility Radeon HD 3400.

It may be something that happens after something triggers this bug. If I see the behavior then I'll post here.

I was premature in declaring this fixed. After a few days, the massive swap behavior after resume has started again. I don't see anything in "dmesg" that is obviously triggering this. I guess I'll try going back to the open source drivers (although whatever Lucid was using by default was painfully slow).... :(

I've gone back to open source drivers.

Note that the radeonhd drivers worked *very* poorly with Lucid. This turns out to be a problem mostly because I installed them manually previously. I removed them, rebooted, and now everything looks pretty and updates quickly.

I know Canonical can't control closed source drivers, but at least their hardware drivers thingy could have some sort of black list of known back mixes, right?

Anton (feenstra) wrote :

I'm having this, or something very similar, on my HP 6930p laptop, with a Radeon Mobility HD 3400 running Lucid AMD 64 (2.6.32-22-generic x86_64) and fglrx 2:8.723.1-0ubuntu4 (according to dpkg -l). I just downgraded to 2:8.723.1-0ubuntu3 to see if that changes anything (judging from the above, it shouldn't really...).

Swapping/trashing starts at resume, with the machine getting totally unusable for up to or over half an hour (if I have the patience; I usually ctrl+alt+sys-rq+b well before that), but sometimes recovers more or less spontaneously in a matter of minutes (up to five or so). When it happens, the memory is never even remotely full (usually well below 50%), but there may be a slight tendency that it happens more often or is more severe when more memory is in use.

Anything else I'd need to supply?

Terrax (tball-es) wrote :

I do also have this problem.

My system:
Ubuntu Lucid latest updates.
Linux tball-laptop 2.6.32-24-generic #38-Ubuntu SMP Mon Jul 5 09:20:59 UTC 2010 x86_64 GNU/Linux
ATI Mobility Radeon HD 4650 with fglrx 9.7.
Ram: 4Gb
CPU: Intel C2D

I have attached my dmesg, from the power-up procedure.
It mostly happens after third suspend. Never the first suspend.

same problem lucid install on a 6910p HP laptop, 64bits. 3Go Ram total 2 not used, and 1Go of swap used.
nothing special in the kernel logs.
I don't use fglrx, but open source driver radeon

affects: ubuntu → linux (Ubuntu)
Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: asusf8v dell-studio-17 jaunty karmic
tags: added: hp6930
tags: added: lucid
Fabio Marconi (fabiomarconi) wrote :

Hello to all.
Can someone reproduce the bug in Lucid then attach here these files:

/var/log/syslog
/var/log/dmesg
/var/log/kern.log
/var/log/Xorg.0.log
/var/log/Xorg.0.log.old
/var/log/udev

Thanks in advance
:)Fabio

On 15/08/10 22:42, Fabio Marconi wrote:
> Hello to all.
> Can someone reproduce the bug in Lucid then attach here these files:
>
> /var/log/syslog
> /var/log/dmesg
> /var/log/kern.log
> /var/log/Xorg.0.log
> /var/log/Xorg.0.log.old
> /var/log/udev
>
> Thanks in advance
> :)Fabio

Would files after a reboot do? Most often, when I encounter this bug,
the machine does not get back into a working condition and I have to
reboot (even hard reset sometimes).

Anton.

Hello anton.

After the bug, can you please attach these files:

/var/log/syslog
/var/log/syslog.1
/var/log/dmesg
/var/log/dmesg.0
/var/log/kern.log
/var/log/kern.log.1
/var/log/Xorg.0.log
/var/log/xorg.0.log.old
/var/log/udev

Thanks
Fabio

On 16/08/10 11:49, Fabio Marconi wrote:
> Hello anton.
>
> After the bug, can you please attach these files:
[...]

OK, will do that. Expect a day or so delay, as I have to wait for it to
reappear (and the machine is my major production environment, so I
cannot spend the time to experiment).

--
Groetjes,

Anton
  _____________ _______________________________________________________
| | |
| _ _ ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University Amsterdam |
|( | )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | <email address hidden> - www.few.vu.nl/~feenstra/ |
| | "And I Will Strike Down Upon Those With Great |
| | Vengeance and With Furious Anger Those Who Attempt to |
| | Poison and Destroy My Brothers." (Pulp Fiction) |
|_____________|_______________________________________________________|

It happened again yesterday (in the train). Attached are the logfiles you asked for. I grabbed them after reboot (since I could not get the machine in an operational state), from the console (i.e., without logging in via gdm).

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: needs-upstream-testing
removed: asusf8v dell-studio-17 hp6930
description: updated
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
57 comments hidden view all 130 comments

apport information

tags: added: apport-collected precise

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Sorry for the spam guys, I just ran apport-collect on this bug, since I still have it too. The stacktrace is roughly similar to what has been posted above.

Wong Yong Jie, please do not apport-collect to another person's report. If you are having a problem in Ubuntu, please file a new report by executing the following via the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

tags: removed: apport-collected precise

The bug is still very present. It seems that if I don't have any memory swapped out then it resumes fast. If I have memory swapped I wait for a few minutes before I get back control of my computer. Also under this heavy load the mouse either stutters or dies completely for a few minutes until the swapping is done. Is mouse stuttering normal under heavy HDD activity?

Sebastian Bugiu, if you are having a problem in Ubuntu, please file a new report by executing the following via the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

Could you please clarify the bug policy for me? If his bug is going to be
marked as a dupe, why should he file a new bug?

On Saturday, June 9, 2012, Christopher M. Penalver wrote:

> Sebastian Bugiu, if you are having a problem in Ubuntu, please file a new
> report by executing the following via the Terminal and feel free to
> subscribe me to it:
> ubuntu-bug linux
>
> Thanks!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/391628
>
> Title:
> Everything gets swapped out after resume from suspend using fglrx
> drivers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/+subscriptions
>

Hello,

This is still (since 10.10 as far as I remember) reproduced with my laptop HP Compaq 6730s (Radeon HD3430, 4Gb RAM, Ubuntu 11.10 x64) and the latest 12.6 driver.

Adding script
if [ "$1" == "suspend" ] || [ "$1" == "resume" ]; then
 swapoff -a
 swapon -a
fi

which disabled and then enabled swap on each suspend/resume to /etc/pm/sleep.d/ also has not helped.

It looks like swap usage system policy does not affect this issue.
(sysctl -w vm.swappiness = 0)

After some of resumes about 1.5GB can be swapped out when there is 2GB free system memory.

Thus the only solution for me I can see is to disable swap at all and track memory state as I really need "suspend" feature.

One point is still unclear for me: isn't swap usage completely under the kernel control?

Thanks

gumkins (txtinzip) wrote :

>> isn't swap usage completely under the kernel control?
Anyway, if everything is running under the system doesn't it have possibility to restrict swap usage by some third party drivers/software? Is it impossible even by kernel rebuilding with some special options?

Cheers

gumkins (txtinzip) wrote :

>> ... by some third party ...
sorry, I meant FOR some...

http://askubuntu.com/questions/211733/swap-swapiness-and-standby-swapping-starts-when-waking-up

Does happen with a current Ubuntu, Radeon Mobility HD 3650 and a current ATI fglrx, downloaded by AMD directly: Catalyst 12.6 7/24/2012

[ 12.218] (II) Loading /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/drivers/fglrx_drv.so
[ 12.265] (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
[ 12.266] compiled for 1.4.99.906, module version = 8.97.2
[ 12.266] Module class: X.Org Video Driver
[ 12.266] (II) Loading sub module "fglrxdrm"
[ 12.266] (II) LoadModule: "fglrxdrm"
[ 12.266] (II) Loading /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/linux/libfglrxdrm.so
[ 12.266] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[ 12.266] compiled for 1.4.99.906, module version = 8.97.2
[ 12.266] (II) ATI Proprietary Linux Driver Version Identifier:8.97.2
[ 12.266] (II) ATI Proprietary Linux Driver Release Identifier: 8.97.100.3
[ 12.266] (II) ATI Proprietary Linux Driver Build Date: Jul 3 2012 23:56:30

This bug appears to affect my system. Sony VAIO 64 Bit Running Xubuntu 12.04, Radeon Driver with FGLRX drivers installed. Suspend and resume worked flawlessly for several months. The bug has now rendered Suspend/ Resume useless.

Patrick Gillespie, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Lukas W. (lukasw) wrote :

Christopher, as Adam Porter already stated earlier, there is no point in filing a new bug.
Patrick is affected by this very bug, so why should he file a new one? It's only going to be marked as a duplicate.

Hi Christopher, I registered the bug as you requested.

It is listed as Bug #1129411

Since I lack the necessary diagnostic skills to gather more information without assistance, I've directed readers of my new bug report to *this* bug. I also gave it the same name. I hope this prevents any delays in solving this bug. I'd love to see it fixed.

On Mon, Feb 18, 2013 at 8:30 AM, Christopher M. Penalver
<email address hidden> wrote:
> Patrick Gillespie, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
> ubuntu-bug linux
>
> Please note, not filing a new report may delay your problem being
> addressed as quickly as possible.

Would you please explain how having each affected user file a
separate, duplicate bug report will result in more efficient handling
of bug reports?

I contacted AMD's tech support a few months ago and supplied them with detailed information. Meanwhile I was able to circumvent my personal problem by upgrading my machine from 4 GB to 8 GB. A couple of weeks ago I re-contacted AMD and was adviced that their Linux team was working on this issue but due to my product (Radeon HD 3000 Series) being a legacy one this issue was not on their priority list.

This is the URL to directly open bug reports with AMD:
http://emailcustomercare.amd.com/

Thanks for the update. It's too bad that a major issue like this is
not a priority. But I guess people using "old" hardware doesn't make
them more money.

On Sat, Mar 9, 2013 at 2:48 AM, mdo <email address hidden> wrote:
> I contacted AMD's tech support a few months ago and supplied them with
> detailed information. Meanwhile I was able to circumvent my personal
> problem by upgrading my machine from 4 GB to 8 GB. A couple of weeks ago
> I re-contacted AMD and was adviced that their Linux team was working on
> this issue but due to my product (Radeon HD 3000 Series) being a legacy
> one this issue was not on their priority list.
>
> This is the URL to directly open bug reports with AMD:
> http://emailcustomercare.amd.com/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/391628
>
> Title:
> Everything gets swapped out after resume from suspend using fglrx
> drivers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/+subscriptions

mdo, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Adam Porter, it is not helping that you continue to post here, despite you already being requested to file a new report over a year ago in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/comments/83 . If you want your issue addressed, please perform the actions previously requested.

tags: added: needs-kernel-logs

Christopher,

As I have said earlier, I still have this bug when using fglrx, and
that has forced me to use the open-source driver. You're asking me to
change drivers, reenact the bug, and then file a new bug report, which
will then be marked as a duplicate or Incomplete. In the meantime,
Wong Yong Jie posted a valid addition to this bug report with
appropriate kernel debug info and traces, but you deleted it and all
of his attachments. You also removed Luke Plant's report and
attachments and told him to re-report the bug. And after deleting
these logs, you marked this bug as "needs-kernel-logs", and you marked
it "Incomplete" in spite of it clearly being confirmed by multiple
users.

You never answered Luke when he said:

> I've just uninstalled the fglrx drivers since this is a critical issue for me. However, if you can assure me that you are actually intending to do something about this, rather than just find a reason to cross this bug off your list, then I will install it again and follow the steps you posted.

I feel the same way. I do not want to go to all that trouble just to
have my bug report marked Incomplete or Duplicate again. That's
happened to me too many times on other Ubuntu bug reports. I feel
like you are asking us to jump through too many hoops when we have
already done that. Debian doesn't treat bug reporters this way, with
such bureaucracy.

Adam, you made your point. Just file a separate bug report (like I did) so the ball can finally be in their court.

You're not helping the rest of us (who also have this problem) by stubbornly standing on principle, regardless of whether you're right.

I mean, after all, you're just dealing with people trying to do what they enjoy (and maybe make a living?). We're not dealing with Microsoft here, right?

You made your point. Take a deep breath. File a new bug report.

Luke Plant (spookylukey) wrote :

In addition to what Adam Porter said, quoting me, I want to point out that I am not demanding or expecting anyone to fix this bug. I'm a core developer of a significant open source project myself (Django), and fully understand that contributors are often volunteers, or there are just more important things, and I know that I am not a paying customer and cannot make demands on people's time.

However, it seems like Ubuntu's bug closing procedures are designed to cross bugs off your list at the expense of *my* time, by asking me to perform the same steps over and over, simply to confirm that yes, this is *still* an issue, when all that work isn't actually going to do any good. This is not a good way to treat people who have gone to the bother of filing detailed bug reports. If you don't have the resources to deal with a bug, why not just leave it as open? Closing the bug only serves to make someone's stats look better.

Best regards.

Adam Porter, thank you for your comments. Regarding them https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/comments/123 :
>"Christopher, As I have said earlier, I still have this bug when using fglrx, and that has forced me to use the open-source driver. You're asking me to change drivers, reenact the bug, and then file a new bug report, which will then be marked as a duplicate or Incomplete."

Firstly, in my initial post to you https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/comments/83 requesting for you to file a new report, I did not post the rationale for this, so I beg your pardon. As well, I would not mark this a duplicate unless a developer notes this is so, or it is clear from a development perspective. Since you did not file a new report, this is undeterminable.

>"In the meantime, Wong Yong Jie posted a valid addition to this bug report with appropriate kernel debug info and traces, but you deleted it and all of his attachments. You also removed Luke Plant's report and attachments and told him to re-report the bug. And after deleting these logs, you marked this bug as "needs-kernel-logs", and you marked it "Incomplete" in spite of it clearly being confirmed by multiple users."

This would be correlation, not causation.

>"You never answered Luke when he said: > I've just uninstalled the fglrx drivers since this is a critical issue for me. However, if you can assure me that you are actually intending to do something about this, rather than just find a reason to cross this bug off your list, then I will install it again and follow the steps you posted. I feel the same way."

I'm more than happy, and eagerly await the opportunity to triage both of your reports, in line with the policies set out by the Ubuntu Kernel Team, Ubuntu Bug Control, and Ubuntu Bug Squad.

>"I do not want to go to all that trouble just to have my bug report marked Incomplete or Duplicate again. That's happened to me too many times on other Ubuntu bug reports."

The last thing I would want is to have you do a considerable amount of work, to find that this is in fact a duplicate.

>"I feel like you are asking us to jump through too many hoops when we have already done that. Debian doesn't treat bug reporters this way, with such bureaucracy."

The last thing I would want is to create and sustain a bureaucracy. If this is what Ubuntu was about, I certainly would not have installed Ubuntu, let alone triage the bug reports regarding it.

If you have further questions, please do not post further to this report, but contact me directly, post to the appropriate forum, and file a new report.

Thank you for your understanding.

Download full text (4.1 KiB)

On Wed, May 29, 2013 at 9:24 PM, Christopher M. Penalver
<email address hidden> wrote:

Chris,

I appreciate your polite response, but I am still disappointed.

> Firstly, in my initial post to you
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/391628/comments/83
> requesting for you to file a new report, I did not post the rationale
> for this, so I beg your pardon. As well, I would not mark this a
> duplicate unless a developer notes this is so, or it is clear from a
> development perspective. Since you did not file a new report, this is
> undeterminable.

This bug is a specific, very unusual behavior, experienced only by
users using a specific driver, taking a specific action. It's clearly
the same bug. There's no reason to think otherwise. You seem to be
advocating a "presumed different until proven duplicate" policy, which
doesn't make sense, if for no other reason than the excessive bug
reports and associated triage workload it would generate.

>>"In the meantime, Wong Yong Jie posted a valid addition to this bug
> report with appropriate kernel debug info and traces, but you deleted it
> and all of his attachments. You also removed Luke Plant's report and
> attachments and told him to re-report the bug. And after deleting these
> logs, you marked this bug as "needs-kernel-logs", and you marked it
> "Incomplete" in spite of it clearly being confirmed by multiple users."
>
> This would be correlation, not causation.

But let's look at the end result: logs were deleted and then
requested, and the bug was confirmed by multiple users and then marked
Incomplete. This makes no sense.

> The last thing I would want is to have you do a considerable amount of
> work, to find that this is in fact a duplicate.

Then why are you asking me to do so when it is clearly the same bug?

>>"I feel like you are asking us to jump through too many hoops when we
> have already done that. Debian doesn't treat bug reporters this way,
> with such bureaucracy."
>
> The last thing I would want is to create and sustain a bureaucracy. If
> this is what Ubuntu was about, I certainly would not have installed
> Ubuntu, let alone triage the bug reports regarding it.

I believe you are sincere, but look at what you just said:

> I'm more than happy, and eagerly await the opportunity to triage both of
> your reports, in line with the policies set out by the Ubuntu Kernel
> Team, Ubuntu Bug Control, and Ubuntu Bug Squad.

If that's not bureaucracy, what is? You sound so polite, but you
sound like someone at a government agency who is "glad" to solve a
citizen's problem as soon as the citizen fills out the "necessary"
paperwork, in spite of the fact that the problem is self-evident, and
the only thing preventing further action is the lack of paperwork.

> If you have further questions, please do not post further to this
> report, but contact me directly, post to the appropriate forum, and file
> a new report.

My questions are:

1. Why was useful information deleted from this bug report after
multiple users provided it?
2. Why was the bug marked Incomplete instead of Confirmed, given that
multiple users have confirmed the same behavior in the same...

Read more...

I just looked over the bug's history again and noticed this:

Fabio Marconi (fabiomarconi) wrote on 2010-08-18:
Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!
Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Christopher M. Penalver (penalvch) on 2012-04-26
Changed in linux (Ubuntu):
status: Confirmed → Incomplete

So we have many users confirming the bug. Then an Ubuntu Member and member of multiple testing and bug teams and other Ubuntu teams marks the bug Confirmed, saying it has enough info and is ready to be worked on. Then after 9 more user confirmations, a year and a half later someone else shows up and marks it Incomplete. Then he deletes useful, fresh debug info. And when one user actually does file another report as he insisted, it, too, is marked Incomplete.

...?

Yes, this is still an issue.

Adam, Christopher, Luke, Patrick and others, I find the following link very useful when tolerating upstream bug queues:

http://www.jwz.org/doc/cadt.html

I've been through three revisions of hardware in the four (yes, four) years since this bug was reported. I can just mail one of the old systems to Ubuntu and let them reconfirm ad nauseam themselves. For what it's worth, any T61p/ATI laptop from eBay will probably do.

The bad news for Ubuntu is that I (as an informed user, C developer, open source and commercial developer, and generally very good debugger) now only report bugs when I'm feeling particularly bored, as I don't expect them to get fixed. It's a two-way street.

gumkins (txtinzip) on 2013-09-25
Changed in linux (Ubuntu):
status: Incomplete → Confirmed

gumkins, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via http://www.ubuntu.com/support/community/mailinglists , or you may contact me directly.

Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
summary: - Everything gets swapped out after resume from suspend using fglrx
- drivers
+ [Dell Studio 17] Everything gets swapped out after resume from suspend
+ using fglrx drivers
Displaying first 40 and last 40 comments. View all 130 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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