> On Sunday, 30 September 2007 20:39, Alexey Starikovskiy wrote:
quoted text
> > ACPI uses acpi_get_register() in order to get into suspend.
> > This function is guarded by acpi_gbl_hardware_lock, which will be carri=
ed
quoted text
> > into resume phase.
> > At resume interrupts are enabled and first ACPI interrupt deadlocks on
> > this lock.
>
> Ouch.  That might have bitten quite some people, I guess.
>
> > Solution seems to be to not lock register read, as there are no
> > concurrent activity at this point.
> >
> > Reference: http://bugzilla.kernel.org/show_bug.cgi?id=3D7499
> >
> > Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
>
> Do you think it's -stable material?

As someone who *has* been bitten by this bug - by all means.

I'd like to emphasize one more point - we were able to debug it only becaus=
e=20
old kernel at least displayed debug messages. Current kernel deadlocks=20
absolutely dead (pun intended). No output to console, no indication what=20
happens. I consider this regression. If at all possible, we should make sur=
e=20
that console output is available as early as possible.