Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[Bernard Blackham]

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

On Sat, Mar 05, 2005 at 10:44:58AM +0200, Dumitru Ciobarcianu wrote:
> ??n data de S??, 05-03-2005 la 01:50 +0800, Bernard Blackham a scris:
> > The attached patch more or less reverts the change in 2.6.9-rc1 that
> > began this all. If you have a Toshiba or other laptop that's
> > affected by this, I ask you to see if it helps your problems. (It
> > hacks around the problem rather than fixing it, but I'm not entirely
> > sure what functionality it disables).
> 
> You are on the right track , it does the trick, I did serveral
> suspend/resume cycles whitout problems. 
> 
> But (yes, it's a but :) it is functionally equivalent with using the
> other workaround (booting at resume with acpi=off) meaning that I lose
> all the acpi events (AC events, LID events, etc). The system records the
> event (if I do an "watch cat /proc/acpi/ac_adapter/ADP1/state" it shows
> the current state correctly) but acpid does not receive the event, and
> thus can not act accordingly :(  (Toshiba Satellite Pro 6100) 

Ahh, d'oh. Try this patch instead.

After more investigation, it seems that the issue is the GPE is
fired but not serviced because kacpid is frozen. This in itself
would be okay, however, the GPE isn't being disabled before the
method executes (despite there being code there to do so), and hence
fires continuously.

The attached patch makes kacpid NOFREEZE so the GPE does get
serviced (eventually), but probably still isn't the correct
solution. (A better solution being making sure the GPE gets disabled
in the first place ... still looking into this).

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>

[-- Attachment #2: toshiba-acpi-hack-2.diff --]
[-- Type: text/plain, Size: 376 bytes --]

--- linux-2.6.9-rc1/drivers/acpi/osl.c.orig	2005-03-05 17:44:13.000000000 +0800
+++ linux-2.6.9-rc1/drivers/acpi/osl.c	2005-03-05 17:44:16.000000000 +0800
@@ -87,7 +87,7 @@
 		return AE_NULL_ENTRY;
 	}
 #endif
-	kacpid_wq = create_singlethread_workqueue("kacpid", 0);
+	kacpid_wq = create_singlethread_workqueue("kacpid", PF_NOFREEZE);
 	BUG_ON(!kacpid_wq);
 
 	return AE_OK;

Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[Dumitru Ciobarcianu]

În data de Sî, 05-03-2005 la 18:02 +0800, Bernard Blackham a scris:
> Ahh, d'oh. Try this patch instead.
> 
> After more investigation, it seems that the issue is the GPE is
> fired but not serviced because kacpid is frozen. This in itself
> would be okay, however, the GPE isn't being disabled before the
> method executes (despite there being code there to do so), and hence
> fires continuously.
> 
> The attached patch makes kacpid NOFREEZE so the GPE does get
> serviced (eventually), but probably still isn't the correct
> solution. (A better solution being making sure the GPE gets disabled
> in the first place ... still looking into this).


You got it this time!
Several successful suspend/resume cycles for me! And even the events are
working! :) 

Thanks, 

-- 
Cioby




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[Pavel Machek]

Hi!

> > You are on the right track , it does the trick, I did serveral
> > suspend/resume cycles whitout problems. 
> > 
> > But (yes, it's a but :) it is functionally equivalent with using the
> > other workaround (booting at resume with acpi=off) meaning that I lose
> > all the acpi events (AC events, LID events, etc). The system records the
> > event (if I do an "watch cat /proc/acpi/ac_adapter/ADP1/state" it shows
> > the current state correctly) but acpid does not receive the event, and
> > thus can not act accordingly :(  (Toshiba Satellite Pro 6100) 
> 
> Ahh, d'oh. Try this patch instead.
> 
> After more investigation, it seems that the issue is the GPE is
> fired but not serviced because kacpid is frozen. This in itself
> would be okay, however, the GPE isn't being disabled before the
> method executes (despite there being code there to do so), and hence
> fires continuously.

Perhaps you should fix that, too? It is going to cause ugly perfrmance problems.

> The attached patch makes kacpid NOFREEZE so the GPE does get
> serviced (eventually), but probably still isn't the correct
> solution. (A better solution being making sure the GPE gets disabled
> in the first place ... still looking into this).

Looks good to me. It is good idea for other reasons, too: like we'll be
able to fight overheat during writing pages.

				Pavel
> --- linux-2.6.9-rc1/drivers/acpi/osl.c.orig	2005-03-05 17:44:13.000000000 +0800
> +++ linux-2.6.9-rc1/drivers/acpi/osl.c	2005-03-05 17:44:16.000000000 +0800
> @@ -87,7 +87,7 @@
>  		return AE_NULL_ENTRY;
>  	}
>  #endif
> -	kacpid_wq = create_singlethread_workqueue("kacpid", 0);
> +	kacpid_wq = create_singlethread_workqueue("kacpid", PF_NOFREEZE);
>  	BUG_ON(!kacpid_wq);
>  
>  	return AE_OK;


-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [ACPI] Re: Cause of Suspend2 resume failures on Toshiba laptops

[Bernard Blackham]

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

On Sat, Mar 05, 2005 at 06:56:41PM +0100, Pavel Machek wrote:
> > After more investigation, it seems that the issue is the GPE is
> > fired but not serviced because kacpid is frozen. This in itself
> > would be okay, however, the GPE isn't being disabled before the
> > method executes (despite there being code there to do so), and hence
> > fires continuously.
> 
> Perhaps you should fix that, too? It is going to cause ugly
> perfrmance problems.

Yep, been looking into it, and I think I've got it. The GPE in
question is fired periodically, about every 5 seconds. It fires when
suspending but kacpid is stopped, so the GPE is simply disabled and
never serviced. However, the state of it being disabled is recorded
in the atomic copy.

Upon resume, after restoring the atomic copy, the code at the top of
acpi_ev_disable_gpe believes that the GPE is already disabled (as it
was when we suspended) even though it's not. Hardware state is out
of sync with what the kernel thinks and badness ensues. The culprit
difference between 2.6.8 and 2.6.9-rc1 is that 2.6.8 disabled the
GPE unconditionally, 2.6.9-rc1 checks against its last known state
which is incorrect upon resuming.

Removing the check resolves this issue (patch attached). Is this an
adequate fix?

> Looks good to me. It is good idea for other reasons, too: like
> we'll be able to fight overheat during writing pages.

Fair enough. Even with kacpid running, we may still potentially run
into the same issue if a GPE occurs at the instant prior to the
atomic copy (and gets disabled in the atomic copy).

So, combining this patch with the previous kacpid NOFREEZE patch...
Does this make people happy? :) (And should it be submitted via Len
or akpm?)

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>

[-- Attachment #2: toshiba-acpi-hack-3.diff --]
[-- Type: text/plain, Size: 461 bytes --]

--- linux-2.6.9-rc1/drivers/acpi/events/evgpe.c.orig	2005-03-06 04:29:40.000000000 +0800
+++ linux-2.6.9-rc1/drivers/acpi/events/evgpe.c	2005-03-06 04:29:49.000000000 +0800
@@ -253,10 +253,6 @@
 	ACPI_FUNCTION_TRACE ("ev_disable_gpe");
 
 
-	if (!(gpe_event_info->flags & ACPI_GPE_ENABLE_MASK)) {
-		return_ACPI_STATUS (AE_OK);
-	}
-
 	/* Make sure HW enable masks are updated */
 
 	status = acpi_ev_update_gpe_enable_masks (gpe_event_info, ACPI_GPE_DISABLE);

[-- Attachment #3: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Suspend2-devel mailing list
Suspend2-devel@lists.suspend2.net
http://lists.suspend2.net/mailman/listinfo/suspend2-devel

Re: [ACPI] Re: Cause of Suspend2 resume failures on Toshiba laptops

[Pavel Machek]

Hi!

> > Perhaps you should fix that, too? It is going to cause ugly
> > perfrmance problems.
> 
> Yep, been looking into it, and I think I've got it. The GPE in
> question is fired periodically, about every 5 seconds. It fires when
> suspending but kacpid is stopped, so the GPE is simply disabled and
> never serviced. However, the state of it being disabled is recorded
> in the atomic copy.
> 
> Upon resume, after restoring the atomic copy, the code at the top of
> acpi_ev_disable_gpe believes that the GPE is already disabled (as it
> was when we suspended) even though it's not. Hardware state is out
> of sync with what the kernel thinks and badness ensues. The culprit
> difference between 2.6.8 and 2.6.9-rc1 is that 2.6.8 disabled the
> GPE unconditionally, 2.6.9-rc1 checks against its last known state
> which is incorrect upon resuming.
> 
> Removing the check resolves this issue (patch attached). Is this an
> adequate fix?

Does not removing of the check cause problems elsewhere? Bring it up
on linix-acpi lists...

Obvious solution would be to add suspend/resume routines to acpi,
and properly set the flag during resume.

> So, combining this patch with the previous kacpid NOFREEZE patch...
> Does this make people happy? :) (And should it be submitted via Len
> or akpm?)

Len.

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[John M Flinchbaugh]

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

On Sun, Mar 06, 2005 at 04:35:33AM +0800, Bernard Blackham wrote:
> So, combining this patch with the previous kacpid NOFREEZE patch...
> Does this make people happy? :) (And should it be submitted via Len
> or akpm?)
> -- 
>  Bernard Blackham <bernard at blackham dot com dot au>

> --- linux-2.6.9-rc1/drivers/acpi/events/evgpe.c.orig	2005-03-06 04:29:40.000000000 +0800
> +++ linux-2.6.9-rc1/drivers/acpi/events/evgpe.c	2005-03-06 04:29:49.000000000 +0800
> @@ -253,10 +253,6 @@
>  	ACPI_FUNCTION_TRACE ("ev_disable_gpe");
>  
>  
> -	if (!(gpe_event_info->flags & ACPI_GPE_ENABLE_MASK)) {
> -		return_ACPI_STATUS (AE_OK);
> -	}
> -
>  	/* Make sure HW enable masks are updated */
>  
>  	status = acpi_ev_update_gpe_enable_masks (gpe_event_info, ACPI_GPE_DISABLE);

I'm looking into your patches in hopes to eliminate system freezes
related to ACPI and swsusp on my Thinkpad R40.

I can apply this patch to 2.6.11.1, but the previous PF_NOFREEZE patch
won't compile.  Would you mind providing a proper patch for 2.6.11.1
that makes all the changes you intend?

Thanks.
-- 
John M Flinchbaugh
john-sQWoH1wgGpLQT0dZR+AlfA@public.gmane.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ACPI] Re: Cause of Suspend2 resume failures on Toshiba laptops

