[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200710021759.05583.rjw@sisk.pl>
Date: Tue, 2 Oct 2007 17:59:05 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Andrey Borzenkov <arvidjaar@...l.ru>
Cc: linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend
On Tuesday, 2 October 2007 06:07, Andrey Borzenkov wrote:
> > 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.
Compile with DISABLE_CONSOLE_SUSPEND set and it should work.
There's a patch queued up for 2.6.24 that adds a command line switch for that.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists