Bug 6176 - slab size-512: redzone mismatch - acpi_ut_allocate
Summary: slab size-512: redzone mismatch - acpi_ut_allocate
Status: REJECTED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Len Brown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-06 15:51 UTC by Len Brown
Modified: 2006-03-07 18:33 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.16-rc5 based FC5-T3
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
acpidump output for BIOS 41 (144.83 KB, application/octet-stream)
2006-03-06 15:52 UTC, Len Brown
Details

Description Len Brown 2006-03-06 15:51:04 UTC
Capell Valley CRB running BIOS 41

every 5 minutes, the console sees this:

slab size-512: redzone mismatch in slab f7d50040, obj f7d50078, bufctl 0xfffffffe
Redzone: 0x170fc2a5/0x170fc200.
Last user: [<c02063c9>](acpi_ut_allocate+0x28/0x45)
000: 53 53 44 54 fa 01 00 00 01 f9 50 6d 52 65 66 00
010: 43 70 75 30 49 73 74 00 00 30 00 00 49 4e 54 4c
Comment 1 Len Brown 2006-03-06 15:52:13 UTC
Created attachment 7518 [details]
acpidump output for BIOS 41
Comment 2 Len Brown 2006-03-06 15:53:57 UTC
Still see this in single user mode.
The 5 minute interval seems to be from the SLAB_DEBUG code:

#define REDZONETIMEOUT          (300*HZ)
Comment 3 Len Brown 2006-03-07 12:39:43 UTC
changing acpi_ut_allocate() to call kmalloc directly,
instead of via acpi_os_allocate(), and and updating
verify_slab_redzone() to dump the whole buffer, we see this:

slab size-512: redzone mismatch in slab f7d71040, obj f7d71078, bufctl 0xfffffffe
Redzone: 0x170fc2a5/0x170fc200.
Last user: [<c01f9d25>](acpi_ex_load_op+0x10c/0x267)
000: 53 53 44 54 fa 01 00 00 01 f9 50 6d 52 65 66 00
010: 43 70 75 30 49 73 74 00 00 30 00 00 49 4e 54 4c
020: 24 06 05 20 10 45 1d 5c 2e 5f 50 52 5f 43 50 55
030: 30 14 0b 5f 50 50 43 00 a4 50 50 43 53 14 47 07
040: 5f 50 43 54 00 a0 41 04 90 7b 43 46 47 44 0a 01
050: 00 7b 50 44 43 30 0a 01 00 a4 12 2c 02 11 14 0a
060: 11 82 0c 00 7f 00 00 00 00 00 00 00 00 00 00 00
070: 79 00 11 14 0a 11 82 0c 00 7f 00 00 00 00 00 00
080: 00 00 00 00 00 79 00 a4 12 2c 02 11 14 0a 11 82
090: 0c 00 01 10 00 00 b2 00 00 00 00 00 00 00 79 00
0a0: 11 14 0a 11 82 0c 00 01 08 00 00 b3 00 00 00 00
0b0: 00 00 00 79 00 14 1a 58 50 53 53 00 a0 0e 7b 50
0c0: 44 43 30 0a 01 00 a4 4e 50 53 53 a4 53 50 53 53
0d0: 08 53 50 53 53 12 46 06 03 12 20 06 0c 29 07 00
0e0: 00 0c 78 69 00 00 0c 6e 00 00 00 0c 0a 00 00 00
0f0: 0c 83 00 00 00 0c 00 00 00 00 12 20 06 0c 35 05
100: 00 00 0c 38 4a 00 00 0c 6e 00 00 00 0c 0a 00 00
110: 00 0c 83 01 00 00 0c 01 00 00 00 12 20 06 0c e8
120: 03 00 00 0c c8 32 00 00 0c 6e 00 00 00 0c 0a 00
130: 00 00 0c 83 02 00 00 0c 02 00 00 00 08 5f 50 53
140: 53 12 46 06 03 12 20 06 0c 29 07 00 00 0c 78 69
150: 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 2c 0b 00
160: 00 0c 2c 0b 00 00 12 20 06 0c 35 05 00 00 0c 38
170: 4a 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 20 08
180: 00 00 0c 20 08 00 00 12 20 06 0c e8 03 00 00 0c
190: c8 32 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 17
1a0: 06 00 00 0c 17 06 00 00 14 41 05 5f 50 53 44 00
1b0: a0 38 7b 43 46 47 44 0c 00 00 00 01 00 a0 1a 7b
1c0: 50 44 43 30 0a 20 00 a4 12 0f 01 12 0c 05 0a 05
1d0: 0a 00 0a 00 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a
1e0: 05 0a 00 0a 00 0a fe 0a 02 a4 12 0f 01 12 0c 05
1f0: 0a 05 0a 00 0a 00 0a fc 0a 01 00 00 00 00 00 00

Enabling CONFIG_ACPI_DEBUG=y makes the failure go away.