[Bernard Blackham]

On Mon, Mar 07, 2005 at 11:48:00AM -0500, John M Flinchbaugh wrote:
> On Sun, Mar 06, 2005 at 04:35:33AM +0800, Bernard Blackham wrote:
> > So, combining this patch with the previous kacpid NOFREEZE patch...
> > Does this make people happy? :) (And should it be submitted via Len
> > or akpm?)
> > -- 
> >  Bernard Blackham <bernard at blackham dot com dot au>
> 
> > --- linux-2.6.9-rc1/drivers/acpi/events/evgpe.c.orig	2005-03-06 04:29:40.000000000 +0800
> > +++ linux-2.6.9-rc1/drivers/acpi/events/evgpe.c	2005-03-06 04:29:49.000000000 +0800
> > @@ -253,10 +253,6 @@
> >  	ACPI_FUNCTION_TRACE ("ev_disable_gpe");
> >  
> >  
> > -	if (!(gpe_event_info->flags & ACPI_GPE_ENABLE_MASK)) {
> > -		return_ACPI_STATUS (AE_OK);
> > -	}
> > -
> >  	/* Make sure HW enable masks are updated */
> >  
> >  	status = acpi_ev_update_gpe_enable_masks (gpe_event_info, ACPI_GPE_DISABLE);
> 
> I'm looking into your patches in hopes to eliminate system freezes
> related to ACPI and swsusp on my Thinkpad R40.
> 
> I can apply this patch to 2.6.11.1, but the previous PF_NOFREEZE patch
> won't compile.  Would you mind providing a proper patch for 2.6.11.1
> that makes all the changes you intend?

