Talk:Problems with ACPI suspend-to-ram - Revision history

Mbg71: /* Intermittent lock-up on resume with X31 */

2009-10-18T02:34:36Z

‎Intermittent lock-up on resume with X31

Mbg71: /* Intermittent lock-up on resume with X31 */

2009-10-11T01:57:59Z

‎Intermittent lock-up on resume with X31

Sylence: /* Intermittent lock-up on resume with X31 */

2008-08-11T18:42:31Z

‎Intermittent lock-up on resume with X31

Sylence: /* Intermittent lock-up on resume with X31 */

2008-08-11T18:41:39Z

‎Intermittent lock-up on resume with X31

Sylence: /* Intermittent lock-up on resume with X31 */

2008-08-11T18:40:56Z

‎Intermittent lock-up on resume with X31

Sylence: /* Intermittent lock-up on resume with X31 */

2008-08-11T18:34:06Z

‎Intermittent lock-up on resume with X31

Mbg71: /* Intermittent lock-up on resume with X31 */

2008-06-29T00:24:21Z

‎Intermittent lock-up on resume with X31

Eater: /* Intermittent lock-up on resume with X31 */

2008-06-06T01:10:39Z

‎Intermittent lock-up on resume with X31

Stephen: /* Intermittent lock-up on resume with X31 */

2007-09-02T17:24:51Z

‎Intermittent lock-up on resume with X31

Mbg71: /* Intermittent lock-up on resume with X31 */

2007-08-23T11:08:29Z

‎Intermittent lock-up on resume with X31

← Older revision		Revision as of 02:34, 18 October 2009
Line 117:		Line 117:

	I spent 4 months using my machine on a wired connection and experienced a dramatic decrease in the number of lock-ups on resume. This reinforces my belief that the ipw2200 driver is the problem or at least a major contributor. Otherwise things are the same as before, now on kernel 2.6.26 (Debian Lenny), ACPI 20080321, ieee80211 git-1.1.13, ipw2200 1.2.2kmprq --[[User:Mbg71\|Malcolm]] 01:57, 11 October 2009 (UTC)		I spent 4 months using my machine on a wired connection and experienced a dramatic decrease in the number of lock-ups on resume. This reinforces my belief that the ipw2200 driver is the problem or at least a major contributor. Otherwise things are the same as before, now on kernel 2.6.26 (Debian Lenny), ACPI 20080321, ieee80211 git-1.1.13, ipw2200 1.2.2kmprq --[[User:Mbg71\|Malcolm]] 01:57, 11 October 2009 (UTC)
		+
		+	PS This Intel wireless bug may be relevant: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1854
		+
		+	--[[User:Mbg71\|Malcolm]] 02:34, 18 October 2009 (UTC)
		+

	With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?		With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?

← Older revision		Revision as of 01:57, 11 October 2009
Line 115:		Line 115:

	--[[User:Mbg71\|Malcolm]] 02:24, 29 June 2008 (CEST)		--[[User:Mbg71\|Malcolm]] 02:24, 29 June 2008 (CEST)
		+
		+	I spent 4 months using my machine on a wired connection and experienced a dramatic decrease in the number of lock-ups on resume. This reinforces my belief that the ipw2200 driver is the problem or at least a major contributor. Otherwise things are the same as before, now on kernel 2.6.26 (Debian Lenny), ACPI 20080321, ieee80211 git-1.1.13, ipw2200 1.2.2kmprq --[[User:Mbg71\|Malcolm]] 01:57, 11 October 2009 (UTC)

	With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?		With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?

@@ Line 116: / Line 116: @@
 --[[User:Mbg71|Malcolm]] 02:24, 29 June 2008 (CEST)
-With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second try to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
+With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second I'm trying to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
 I've no idea how to get some debug output or how to reproduce this behaviour, it just happends sometimes in the same setup i'm using all the time.

@@ Line 116: / Line 116: @@
 --[[User:Mbg71|Malcolm]] 02:24, 29 June 2008 (CEST)
-With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after suspend my normal conservative goveror is restored. Before the governor hack it crashed on every second try to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
+With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after resume my normal conservative goveror is restored. Before the governor hack it crashed on every second try to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
 I've no idea how to get some debug output or how to reproduce this behaviour, it just happends sometimes in the same setup i'm using all the time.

