Resume from sleep fails / extremely slow with fglrx

Bug #561292 reported by Johannes H. Jensen
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

With the 10.3 catalyst drivers (8.712) resume from suspend is either extremely slow (often takes over 5 minutes to resume) or fails completely. The machine seems to manage to resume, but it takes a long time until it's possible to log in (unlock the screensaver).

Further investigation with ssh and iotop reveals there's a tremendous amount of I/O going on, mainly by the X process. Sometimes the I/O stops after a while, other times it continues indefinitely and I have to hit the reset switch.

I'm attaching the syslog from a failed resume. Please let me know if there's any more information I can provide.

ProblemType: Bug
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: joh 4951 F.... pulseaudio
 /dev/snd/controlC0: joh 4951 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe7f8000 irq 22'
   Mixer name : 'Realtek ALC883'
   Components : 'HDA:10ec0883,1043829f,00100002'
   Controls : 35
   Simple ctrls : 20
Card1.Amixer.info:
 Card hw:1 'Q9000'/'Logitech, Inc. QuickCam Pro 9000 at usb-0000:00:1a.7-4, high speed'
   Mixer name : 'USB Mixer'
   Components : 'USB046d:0990'
   Controls : 2
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'Mic',0
   Capabilities: cvolume cvolume-joined cswitch cswitch-joined
   Capture channels: Mono
   Limits: Capture 0 - 3072
   Mono: Capture 0 [0%] [18.00dB] [on]
Card2.Amixer.info:
 Card hw:2 'Generic'/'HD-Audio Generic at 0xfe8fc000 irq 17'
   Mixer name : 'ATI R6xx HDMI'
   Components : 'HDA:1002aa01,00aa0100,00100200'
   Controls : 4
   Simple ctrls : 1
Card2.Amixer.values:
 Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [off]
Date: Mon Apr 12 10:27:52 2010
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=78eeea3c-7948-4887-9104-2d2647d8be59
MachineType: System manufacturer P5K
NonfreeKernelModules: fglrx
Package: linux-image-2.6.31-20-generic 2.6.31-20.58
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.31-20-generic root=UUID=47045301-e02a-4cb1-9cfe-edbd6fc4dc1a ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-20.58-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-20-generic N/A
 linux-firmware 1.26
RfKill:

SourcePackage: linux
Uname: Linux 2.6.31-20-generic x86_64
WifiSyslog:
 Apr 12 10:17:02 FarSite kernel: [ 5857.501315] kjournald starting. Commit interval 5 seconds
 Apr 12 10:17:02 FarSite kernel: [ 5857.501325] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
 Apr 12 10:17:02 FarSite kernel: [ 5857.506781] EXT3 FS on sdg1, internal journal
 Apr 12 10:17:02 FarSite kernel: [ 5857.506784] EXT3-fs: recovery complete.
 Apr 12 10:17:02 FarSite kernel: [ 5857.507404] EXT3-fs: mounted filesystem with writeback data mode.
WpaSupplicantLog:

dmi.bios.date: 10/14/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1201
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: P5K
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1201:bd10/14/2008:svnSystemmanufacturer:pnP5K:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP5K:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: P5K
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

Revision history for this message
Johannes H. Jensen (joh) wrote :
Revision history for this message
Johannes H. Jensen (joh) wrote :

Forgot to mention details on my graphics card, as I see it's not detected by lspci:

ATI Radeon HD 5770

Revision history for this message
Alexandre Rosenfeld (airmind) wrote :

I'm having the same problem with an ATI Mobility Radeon 3650 HD. WIth the open-source drivers, suspend from resume is very fast, but with the binary-only drivers sometimes it takes ages to resume, with the disc activity indicator on my laptop blinking a lot.
The open-source drivers are not an option to me because of the lack of power management, which drains my battery and keep my laptop too hot.

Revision history for this message
Vadym Krevs (vkrevs) wrote :

Similar problem on openSUSE 11.2 for x86_64 with ATI Mobility Radeon 3650 HD.

https://bugzilla.novell.com/show_bug.cgi?id=597613

Revision history for this message
Felix Kuehling (felix-kuehling) wrote :

The fglrx driver saves all used video memory to system memory before suspending. When you suspend to disk all that memory also has to be swapped out to the swap partition. If you have a graphics card with lots of memory and not a lot of available system memory, the saving of video memory will cause a lot of paging. This will affect your performance on suspend/resume. If your swap partition is too small that may cause suspend to fail completely.

Three factors that will have a big impact on your suspend performance:
1. amount of video memory (reported by amdcccle)
2. amount of available system memory (reported by free, 2nd line "-/+ buffers/cache")
3. amount of available swap space (reported by free, 3rd line)

Some rules of thumbs:
1. You should have about 1GB more system memory than video memory, more is better
2. You should have more swap space than system memory, typically by a factor 2

