Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend

Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend

[Alexey Starikovskiy]

Rafael J. Wysocki 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@suse.de>
> 
> Do you think it's -stable material?
Seem to be trivial.

Regards,
Alex.

Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend

[Rafael J. Wysocki]

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@suse.de>

Do you think it's -stable material?

Greetings,
Rafael


> ---
> 
>  drivers/acpi/hardware/hwsleep.c |    3 ++-
>  include/acpi/acpixf.h           |    2 ++
>  2 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
> index 4d0c677..c0577ca 100644
> --- a/drivers/acpi/hardware/hwsleep.c
> +++ b/drivers/acpi/hardware/hwsleep.c
> @@ -398,7 +398,8 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
>  	/* Wait until we enter sleep state */
>  
>  	do {
> -		status = acpi_get_register(ACPI_BITREG_WAKE_STATUS, &in_value);
> +		status = acpi_get_register_unlocked(ACPI_BITREG_WAKE_STATUS,
> +						    &in_value);
>  		if (ACPI_FAILURE(status)) {
>  			return_ACPI_STATUS(status);
>  		}
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index 3d7ab9e..9512f04 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -314,6 +314,8 @@ acpi_resource_to_address64(struct acpi_resource *resource,
>   */
>  acpi_status acpi_get_register(u32 register_id, u32 * return_value);
>  
> +acpi_status acpi_get_register_unlocked(u32 register_id, u32 *return_value);
> +
>  acpi_status acpi_set_register(u32 register_id, u32 value);
>  
>  acpi_status
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

> 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@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 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2] ACPICA: hw: Don't carry spinlock over suspend

[Rafael J. Wysocki]

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@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 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