The kacpid NOFREEZE patch is only relevant for Software Suspend 2.

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>

RE: Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[Li, Shaohua]

>
>On Sat, Mar 05, 2005 at 10:44:58AM +0200, Dumitru Ciobarcianu wrote:
>> ??n data de S??, 05-03-2005 la 01:50 +0800, Bernard Blackham a scris:
>> > The attached patch more or less reverts the change in 2.6.9-rc1
that
>> > began this all. If you have a Toshiba or other laptop that's
>> > affected by this, I ask you to see if it helps your problems. (It
>> > hacks around the problem rather than fixing it, but I'm not
entirely
>> > sure what functionality it disables).
>>
>> You are on the right track , it does the trick, I did serveral
>> suspend/resume cycles whitout problems.
>>
>> But (yes, it's a but :) it is functionally equivalent with using the
>> other workaround (booting at resume with acpi=off) meaning that I
lose
>> all the acpi events (AC events, LID events, etc). The system records
the
>> event (if I do an "watch cat /proc/acpi/ac_adapter/ADP1/state" it
shows
>> the current state correctly) but acpid does not receive the event,
and
>> thus can not act accordingly :(  (Toshiba Satellite Pro 6100)
>
>Ahh, d'oh. Try this patch instead.
>
>After more investigation, it seems that the issue is the GPE is
>fired but not serviced because kacpid is frozen. This in itself
>would be okay, however, the GPE isn't being disabled before the
>method executes (despite there being code there to do so), and hence
>fires continuously.
>
>The attached patch makes kacpid NOFREEZE so the GPE does get
>serviced (eventually), but probably still isn't the correct
>solution. (A better solution being making sure the GPE gets disabled
>in the first place ... still looking into this).
Hi,
Did you guys try the suspend method 'platform'? In this case, ACPI will
disable all non-wakeup GPEs.

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: [Suspend2-devel] Cause of Suspend2 resume failures on Toshiba laptops

[Sebastian Kügler]

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

On Tuesday 08 March 2005 10:47, Bernard Blackham wrote:
> On Tue, Mar 08, 2005 at 02:58:01PM +0800, Li, Shaohua wrote:
> > >Removing the check resolves this issue (patch attached). Is this an
> > >adequate fix?
> >
> > Great analyzing! I guess Both S3, swsusp, and swsusp2 can't suffer from
> > this bug. Sure this patch hasn't any side effect.
>
> At least one user has reported that this patch makes the battery
> status unreadable. -
> http://lists.suspend2.net/lurker/message/20050306.201243.cbbca9ea.en.html
>
> I don't know why this is the case yet, but I'd hesitate to use it
> until this is sorted out.

That's me though, who is prepared to do tests for you to resolve the issue.

Please shoot right away...

Cheers,

sebas
-- 
  http://vizZzion.org   |   GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I contend that we are both atheists. I just believe in one fewer god than you 
do. When you understand why you dismiss all the other possible gods, you will 
understand why I dismiss yours. - Sir Stephen Henry Roberts


[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]