Bug 6549 - acpi_gbl_global_list randomly gets corroputed
Summary: acpi_gbl_global_list randomly gets corroputed
Status: REJECTED DUPLICATE of bug 6550
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Robert Moore
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-14 05:50 UTC by Luming Yu
Modified: 2006-09-28 13:22 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.16 and later
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Luming Yu 2006-05-14 05:50:08 UTC
I got a weird random NULL pointer in acpi_ut_find_allocation. My investigation 
shows that the acpi_gbl_global_list somehow got corrupted between :

exconfig.c: acpi_ex_load_op:	 table_ptr = ACPI_MEM_ALLOCATE
(table_header.length);

And

tbinstal.c : acpi_tb_init_table_descriptor:  table_desc = ACPI_MEM_CALLOCATE
(sizeof(struct acpi_table_desc));

For example:
The corrupted list had a internal node (dfef1200) with
	prev pointer == 0x0 (Wrong)
	next pointer == dff09600 
And node (dff09600) with
	prev pointer == 0x0 (Wrong) 
	next pointer == 182 (Wrong)  XXXX: This cause kernel NULL pointer 
panic.

The interesting thing is if  the value of table_ptr allocated for the first 
SSDT was larger than the successor by 0x200,
then the corresponding node for the first SSDT on the acpi_gbl_global_list 
would be corrupted. Otherwise, everything
is just ok. For example, dfe72c00 was allocated for the first SSDT, dfe72a00 
was allocated for the second SSDT,
then, I observed the node dfe72c00 corrupted.  So, it looks like the execution 
of code from 
exconfig.c: acpi_ex_load_op:	 table_ptr = ACPI_MEM_ALLOCATE
(table_header.length);
to 
 tbinstal.c : acpi_tb_init_table_descriptor:  table_desc = ACPI_MEM_CALLOCATE
(sizeof(struct acpi_table_desc));
for the second SSDT unexpectedly changed the node for the first SSDT on the 
acpi_gbl_global_list.

But, how? Or there are other tricks? 
I will debug further..., and stay tuned. 

Thanks,
Luming

ps: The following are the log for the failed and successful boot.

Failed Log
...
acpi_ex_load_op: table_ptr=dff0a228
SSDT located at dff0a228
Parsing all Control Methods:
Table [SSDT](id 0086) - 5 Objects with 0 Devices 3 Methods 0 Regions
table_header.length = 470 
acpi_ex_load_op: table_ptr=dff0a028
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0000018
6
 printing eip:
c0227068
*pde = 00000000
Oops: 0000 [#1]
SMP . 

Successful Log
...
table_header.length = 422 
acpi_ex_load_op: table_ptr=c1944028
SSDT located at c1944028
Parsing all Control Methods:
Table [SSDT](id 0086) - 5 Objects with 0 Devices 3 Methods 0 Regions
table_header.length = 470 
acpi_ex_load_op: table_ptr=c198be28
SSDT located at c198be28
Parsing all Control Methods:
Table [SSDT](id 0087) - 1 Objects with 0 Devices 1 Methods 0 Regions
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
table_header.length = 135 
acpi_ex_load_op: table_ptr=dfee67a8
SSDT located at dfee67a8
Parsing all Control Methods:
Table [SSDT](id 008B) - 3 Objects with 0 Devices 3 Methods 0 Regions
table_header.length = 133 
acpi_ex_load_op: table_ptr=dfee66a8
SSDT located at dfee66a8
Parsing all Control Methods:
Table [SSDT](id 008C) - 1 Objects with 0 Devices 1 Meth
Comment 1 Luming Yu 2006-05-14 05:54:12 UTC

*** This bug has been marked as a duplicate of 6550 ***

Note You need to log in before you can comment on or make changes to this bug.