[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200710020807.41325.arvidjaar@mail.ru>
Date: Tue, 2 Oct 2007 08:07:36 +0400
From: Andrey Borzenkov <arvidjaar@...l.ru>
To: "Rafael J. Wysocki" <rjw@...k.pl>, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend
> On Sunday, 30 September 2007 20:39, Alexey Starikovskiy wrote:
> > ACPI uses acpi_get_register() in order to get into suspend.
> > This function is guarded by acpi_gbl_hardware_lock, which will be carried
> > 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=7499
> >
> > Signed-off-by: Alexey Starikovskiy <astarikovskiy@...e.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 because
old kernel at least displayed debug messages. Current kernel deadlocks
absolutely dead (pun intended). No output to console, no indication what
happens. I consider this regression. If at all possible, we should make sure
that console output is available as early as possible.
Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists