Slow suspend/resume in Hardy

[Mozg]

I would like to mention that I've noticed considerably slower resuming from suspend to ram in Hardy as compared with Gutsy. I had timed the suspend / resume on Gutsy and Hardy and notied the following trend. The suspending timing is the same: about 12-13 seconds from pressing the Suspend button to the system in sleep state. However, resuming takes twice as long in Hardy. Gutsy manages to fully wake up and present the password prompt in 14-17 seconds, where as Hardy does it in 30-40 seconds. As you can see the difference is great, taking into account that it takes about 35-40 seconds to boot into Ubuntu from fresh boot and resuming from sleep should be done much faster!

Just to mention that the tests were run on the same hardware: I used to run Gutsy and about 2 weeks ago upgraded to Hardy. So, all applications/settings/hardware was the same, including /etc/default/acpi-support. In both cases I used nvidia proprietary drivers version 169.12 installed using envy.

output of lspci:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
15:00.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)
15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)

lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

[Dave (dave-l-harrison)]

I see this under hardy as well, it only started after an update about two or three weeks ago though. Until recently, restore from hibernate and suspend was very fast, now it's at least 30-40 seconds just to come back from a suspend.

I'm on a Thinkpad X60s

lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

[imminentwill (colin-uk)]

Same situation for me on a Thinkpad X41 Tablet. 50-60 seconds to resume from suspend on Hardy.

lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

[imminentwill (colin-uk)]

Here's the result from 'dmesg | tail' after resuming from suspend.

[Mozg (andrei-arhont)]

