Skip to contentSkip to conversation

Avoid slab errors on suspend

PATH Thomas Renninger 2 participants 3 messages Mar 8, 2006 ACPI

lore
Share & tools
lore
#0 lore raw

When going into suspend irqs must be disabled for a long time.

There is already a acpi_in_resume variable in osl.c to not make use of sleeping functions (mem allocs/mutexes). This one just makes a bit more intensive use of it.

The acpi_in_resume seem to vanish later (pci_link.c):
/*
* FIXME: this is a workaround to avoid nasty warning. It will be removed
* after every device calls pci_disable_device in .resume.
*/
but for now below patch seem to be needed:

Subject: No GFP_KERNEL buffer alloc or mutexes if resuming

 drivers/acpi/osl.c   |   10 +++++++---
 drivers/acpi/utils.c |    6 +++++-
 2 files changed, 12 insertions(+), 4 deletions(-)
drivers/acpi/osl.c +7 -3
Index: linux-2.6.15/drivers/acpi/osl.c
===================================================================
@@ -880,7 +880,7 @@ acpi_status acpi_os_wait_semaphore(acpi_
 	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "Waiting for semaphore[%p|%d|%d]\n",
 			  handle, units, timeout));
 
-	if (in_atomic())
+	if (in_atomic() || acpi_in_resume)
 		timeout = 0;
 
 	switch (timeout) {
@@ -1009,7 +1009,7 @@ u8 acpi_os_writable(void *ptr, acpi_size
 
 u32 acpi_os_get_thread_id(void)
 {
-	if (!in_atomic())
+	if (!in_atomic() && !acpi_in_resume)
 		return current->pid;
 
 	return 0;
@@ -1252,7 +1252,11 @@ acpi_status acpi_os_release_object(acpi_
 
 void *acpi_os_acquire_object(acpi_cache_t * cache)
 {
-	void *object = kmem_cache_alloc(cache, GFP_KERNEL);
+	void *object;
+	if (acpi_in_resume)
+		object = kmem_cache_alloc(cache, GFP_ATOMIC);
+	else
+		object = kmem_cache_alloc(cache, GFP_KERNEL);
 	WARN_ON(!object);
 	return object;
 }
drivers/acpi/utils.c +5 -1
Index: linux-2.6.15/drivers/acpi/utils.c
===================================================================
@@ -250,6 +250,7 @@ acpi_extract_package(union acpi_object *
 
 EXPORT_SYMBOL(acpi_extract_package);
 
+extern int acpi_in_resume;
 acpi_status
 acpi_evaluate_integer(acpi_handle handle,
 		      acpi_string pathname,
@@ -264,7 +265,10 @@ acpi_evaluate_integer(acpi_handle handle
 	if (!data)
 		return_ACPI_STATUS(AE_BAD_PARAMETER);
 
-	element = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
+	if (acpi_in_resume)
+		element = kmalloc(sizeof(union acpi_object), GFP_ATOMIC);
+	else
+		element = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
 	if (!element)
 		return_ACPI_STATUS(AE_NO_MEMORY);
 
#1 lore raw
Quoted 2 lines · Thomas Renninger

When going into suspend irqs must be disabled for a long time.

Mine is very similar to recently posted:
[patch 16/22] acpi_os_acquire_object (GFP_KERNEL) called with IRQs disabled through suspend-resume

Hmm, but on my machine "acpi_os_derive_pci_id_2" is also invoked, calling "acpi_evaluate_integer" in utils.c that also has a GFP_KERNEL call.

Davi, maybe it's best if you post the second part of your patch (which is part of the ACPICA?) directly to Len/Robert.

Mine includes the first part of yours and adds some additional acpi_in_resume checks that seem to be necessary on some machines.

Thomas

#2 lore raw
Quoted 6 lines · Thomas Renninger
Quoted 2 lines · Thomas Renninger

When going into suspend irqs must be disabled for a long time.

Mine is very similar to recently posted:
[patch 16/22] acpi_os_acquire_object (GFP_KERNEL) called with IRQs disabled through suspend-resume

Quoted 8 lines

Hmm, but on my machine "acpi_os_derive_pci_id_2" is also invoked, calling "acpi_evaluate_integer" in utils.c that also has a GFP_KERNEL call.

Davi, maybe it's best if you post the second part of your patch (which is part of the ACPICA?) directly to Len/Robert.

Mine includes the first part of yours and adds some additional acpi_in_resume checks that seem to be necessary on some machines.

If you want to workaround such issue, maybe we should change system_state to !SYSTEM_RUNNING at the begining of irqrouter_resume' and restore it at the end of this routine. This should solve all such issues.

Thanks,
Shaohua