Cause of Suspend2 resume failures on Toshiba laptops

??n data de S??, 05-03-2005 la 01:50 +0800, Bernard Blackham a scris:

Quoted 5 lines

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

Quoted 9 lines

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

drivers/acpi/osl.c renamed from drivers/acpi/osl.c.orig +1 -1

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

Quoted 5 lines

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.

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

Quoted 2 lines

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?

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

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

Signature · 1 line

 Bernard Blackham <bernard at blackham dot com dot au>

Quoted 18 lines · Bernard Blackham

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

Signature · 1 line

 Bernard Blackham <bernard at blackham dot com dot au>

drivers/acpi/events/evgpe.c renamed from drivers/acpi/events/evgpe.c.orig +0 -4

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

drivers/acpi/events/evgpe.c line 258

Quoted 1 line

drivers/acpi/events/evgpe.c renamed from drivers/acpi/events/evgpe.c.orig +0 -0

 	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?