So adding some lines to print the size and address
from acpi_ex_load_op() we see this:

acpi_ex_load_op()
load from REGION f7cc3314
 lenb: table length 506
lenb: table pointer  f7d7107c
acpi_ex_load_op()
load from REGION c1bd2828
 lenb: table length 350
lenb: table pointer  f7d7fd04
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
acpi_ex_load_op()
load from REGION c1bd27f4
 lenb: table length 188
lenb: table pointer  f7d70164
acpi_ex_load_op()
load from REGION f7cc3584
 lenb: table length 133
lenb: table pointer  f7d70058

The first allocation of 506 is the buffer in question.
Looks like byes 506-512 at the end of the buffer are zero,
as expected.

Comment 4 Len Brown 2006-03-07 13:56:07 UTC
The actual slab data contents are intact.

Dumping the physical source where ACPI got the SSDT
and comparing it to the slab dumped in the dmesg
shows that they are the same, except the physical source
has other bits after byte 506 that were cleared
in the case of the slab.

# acpidump --addr 0x3f68a625 --length 0x200 |od -tx1 -Ax | tee physical
000000 53 53 44 54 fa 01 00 00 01 f9 50 6d 52 65 66 00
000010 43 70 75 30 49 73 74 00 00 30 00 00 49 4e 54 4c
000020 24 06 05 20 10 45 1d 5c 2e 5f 50 52 5f 43 50 55
000030 30 14 0b 5f 50 50 43 00 a4 50 50 43 53 14 47 07
000040 5f 50 43 54 00 a0 41 04 90 7b 43 46 47 44 0a 01
000050 00 7b 50 44 43 30 0a 01 00 a4 12 2c 02 11 14 0a
000060 11 82 0c 00 7f 00 00 00 00 00 00 00 00 00 00 00
000070 79 00 11 14 0a 11 82 0c 00 7f 00 00 00 00 00 00
000080 00 00 00 00 00 79 00 a4 12 2c 02 11 14 0a 11 82
000090 0c 00 01 10 00 00 b2 00 00 00 00 00 00 00 79 00
0000a0 11 14 0a 11 82 0c 00 01 08 00 00 b3 00 00 00 00
0000b0 00 00 00 79 00 14 1a 58 50 53 53 00 a0 0e 7b 50
0000c0 44 43 30 0a 01 00 a4 4e 50 53 53 a4 53 50 53 53
0000d0 08 53 50 53 53 12 46 06 03 12 20 06 0c 29 07 00
0000e0 00 0c 78 69 00 00 0c 6e 00 00 00 0c 0a 00 00 00
0000f0 0c 83 00 00 00 0c 00 00 00 00 12 20 06 0c 35 05
000100 00 00 0c 38 4a 00 00 0c 6e 00 00 00 0c 0a 00 00
000110 00 0c 83 01 00 00 0c 01 00 00 00 12 20 06 0c e8
000120 03 00 00 0c c8 32 00 00 0c 6e 00 00 00 0c 0a 00
000130 00 00 0c 83 02 00 00 0c 02 00 00 00 08 5f 50 53
000140 53 12 46 06 03 12 20 06 0c 29 07 00 00 0c 78 69
000150 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 2c 0b 00
000160 00 0c 2c 0b 00 00 12 20 06 0c 35 05 00 00 0c 38
000170 4a 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 20 08
000180 00 00 0c 20 08 00 00 12 20 06 0c e8 03 00 00 0c
000190 c8 32 00 00 0c 0a 00 00 00 0c 0a 00 00 00 0c 17
0001a0 06 00 00 0c 17 06 00 00 14 41 05 5f 50 53 44 00
0001b0 a0 38 7b 43 46 47 44 0c 00 00 00 01 00 a0 1a 7b
0001c0 50 44 43 30 0a 20 00 a4 12 0f 01 12 0c 05 0a 05
0001d0 0a 00 0a 00 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a
0001e0 05 0a 00 0a 00 0a fe 0a 02 a4 12 0f 01 12 0c 05
0001f0 0a 05 0a 00 0a 00 0a fc 0a 01 53 53 44 54 bc 00

diff slab physical
32c32,33
< 0001f0 0a 05 0a 00 0a 00 0a fc 0a 01 00 00 00 00 00 00
---
> 0001f0 0a 05 0a 00 0a 00 0a fc 0a 01 53 53 44 54 bc 00
> 000200
Comment 5 Dave Jones 2006-03-07 14:33:53 UTC
It's worth noting that this is popping out every five minutes as a result of the
periodic background slab checker.

http://cvs.fedora.redhat.com/viewcvs/devel/kernel/linux-2.6-debug-periodic-slab-check.patch?rev=1.3&view=markup
Comment 6 Len Brown 2006-03-07 18:33:25 UTC
Closing this bug as UNREPRODUCIBLE.

This CRB includes well-aged pre-production components, which when swapped
with slightly newer components makes the the issue vanish.

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