Possible remedies (depending on your situation):
1. make sure your swap partition is big enough, typical recommendation is 2x amount of RAM
2. get more RAM (always a good idea and a cheap option to improve overall system performance and responsiveness)

Revision history for this message
Johannes H. Jensen (joh) wrote :

@Felix Kuehling:

Thank you for your reply. The problem does not occur when suspending to RAM but when resuming from suspend.

1. My graphics card has 1024 MB of memory
2. I have 4 GB system memory - the amount of free memory depends of course.
3. I have 8 GB swap space - usually completely free

You're saying that unless I have 1024 MB of system memory *free* before I suspend to RAM, I'll get problems?
If I suspend to disk I should have better results as my swap space will easily hold both my system memory and video memory..?

Revision history for this message
Johannes H. Jensen (joh) wrote :

Suspended my computer to RAM yesterday with 1818 MB free system memory (of the total 3962 MB) and 181 MB swap used. That should be plenty of room for the 1024 MB video memory from my graphics card, right..?

Resumed it now and free reports 2382 MB free memory and 560 MB used swap. I/O is still very heavy now, 5 minutes after the resume with disk reads reported by iotop up to 2.5 MB/s by various processes - firefox, X, gnome-panel. Comparing with my laptop which has no disk reads whatsoever, this behavior seems far from normal to me...

So it doesn't seem like it's swapping at all - system memory is kept at a constant level. What I do notice, however, is that none of the system memory is used as buffers/cache. Could it be that for some reason cache has been disabled after resume which causes processes to constantly read from the disks?

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Hi Johannes,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Vadym Krevs (vkrevs) wrote :

I've followed the advice in #5 and increased swap size from 4Gb to 8Gb (double the RAM) on 26-Apr-2010. Since then I did not have a single "slow" resume from suspend or a failed resume from suspend. In fact, resume from suspend is now very quick.

Felix, thank you very much.

Revision history for this message
Johannes H. Jensen (joh) wrote :

@Vadym: How much system and graphics memory do you have?

Revision history for this message
Johannes H. Jensen (joh) wrote :

Jeremy,

Which kernel version do you want me to test? The one mapping to my current ubuntu kernel (2.6.31-20.58) or the most current version (http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/)?

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Johannes,
     Ideally the most current. i understand if this is not possible.

Thanks!

~JFo

Revision history for this message
Vadym Krevs (vkrevs) wrote :

@Jonannes: My machine has 4GB RAM and 256Mb video RAM. It used to have a 2Gb swap partition, which I'd resized to 8GB.

Revision history for this message
Johannes H. Jensen (joh) wrote :

Interesting - version 10.4 of the catalyst driver was released two days ago and the release notes mention the following under "Resolved Issues":

 - System will now resume properly after hibernation/suspend mode

Hopefully that might be related to this bug..? I'll upgrade the driver and test...

Revision history for this message
Johannes H. Jensen (joh) wrote :

Just tested resuming with catalyst 10.4 and did not have any problems. As far as I can see this bug is fixed :-)

Changed in linux (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Vadym Krevs (vkrevs) wrote :

Sadly, the issue is back for me. It now occurs less frequently, which leads me to believe that my system experienced a combination of two issues - one caused by insufficient swap size and another yet unknown.

Revision history for this message
Johannes H. Jensen (joh) wrote :

@Vadym: You're right, I just experienced the issue again. I'll test with the mainline kernels and report further...

Changed in linux (Ubuntu):
status: Fix Released → Incomplete
Revision history for this message
Johannes H. Jensen (joh) wrote :

The computer didn't even resume on 2.6.34... No signals to the screen - doesn't even respond to ping.

Revision history for this message
Johannes H. Jensen (joh) wrote :

Yeah, the mainline kernel is even more unreliable when it comes to resume - sometimes it works okay but other times it never seems to resume fully and I have to hit the reset button. As mentioned, there's no signal to the screen at all and it doesn't even respond to ping at this point.

tags: removed: needs-upstream-testing
Changed in linux (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
Revision history for this message
jon h (johnny-hill) wrote :

same problem. i have ATI 5700 series video card with 1Gb video ram, and desktop has 4Gb system ram. im suspending to ram and after the second or third resume, system is very slow. vmstat shows a lot of swapping, and cpu wait. logging out and back in fixes problem ( presumably resets X server ). im on 2.6.32-23 64 bit kernel.

Revision history for this message
jon h (johnny-hill) wrote :

suspend to RAM now works for me with Catalyst 10.7, 2.6.32-24-generic #38-Ubuntu SMP

Revision history for this message
Roland Schulz (roland-rschulz) wrote :

@jon h: Did you only update the kernel or also the Catalyst driver since 7-22? The change-log of 2.6.32-23 doesn't mention anything which should affect this bug.

Revision history for this message
jon h (johnny-hill) wrote :

spoke too soon : after several successful suspends, i had the same issue.

Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

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

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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