Thanks to Andy Goossens from Bug 217841 (https://bugs.launchpad.net/ubuntu/+bug/217841) for posting the acpi-default config file from Thinkwiki I have managed to fix the the slow suspend/resume. I am now back to about 12-13 seconds to sleep and about 13-15 seconds to resume. That is relatively fast comparing to what it was before. However, I am wondering how Windows + Lenovo drivers manages to resume in about 5 seconds?

[imminentwill (colin-uk)]

I've found another solution for my slow suspend problem. Using advice from lbharti (http://ubuntuforums.org/showthread.php?t=690933), I installed the hibernate package. I can now resume from suspend in about 8-9 seconds.

[cdiggity (craig-nzenergy)]

My resume takes nearly a minute but I have the intel graphics not nvidia. Andy Goosens acpi-support file linked to by Mozg above does not make it any faster.

[cdiggity (craig-nzenergy)]

and my lspci output. This is an R61i

[Mozg (andrei-arhont)]

What i have noticed is that I get a slow resume from suspend when my Xorg server restarts. Whenever the Xorg resumes from suspend without any problems, it is relatively fast (around 15 seconds).

[Jon-o Addleman (jaddle)]

I'm seeing the same thing. Oddly, for a while last week it was working flawlessly again - I assumed it was some updated package updated that had some effect. But now it's taking ~45 seconds to resume again.

I'm using an X60s thinkpad. Is there any other info that I can supply to help track down the problem?

[cdiggity (craig-nzenergy)]

My suspend / resume times are under 10s at the moment. I don't know what has changed but something has made a difference. I've attached my acpi-support file in case this can be helpful to anyone. I haven't changed this file since May4th so my now fast resumes are not due to any recent changes I have made in acpi-support.

[Jon-o Addleman (jaddle)]

I just tried using cdiggity's acpi-support file, but saw no improvement. I guess the delay must be caused somewhere else, then.

[Mozg (andrei-arhont)]

cdiggity: I was wondering if you could post your xorg.conf and lspci
-vv files as well. Actually, under 10 seconds resume/suspend is
excellent, as even when I had Edgy installed, I was never achieving
these times. To be honest, I am finding Hardy very dissapointing when
it comes to hardware support. My performance/stability in Edgy was
better. suspend/resume has never failed on T61p, whereas in Hardy it
works fine at its best 3 times out of 10 (( and I was never able to
successfully resume when connected to a docking station. My mate on
the exact hardware on Gentoo has no problems in 2.6.24 kernel.
 Andrei
 ----- Original Message -----
 Subject: [Bug 217846] Re: Slow suspend/resume in Hardy
 From: cdiggity
 To: <email address hidden>
 Date: 25/05/2008 5:50
 My suspend / resume times are under 10s at the moment. I don't know
 what has changed but something has made a difference. I've attached
my
 acpi-support file in case this can be helpful to anyone. I haven't
 changed this file since May4th so my now fast resumes are not due to
any
 recent changes I have made in acpi-support.
 ** Attachment added: "acpi-support"
 http://launchpadlibrarian.net/14695477/acpi-support
 --
 Slow suspend/resume in Hardy
 https://bugs.launchpad.net/bugs/217846
 You received this bug notification because you are a direct
subscriber
 of the bug.

[Mozg (andrei-arhont)]

Sorry, in the previous message where I've mentioned Edgy I meant Gutsy (7.10).

[Jon-o Addleman (jaddle)]

Here's my lcpci -vv

[Jon-o Addleman (jaddle)]

and my xorg.conf.

[cdiggity (craig-nzenergy)]

attached lspci for my lenovo thinkpad r61i with intel graphics

[cdiggity (craig-nzenergy)]

and xorg.conf.
Perhaps I should mention that I patched my intel video driver a while back so that I could use compiz and Xv. http://linux.pengin.de/#intel

[cdiggity (craig-nzenergy)]

Between june 4th and 9th my suspend/resume started to take a long time again. Apart from the automatic updates all I can think of that is changed is 1) my location on earth by 5000km and 2) the access point I'm connecting to now uses WPA instead of WEP.

I've tried disabling my wireless and doing suspend resumes but it didn't seem to have any effect.

[Swâmi Petaramesh (swami-petaramesh)]

Confirmed here (alas) with an Acer Aspire 3104WLMi running Hardy (fglrx drivers, madwifi drivers). Initially resuming from suspend to RAM was quite fast, but after recent Ubuntu updates now "suspending" looks normally fast (except once, trying to suspend ended in "kernel panic") but resuming takes *minutes* with the hard disk working like crazy. During this time the screen is black and backlight off, keyboard not responding. Meanwhile the machine however pings (thru Wi-Fi) and can be accessed from remote using SSH...

No change in hardware or whatever between the times when it was fast and now that it has become dreadfully slow.

Once resumed I notice more than 780 MB of swap used when there was little swap used before suspending.

In the current situation it takes more time to resume from suspend than to restart from hibernate or event to cold boot... Which makes suspending to RAM completely useless...

[Jon-o Addleman (jaddle)]

Hmm, Swami's experience is quite different from mine - when a resume
takes a long time (happens on almost all resumes and takes about a
minute), I see essentially no activity - every once in a while, the hard
disk light flickers, but nothing else. I haven't been able to test if it
can be pinged, but I doubt it, since nothing seems active at all.

--
Jon-o Addleman - http://www.redowl.ca

[Swâmi Petaramesh (swami-petaramesh)]

Hmmm... Actually I tried to ping and SSH to the laptop after I got tired of waiting in front of a black unresponsive machine with a gone-crazy HD. By that time the machine was actually properly anwering ping and SSH thru Wi-Fi, but it had already been "trying to wake up" for at least a cigarette and a cup of coffee ;-)
When I went back to the laptop it still took a couple dozens of seconds before I could in the end get an image on screen (KDE screensaver unlock dialog) and found myself back into a very slow and dramatically swapping, but otherwise working system.

[Swâmi Petaramesh (swami-petaramesh)]

On the other hand, my Dell XPS M1330 laptop (madwifi, Intel video) wakes up after "suspend to RAM" in approx 3 seconds...

Both machines run Hardy with all updates applied and on both machines (Acer Aspire and Dell XPS) I initiated "suspend" just by closing the laptop screen with KDE "power manager" set to "suspend when lid closed".

