Skip to contentSkip to conversation

status update for current development on ASUS M2N

DISCUSSION Georg C. F. Greve 4 participants 7 messages Sep 27, 2004 – Sep 30, 2004 1 message not in the archive ACPI

lore
Share & tools
lore
#0 lore raw

Hi all,

FYI:

My latest kernel, which looks like

Patches contained:

linux-2.6.8
patch-2.6.9-rc2

software-suspend-108-for-2.6.9-rc2 (without kdb)
software-suspend-108-fixes (from http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/linux-2.6-software-suspend-fixes.patch?rev=1.3)

2.6.9-rc2-mm3/bk-acpi.patch

	./acpi-compile-fix.patch
	./acpi-x86_64-build-fix.patch
	./bk-agpgart.patch
	./bk-alsa.patch
	./bk-cpufreq.patch

ipw2100-0.54

arch/i386/kernel/i8259.c:

* changed device_initcall(i8259A_init_sysfs);
to late_initcall(i8259A_init_sysfs);
(needed for suspend to RAM)

Makefile:

* added -plus version

seems not so bad.

Both suspend to ram and suspend to disk via swsusp2 (108) appear to work fine. I completed a few cycles without problems.

However: If I suspend to ram once and then suspend to disk, resume From disk works fine, but about 20 seconds to 1 minute later, the load suddenly jumps to 100% and stays there.

The kacpid process seems to run wild and eat all available time, it looks like some kind of wild loop, but there is no output. I can normally shut the machine down -- although it takes a while.

I've tried compiling ACPI as modules and unloading the modules as well as restarting the acpid before/after suspend to disk. Upon reloading the modules things hang with "thermal" -- but that seems arbitrary, the effect still shows up even if no thermal is loaded.

Not sure this helps anyone improve things, still wanted to give you the feedback, though.

Regards,
Georg

Signature · 3 lines
Georg C. F. Greve                                       <[email protected]>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)
#1 lore raw

Hi Georg.

Quoted 3 lines · Georg C. F. Greve

The kacpid process seems to run wild and eat all available time, it looks like some kind of wild loop, but there is no output. I can normally shut the machine down -- although it takes a while.

Could I get you to compile kdb in as well. If you then press the Sys Rq key when the CPU is being chewed, you should be able to use ps and btp <process number> to get an idea of what is going on. There have been thermal issues reported on the help list. They might be related. I'll see if I can reproduce anything on my desktop.

Regards,

Nigel

Signature · 7 lines
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
#2 lore raw
 || On Mon, 27 Sep 2004 20:11:41 +1000
 || Nigel Cunningham <[email protected]> wrote: 

nc> Could I get you to compile kdb in as well.

I wish I could give you the info, tried compiling things in, but unfortunately the machine dies on suspend to disk when the kdb code is compiled in, it seems.

Unfortunately I'm lacking the time to investigate it further right now, but I will try later if I get the chance.

Regards,
Georg

Signature · 3 lines
Georg C. F. Greve                                       <[email protected]>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

A message that is not in the archive (sent off-list or not yet received): 1096279213.4222.5.camel-AdgCB+f5QAxwBzq2CxEN2SkBHpOjBR89@public.gmane.org

#4 lore raw
 || On Mon, 27 Sep 2004 20:11:41 +1000
 || Nigel Cunningham <[email protected]> wrote: 

nc> Could I get you to compile kdb in as well. If you then press the nc> Sys Rq key when the CPU is being chewed, you should be able to nc> use ps and btp <process number> to get an idea of what is going nc> on.

I am now running kernel

Patches contained:

linux-2.6.8
patch-2.6.9-rc2

software-suspend-109-for-2.6.9-rc2 (without kdb)
build fix for swsusp 109 - see https://lists.berlios.de/pipermail/softwaresuspend-devel/2004-September/000555.html

2.6.9-rc2-mm4/bk-acpi.patch

	acpi-compile-fix.patch
	acpi-x86_64-build-fix.patch
	bk-agpgart.patch
	bk-alsa.patch
	bk-cpufreq.patch

ipw2100-0.55

arch/i386/kernel/i8259.c:

* changed device_initcall(i8259A_init_sysfs);
to late_initcall(i8259A_init_sysfs);
(needed for suspend to RAM)

Makefile:

* added -plus version

and also created a version with kdb and heavy debugging.

This kernel shows the same behaviour and can suspend/resume so I can get into kdb and do btp. Unfortunately I seem to be too stupid to find the way to get the output somehow saved or written anywhere.

Not having the time (and motivation, to be honest) to write down all the names and numbers -- and also not feeling that sending digital photographs is the best way of communicating that output -- I don't know how to give you that information.

Can you tell me how to do this, please?

Regards,
Georg

Signature · 3 lines
Georg C. F. Greve                                       <greve-mXXj517/[email protected]>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)
#5 lore raw
In reply to Georg C. F. Greve

Thus wrote Georg C. F. Greve:

Quoted 3 lines

However: If I suspend to ram once and then suspend to disk, resume From disk works fine, but about 20 seconds to 1 minute later, the load suddenly jumps to 100% and stays there.

I had that issue too, with 2.6.9-rc1 I s'pose, but I thought it was just bug #3193 revisited and didn't really investigate. Does changing swsusp2 to _not_ use ACPI S4 help?
Best regards,

Signature · 2 lines
Karol 'sziwan' Kozimor
[email protected]
#6 lore raw
 || On Mon, 27 Sep 2004 14:33:20 +0200
 || Karol Kozimor <[email protected]> wrote: 

kk> I had that issue too, with 2.6.9-rc1 I s'pose, but I thought it kk> was just bug #3193 revisited and didn't really investigate. Does kk> changing swsusp2 to _not_ use ACPI S4 help?

It seems that this is not a compile-time option anymore and solely determined by /proc/software_suspend/acpi_s4_support, right?

Output of 'cat /proc/software_suspend/acpi_s4_support' is '0'.

So unless something is activating it somewhere, somehow, it seems that this _is_ with deactivated ACPI S4.

Regards,
Georg

Signature · 3 lines
Georg C. F. Greve                                       <[email protected]>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)
#7 lore raw

Hi.

Quoted 9 lines · Georg C. F. Greve
 || On Mon, 27 Sep 2004 14:33:20 +0200
 || Karol Kozimor <[email protected]> wrote: 

kk> I had that issue too, with 2.6.9-rc1 I s'pose, but I thought it kk> was just bug #3193 revisited and didn't really investigate. Does kk> changing swsusp2 to _not_ use ACPI S4 help?

It seems that this is not a compile-time option anymore and solely determined by /proc/software_suspend/acpi_s4_support, right?

That's right.

Regards,

Nigel

Signature · 7 lines
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.