I've been able to successfully suspend & resume my Dell M50 laptop by using /sys/power/state in a script which first stops some services like hotplug & MySQL which are known to disagree with ACPI suspend to ram, and then starts them again on resume.
The problem is that on resume the PCI bus registers are being corrupted it seems.
dmesg says this on resume:
Stopping tasks: ==================================================================================================== ==|
NVRM: RmPowerManagement: 3
PM: Entering state.
Back to C!
PM: Finishing up.
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PCI: Setting latency timer of device 0000:00:1f.5 to 64
PCI: Setting latency timer of device 0000:00:1f.6 to 64
NVRM: RmPowerManagement: 4
PCI: Enabling device 0000:02:01.2 (0000 -> 0002)
Restarting tasks... done
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
I suspect that the problem occurs when the PCI latency timer is set on resume. (?)
There's a report of a kernel bug along these lines here:
http://bugme.osdl.org/show_bug.cgi?id=3609
"/etc/init.d/networking start" has this to say on resume:
Configuring network interfaces...Internet Software Consortium DHCP Client 2.0pl5Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.
Please contribute if you find this software useful.
For info, please visit
http://www.isc.org/dhcp-contrib.html
sit0: unknown hardware address type 776
irda0: unknown hardware address type 783
eth1: unknown hardware address type 24
sit0: unknown hardware address type 776
irda0: unknown hardware address type 783
eth1: unknown hardware address type 24
Listening on LPF/eth0/00:0b:db:14:22:3e
Sending on LPF/eth0/00:0b:db:14:22:3e
Sending on Socket/fallback/fallback-net
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
No DHCPOFFERS received.
Trying recorded lease 218.125.48.35
PING 218.125.49.254 (218.125.49.254) 56(84) bytes of data.
--- 218.125.49.254 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
bound: renewal in 41771 seconds.
done.
After resuming, each time a DHCPDISCOVER is returned the system stutters for a moment, but aside from that, once it gives up and uses the recorded lease the system including the nvidia 3D driver, usb mouse and sound continue to function as normal.
eth0's led's seem to be alive but of course the network is down.
I'm using Debian unstable Linux version 2.6.7-1-686.
Anyone have any similar experiences or any suggestions to offer?
(If you got this far down then thanks for reading!)
cheers