And although the wake up time of the Dell XPS looks surprisingly short (especially compared to the Acer...) I can confirm it was actually suspended (Ethernet LED went off, screen backlight went off, power LED started blinking) and actually woke up (panel LEDs flashed, DVD writer issued a noise, Ethernet LED went back, screeen lit).

So different machines can really show a very different behaviour in Hardy, but before some updates were applied, my Acer was behaving more or less like the Dell, only a little slower :-(

[dave (dave-wo-ist)]

on my laptop (T43p) slow resume is caused by an network issue.
I resolved the problem by using another /etc/network/interfaces

## fast (note: NO auto eth0) ##
# The loopback network interface
auto lo
iface lo inet loopback

# wireless
auto ath0
iface ath0 inet dhcp
        wpa-driver madwifi
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

# ethernet
iface eth0 inet dhcp

## slow ##
auto lo
iface lo inet loopback

# wireless
auto ath0
iface ath0 inet dhcp
        wpa-driver madwifi
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

# ethernet
auto eth0
iface eth0 inet dhcp

[Jon-o Addleman (jaddle)]

YES! Thank you dave! Removing the 'auto' line for my ethernet fixed the
problem for me as well.

Definitely a bug though, if the resuming process waits for the network
devices to get fully activated before proceeding.

--
Jon-o Addleman - http://www.redowl.ca

[cdiggity (craig-nzenergy)]

'me too'. thanks dave!!!

[dave (dave-wo-ist)]

You're welcome!

[Swâmi Petaramesh (swami-petaramesh)]

Here the /etc/network/interfaces is not involved in slow resume after suspend to RAM, so the proposed workaround doesn't help.

When resuming my Acer Aspire 3104 WLMi, my hard disk always works like crazy for at least 1 minute before I at least get the screen backlight to light again, and still more before I eventually get the screensaver unlock prompt. After resumed I notice the swap is highly used (at least 400 MB) even if it was almost empty when I suspended.

The machine has 1 GB RAM and 2 GB swap, and I have no clue about why it happens only with this laptop : I have several Kubuntu Hardy laptops, and only this one shows such a resume behaviour, the fastest one being a Dell XPS M1330 on which resuming is really completely intantaneous.

[Stefanie Tellex (et47hd802)]

Removing auto eth0 worked for me as well.

I'm running a Dell Latitude D830 N Series, with an updated Hardy.

Thanks,

Stefanie

[Yann (lostec)]

A better workaround to the same bug I already posted, as this bug is caused by dhcp timeouts while no ethernet cable is plugged:
https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/236066

With this setup, eth0 will only be setup if a network cable is plugged. So wired network will still be usable if connected at boot/wake-up from suspend.

[Yann (lostec)]

Changed status as confirmed as this problem is obvious for anyone not relying on first listed eth0 interface: All machines connected thru wifi (usually listed as eth1) are at least concerned.

I added a fix from a duplicate bug to cope with this, but it's far from perfect (will set up an unused interface if a cable is plugged during a session?): MII management to check link up should be checked by eth drivers and MII interrupt used to react to link status change and associated eth setup/re-configuration.

Also assigned to kernel team that should be in charge of ethernet modules? Or maybe someone here will read assigned bug and know where this annoying one should go for a real fix.

Regards.

[Izkata (izkata)]

Another confirmation for networks. In my case, both suspend and hibernate were extra slow.

I had to remove "auto eth1" - my wireless - from /etc/network/interfaces and it was fixed immediately.

Best guess as to why my wireless and not everyone else's is because I'm using ndiswrapper for a Broadcom card. It has a lot of quirks (which this must just be another), but otherwise works well.

[Phillip Susi (psusi)]

Is this still happening for you in 12.04 or later?

[Jon-o Addleman (jaddle)]

I'm not having a problem with it any more (currently using 13.04).

[Launchpad Janitor (janitor)]

[Expired for Ubuntu because there has been no activity for 60 days.]