@@ Line 120: / Line 120: @@
 I've no idea how to get some debug output or how to reproduce this behaviour, it just happends sometimes in the same setup i'm using all the time.
---[[User:Sylence|Sylence]] 20:34, 11 August 2008 (CEST)
+Symptons: hard-drive is spinning up; sleep light stays on; battery light is going on; systems seems to be under heavy load (fan is rotating after ~10 minutes); display remaining black; no reaction on user input; if connected to my ultrabase, the cd drive is spinning up and it's control light is activated
 == Unable to resume R40e after suspend-to-RAM ==

← Older revision		Revision as of 18:34, 11 August 2008
Line 115:		Line 115:

	--[[User:Mbg71\|Malcolm]] 02:24, 29 June 2008 (CEST)		--[[User:Mbg71\|Malcolm]] 02:24, 29 June 2008 (CEST)
		+
		+	With custom kernel 2.6.24.x and some hacks suspend to ram works in 9 of 10 cycles. On suspend i'm using scripts to disable and unload wifi drivers, to eject a possibly attached ultrabay drive and to use the "userspace goveror", as written above - after suspend my normal conservative goveror is restored. Before the governor hack it crashed on every second try to resume, so it's a lot better now. But I don't want to use a system's suspend features, which maybe crashes on resume. So any ideas, why it doesn't work all the time?
		+
		+	I've no idea how to get some debug output or how to reproduce this behaviour, it just happends sometimes in the same setup i'm using all the time.
		+
		+	--[[User:Sylence\|Sylence]] 20:34, 11 August 2008 (CEST)

	== Unable to resume R40e after suspend-to-RAM ==		== Unable to resume R40e after suspend-to-RAM ==

@@ Line 107: / Line 107: @@
 My X31 won't wake up from sleep, ever. It beeps as though it's about to, but the fan whirs and the screen stays black and the machine won't respond to anything. Hibernate works fine. This is using ACPI under Ubuntu 8.04.
 --[[User:Eater|Eater]] 03:10, 6 June 2008 (CEST)
 == Unable to resume R40e after suspend-to-RAM ==

@@ Line 103: / Line 103: @@
 I tried it and have had no lockups for the past week, a few dozen sleep/resumes.  I've now edited /etc/sysconfig/cpuspeed to set userspace on boot.  Might work for you too - worth a try anyway.
 --[[User:Stephen|Stephen]] 17:24, 2 September 2007 (UTC)
 == Unable to resume R40e after suspend-to-RAM ==

← Older revision		Revision as of 17:24, 2 September 2007
Line 98:		Line 98:

	--[[User:Mbg71\|Malcolm]] 11:08, 23 August 2007 (UTC)		--[[User:Mbg71\|Malcolm]] 11:08, 23 August 2007 (UTC)
		+
		+	I was having the same problem under fedora 7, kernel 2.6.21-1.3194.fc7 - I could resume maybe 3 times out of 4. This is with all combinations of acpi_sleep= and ec_intr=0 boot parameters. Recently I found a suggestion (sorry, I've lost the reference) that the problem could be the kernel cpu speed governor. The suggested cure was (with root permissions)
		+	echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
		+	I tried it and have had no lockups for the past week, a few dozen sleep/resumes. I've now edited /etc/sysconfig/cpuspeed to set userspace on boot. Might work for you too - worth a try anyway.
		+	--[[User:Stephen\|Stephen]] 17:24, 2 September 2007 (UTC)

	== Unable to resume R40e after suspend-to-RAM ==		== Unable to resume R40e after suspend-to-RAM ==

← Older revision		Revision as of 11:08, 23 August 2007
Line 94:		Line 94:

	--[[User:Mbg71\|Malcolm]] 12:30, 11 February 2007 (CET)		--[[User:Mbg71\|Malcolm]] 12:30, 11 February 2007 (CET)
		+
		+	I've been running an Ubuntu 2.6.20.3 kernel for about 3 months, and still experience lock ups. I still suspect the ipw2200 driver is involved, as occasionally it will stop working after a resume. I'll try a 2.6.22 kernel some time.
		+
		+	--[[User:Mbg71\|Malcolm]] 11:08, 23 August 2007 (UTC)

	== Unable to resume R40e after suspend-to-RAM ==		== Unable to resume R40e after suspend-to-RAM ==