------- Comment #29 from arvidjaar@... 2007-08-17 21:26 -------
(In reply to comment #28)
> remove inderection around acpi_os_acquire_lock()
Does not help.
(In reply to comment #25)
> - compile ACPI_DEBUG in and increase /proc/acpi/debug_level to 0x11F before
> suspend. At least last lines which AML stuff got executed shortly before
> hang might be interesting.
As soon as I set debug level console is spammed with debug output; apparently
this is some polling (battery?) I can blindly type "echo mem >
/sys/power/state" and it suspends; there is no output when it resumes.
> - The machine implements a PTS and a WAK function. Does it work if you
> out kernel code that invokes these
In this case system hangs when going to sleep :) But at least it means they are
somewhere related ...
> Do a grep DKSQ DSDT.dsl and comment out these lines in DSDT.dsl with:
Did not work either. OK I commented out only Wait ... may be I have to
completely comment out all of them - will try.
Final observation. First time I got flooded with ACPI debug messages I pressed
SysRq-B - and system stuck with
BUG: spinlock_trylock failure on UP on CPU#0, events/0/5
lock: dee8ec4c, .magic: dead4ead, .owner: kacpid/33 .owner_cpu:0
stack trace pointed on SysRq handler so it probably was not that useful. This
may be simply printk race condition of course.
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.