Computer feeling quite slow after suspend/resume

When that happens, I have the following backtrace in /var/log/messages:

I have a stack trace too.

Jul 16 14:58:08 luz kernel: [19043.784323] ------------[ cut here ]------------
Jul 16 14:58:08 luz kernel: [19043.784325] WARNING: at /build/buildd/linux-2.6.28/kernel/power/main.c:177 suspend_test_finish+0x80/0x90()
Jul 16 14:58:08 luz kernel: [19043.784326] Component: resume devices
Jul 16 14:58:08 luz kernel: [19043.784327] Modules linked in: i915 drm binfmt_misc btusb bridge stp bnep vboxnetflt vboxdrv ppdev parport_pc sbp2 lp parport snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device intel_agp snd soundcore isight_firmware iTCO_wdt iTCO_vendor_support video ieee80211_crypt_tkip agpgart joydev snd_page_alloc applesmc hid_apple output led_class pcspkr appletouch wl(P) ieee80211_crypt input_polldev usbhid ohci1394 ieee1394 sky2 fbcon tileblit font bitblit softcursor
Jul 16 14:58:08 luz kernel: [19043.784355] Pid: 32716, comm: pm-suspend Tainted: P 2.6.28-13-generic #45-Ubuntu
Jul 16 14:58:08 luz kernel: [19043.784356] Call Trace:
Jul 16 14:58:08 luz kernel: [19043.784360] [<c0139ab0>] warn_slowpath+0x60/0x80
Jul 16 14:58:08 luz kernel: [19043.784363] [<c015381a>] ? down_trylock+0x2a/0x40
Jul 16 14:58:08 luz kernel: [19043.784365] [<c013a10d>] ? try_acquire_console_sem+0xd/0x30
Jul 16 14:58:08 luz kernel: [19043.784368] [<c02c74a0>] ? kobject_put+0x20/0x50
Jul 16 14:58:08 luz kernel: [19043.784371] [<c04fcbf6>] ? printk+0x18/0x1a
Jul 16 14:58:08 luz kernel: [19043.784374] [<c0164ff0>] suspend_test_finish+0x80/0x90
Jul 16 14:58:08 luz kernel: [19043.784376] [<c01650c6>] suspend_devices_and_enter+0xc6/0x160
Jul 16 14:58:08 luz kernel: [19043.784378] [<c04fcbf6>] ? printk+0x18/0x1a
Jul 16 14:58:08 luz kernel: [19043.784380] [<c0165349>] enter_state+0xc9/0x100
Jul 16 14:58:08 luz kernel: [19043.784382] [<c01653fd>] state_store+0x7d/0xc0
Jul 16 14:58:08 luz kernel: [19043.784384] [<c0165380>] ? state_store+0x0/0xc0
Jul 16 14:58:08 luz kernel: [19043.784386] [<c02c7364>] kobj_attr_store+0x24/0x30
Jul 16 14:58:08 luz kernel: [19043.784389] [<c020aba2>] sysfs_write_file+0x92/0xf0
Jul 16 14:58:08 luz kernel: [19043.784392] [<c01bdad8>] vfs_write+0x98/0x110
Jul 16 14:58:08 luz kernel: [19043.784394] [<c020ab10>] ? sysfs_write_file+0x0/0xf0
Jul 16 14:58:08 luz kernel: [19043.784396] [<c01bdc0d>] sys_write+0x3d/0x70
Jul 16 14:58:08 luz kernel: [19043.784398] [<c0103f6b>] sysenter_do_call+0x12/0x2f
Jul 16 14:58:08 luz kernel: [19043.784400] ---[ end trace 89ae7eeb74151c0f ]---

This bug is similar to bug #373690 but categorized under the linux package and with all files automatically collected from 'ubuntu-bug linux'.

I propose 50€ to fix this bug: http://www.cofundos.org/project.php?id=178

From Zhang Rui 2010-01-18 02:42:33 (http://bugzilla.kernel.org/show_bug.cgi?id=14718):
    so please boot with kernel parameter "irqpoll" and see if the problem still exist.

I have the same problem.

What I can add is that the slowness comes from the HDD working on "something"

I managed to open gnome-system-monitor, and I saw that the system was using huge amounts of memory:

1.5 GB of RAM and 1.1 GB of swap.

The computer was slow as when you are copying files.

I have no idea why this happens only when resuming from suspend.

Duplicate of: 236275 ?
https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/236275

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.

Proposed workaround:

I read another place that taking out the battery would help.

And it does!

Today I suspended my 20 GB HP 8540w to RAM. 2.7 GB of this RAM was in use. After resume everything is working as if the 1.6 GHz 4 core CPU has been replaced with a 16 MHz 4 core CPU: I can start multiple processes but they often take up 100% of a core.

Then I suspended to RAM again, removed the battery (this obviously only works if you are on AC), and resumed. Now the machine is working as the expected 1.6 GHz 4 core again.

Plugging the battery back in after resume did not crash anything.

I believe I found the root cause:

$ cpufreq-info |grep policy
  current policy: frequency should be within 933 MHz and 933 MHz.

So the frequency governor cannot select a faster speed than 933 MHz even tough the CPUs support 1.6 GHz.

I changed /etc/default/cpufrequtils to:

MAX_SPEED="1600000"

and have not seen the issue since.

A better fix would be to have /etc/init.d/cpufrequtils default to the max value if MAX_SPEED = 0.