Resume from suspend takes a long time on a VAIO laptop

[Wirawan Purwanto]

I have a Sony VAIO laptop (PCG-FXA53), which is an old laptop powered by an AMD Athlon XP 1400+ processor, 512 MB RAM. Using Intrepid is fine with this laptop with the exception that resuming from sleep (ACPI S3) is a pain: there is a delay of nearly 122 seconds from the time the computer is awake from sleep till the OS is ready to use again. Here's a relevant section of the PM log in the dmesg (I am attaching the full dmesg separately).

~$ dmesg |grep 'PM: '
[ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000c0000
[ 0.000000] PM: Registered nosave memory: 00000000000c0000 - 00000000000d4000
[ 0.000000] PM: Registered nosave memory: 00000000000d4000 - 00000000000dc000
[ 0.000000] PM: Registered nosave memory: 00000000000dc000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 000000001fef0000 - 000000001feff000
[ 0.000000] PM: Registered nosave memory: 000000001feff000 - 000000001ff00000
[ 6.622715] PM: Starting manual resume from disk
[ 6.622781] PM: Resume from partition 8:5
[ 6.622784] PM: Checking hibernation image.
[ 6.623329] PM: Resume from disk failed.
[ 223.392615] PM: Syncing filesystems ... done.
[ 223.552287] PM: Preparing system for mem sleep
[ 223.601109] PM: Entering mem sleep
[ 225.476127] PM: suspend devices took 1.876 seconds
[ 348.200804] PM: resume devices took 122.720 seconds
[ 348.201238] PM: Finishing wakeup.

I looked back at the kern.log files, almost all resumes took 122 seconds! So something is definitely, but almost consistently, wrong. I said "almost" because some entries also showed quick resumes within <3 seconds. This is puzzling. The problem appears with kernel 2.6.27-9-generic and 2.6.27-11-generic. This kind of problem was also observed with Hardy, but not with Feisty or Gutsy. All kernels are standard kernels provided by Ubuntu. But Intrepid does not cause this problem on my Dell laptop.

lspci gives:

$ lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
00:07.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 30)
00:0a.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller
00:0a.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller
00:0e.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link)
00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)

The cardbus slot was used by 3Com wireless card (Atmel chipset).

Wirawan

[Serge Hallyn (serge-hallyn)]

Please reply if this is still an issue in a supported release.