some new unaligned access while booting ia64 (HP rx2620)

some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

Booting a snapshot of Linus' tree this morning I saw a few (new?)
kernel unaligned access warnings:

ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
ACPI: PCI Root Bridge [PCI1] (0000:20)

The first three at ip=0xa0000001003af8c0 are in acpi_rs_get_resource_source()
while zeroing a 64-bit value:
a0000001003af8c0:       dc 00 00 46 98 11       [MFB] (p06) st8 [r35]=r0

Which looks from the assembly code like we are doing a:
   resource_source->string_ptr = 0;
but I don't see anything quite like that in the C source (but
there may be macros & inlining happening).

The other two, ip=0xa0000001003ae6c1 and ip=0xa0000001003ae6d1 are in
acpi_resource_to_address64() close together in this little
block:

a0000001003ae6c6:       50 02 58 30 20 00                   ld8 r37=[r22]
a0000001003ae6cc:       00 00 00 20                         nop.b 0x0;;
a0000001003ae6d0:       19 00 94 1e 98 11       [MMB]       st8 [r15]=r37
a0000001003ae6d6:       70 02 40 30 20 00                   ld8 r39=[r16]

These loads are dereferencing the acpi_resource structure that was passed
as the first argument (offsets 40 and 48 bytes).

-Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

The ACPICA resource manager was mostly rewritten around the 20051021
time frame, and we may have disturbed some of the aligned access
support. I'll look at these, it looks like enough info to fix them.

Thanks,
Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Luck, Tony
> Sent: Thursday, February 02, 2006 11:46 AM
> To: linux-acpi@vger.kernel.org
> Cc: linux-ia64@vger.kernel.org
> Subject: some new unaligned access while booting ia64 (HP rx2620)
> 
> Booting a snapshot of Linus' tree this morning I saw a few (new?)
> kernel unaligned access warnings:
> 
> ACPI: Subsystem revision 20060127
> ACPI: Interpreter enabled
> ACPI: Using IOSAPIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
> kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
> ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> ACPI: PCI Root Bridge [PCI1] (0000:20)
> 
> The first three at ip=0xa0000001003af8c0 are in
> acpi_rs_get_resource_source()
> while zeroing a 64-bit value:
> a0000001003af8c0:       dc 00 00 46 98 11       [MFB] (p06) st8
[r35]=r0
> 
> Which looks from the assembly code like we are doing a:
>    resource_source->string_ptr = 0;
> but I don't see anything quite like that in the C source (but
> there may be macros & inlining happening).
> 
> The other two, ip=0xa0000001003ae6c1 and ip=0xa0000001003ae6d1 are in
> acpi_resource_to_address64() close together in this little
> block:
> 
> a0000001003ae6c6:       50 02 58 30 20 00                   ld8
r37=[r22]
> a0000001003ae6cc:       00 00 00 20                         nop.b
0x0;;
> a0000001003ae6d0:       19 00 94 1e 98 11       [MMB]       st8
[r15]=r37
> a0000001003ae6d6:       70 02 40 30 20 00                   ld8
r39=[r16]
> 
> These loads are dereferencing the acpi_resource structure that was
passed
> as the first argument (offsets 40 and 48 bytes).
> 
> -Tony
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

I'm wondering if the resource structures are being inadvertently packed.

You might try removing this code from actypes.h:

/*
 * If possible, pack the following structures to byte alignment
 */
#ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
#pragma pack(1)
#endif

Please send the dsdt or acpidump for this machine
Thanks,
Bob



> -----Original Message-----
> From: Moore, Robert
> Sent: Thursday, February 02, 2006 2:29 PM
> To: Luck, Tony; linux-acpi@vger.kernel.org
> Cc: linux-ia64@vger.kernel.org
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> The ACPICA resource manager was mostly rewritten around the 20051021
time
> frame, and we may have disturbed some of the aligned access support.
I'll
> look at these, it looks like enough info to fix them.
> 
> Thanks,
> Bob
> 
> 
> > -----Original Message-----
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Luck, Tony
> > Sent: Thursday, February 02, 2006 11:46 AM
> > To: linux-acpi@vger.kernel.org
> > Cc: linux-ia64@vger.kernel.org
> > Subject: some new unaligned access while booting ia64 (HP rx2620)
> >
> > Booting a snapshot of Linus' tree this morning I saw a few (new?)
> > kernel unaligned access warnings:
> >
> > ACPI: Subsystem revision 20060127
> > ACPI: Interpreter enabled
> > ACPI: Using IOSAPIC for interrupt routing
> > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
> > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
> > ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> > ACPI: PCI Root Bridge [PCI1] (0000:20)
> >
> > The first three at ip=0xa0000001003af8c0 are in
> > acpi_rs_get_resource_source()
> > while zeroing a 64-bit value:
> > a0000001003af8c0:       dc 00 00 46 98 11       [MFB] (p06) st8
[r35]=r0
> >
> > Which looks from the assembly code like we are doing a:
> >    resource_source->string_ptr = 0;
> > but I don't see anything quite like that in the C source (but
> > there may be macros & inlining happening).
> >
> > The other two, ip=0xa0000001003ae6c1 and ip=0xa0000001003ae6d1 are
in
> > acpi_resource_to_address64() close together in this little
> > block:
> >
> > a0000001003ae6c6:       50 02 58 30 20 00                   ld8
> r37=[r22]
> > a0000001003ae6cc:       00 00 00 20                         nop.b
0x0;;
> > a0000001003ae6d0:       19 00 94 1e 98 11       [MMB]       st8
> [r15]=r37
> > a0000001003ae6d6:       70 02 40 30 20 00                   ld8
> r39=[r16]
> >
> > These loads are dereferencing the acpi_resource structure that was
> passed
> > as the first argument (offsets 40 and 48 bytes).
> >
> > -Tony
> > -
> > To unsubscribe from this list: send the line "unsubscribe
linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

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

> You might try removing this code from actypes.h:
> 
> /*
>  * If possible, pack the following structures to byte alignment
>  */
> #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
> #pragma pack(1)
> #endif

Either this made things worse, or other changes in the base since
my last test made things worse ... after rebuilding with those lines
deleted my kernel got less far.  Last messages were:

   Initial ramdisk at: 0xe00000003e43b000 (1303588 bytes)
   SAL 3.1: HP version 2.21
   SAL Platform features: None

> Please send the dsdt or acpidump for this machine

/proc/acpi/dsdt attached.

-Tony

[-- Attachment #2: dsdt --]
[-- Type: application/octet-stream, Size: 22401 bytes --]

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

Well, we need to know which it was.

The alignment stuff is based upon __IA64__ or __ia64__, make sure one of
these is set.


/*
 * In the case of the Itanium Processor Family (IPF), the hardware does
not
 * support misaligned memory transfers. Set the
MISALIGNMENT_NOT_SUPPORTED flag
 * to indicate that special precautions must be taken to avoid alignment
faults.
 * (IA64 or ia64 is currently used by existing compilers to indicate
IPF.)
 *
 * Note: EM64T and other X86-64 processors support misaligned transfers,
 * so there is no need to define this flag.
 */
#if defined (__IA64__) || defined (__ia64__)
#define ACPI_MISALIGNMENT_NOT_SUPPORTED
#endif


> -----Original Message-----
> From: Luck, Tony
> Sent: Thursday, February 09, 2006 12:45 PM
> To: Moore, Robert; 'linux-acpi@vger.kernel.org'
> Cc: 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> > You might try removing this code from actypes.h:
> >
> > /*
> >  * If possible, pack the following structures to byte alignment
> >  */
> > #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
> > #pragma pack(1)
> > #endif
> 
> Either this made things worse, or other changes in the base since
> my last test made things worse ... after rebuilding with those lines
> deleted my kernel got less far.  Last messages were:
> 
>    Initial ramdisk at: 0xe00000003e43b000 (1303588 bytes)
>    SAL 3.1: HP version 2.21
>    SAL Platform features: None
> 
> > Please send the dsdt or acpidump for this machine
> 
> /proc/acpi/dsdt attached.
> 
> -Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

> The alignment stuff is based upon __IA64__ or __ia64__, make sure one
of these is set.

__ia64__ is set

-Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

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

But I goofed and muddled up my two problems.  I tried
booting on my zx1 ... which was broken altogether by
recent acpi changes.

Getting back to the rx2620 ... deleting those lines makes
no difference.  I still boot ok, I still see the unaligned
access messages.

/proc/acpi/dsdt for that system attached.

-Tony

[-- Attachment #2: dtdt.rx2620 --]
[-- Type: application/octet-stream, Size: 24380 bytes --]

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

The next thing that would be useful is to know what method(s) are
executing when the message pops out.


> -----Original Message-----
> From: Luck, Tony
> Sent: Thursday, February 09, 2006 1:16 PM
> To: Moore, Robert; 'linux-acpi@vger.kernel.org'
> Cc: 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> But I goofed and muddled up my two problems.  I tried
> booting on my zx1 ... which was broken altogether by
> recent acpi changes.
> 
> Getting back to the rx2620 ... deleting those lines makes
> no difference.  I still boot ok, I still see the unaligned
> access messages.
> 
> /proc/acpi/dsdt for that system attached.
> 
> -Tony

Re: some new unaligned access while booting ia64 (HP rx2620)

[Thomas Renninger]

Moore, Robert wrote:
> The next thing that would be useful is to know what method(s) are
> executing when the message pops out.
> 
> 
>> -----Original Message-----
>> From: Luck, Tony
>> Sent: Thursday, February 09, 2006 1:16 PM
>> To: Moore, Robert; 'linux-acpi@vger.kernel.org'
>> Cc: 'linux-ia64@vger.kernel.org'
>> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
>>
>> But I goofed and muddled up my two problems.  I tried
>> booting on my zx1 ... which was broken altogether by
>> recent acpi changes.
>>
>> Getting back to the rx2620 ... deleting those lines makes
>> no difference.  I still boot ok, I still see the unaligned
>> access messages.
>>
>> /proc/acpi/dsdt for that system attached.
>>
>> -Tony

I also got kernel missalignment errors..., unfortunately also
a lot of slab debugger errors until the machine rebooted, so
I didn't care too much about the missalignments, but these
could have the same cause?

I now could nail the mem
corruptions down to ACPICA-20051021 by binary search.
It's late, maybe I got something wrong, but I am quite sure the
culprit lies there.

The patch is huge, but maybe it's just one of the other pragmas or
whatever related?:

grep pragma ../ACPICA_20051021.patch
+#pragma pack(1)
+#pragma pack()
+#pragma pack(1)
+#pragma pack()


     Thomas

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

When the resource descriptor list (ResourceTemplate) is extracted from
the raw AML byte stream, it is converted and expanded to an internal
format that is easier for the drivers to interpret. For IA64, this
includes alignment of the various structs on 64-bit boundaries.

I suspect that the recent restructuring of the Resource Manager code may
have broken some of the alignment support. Obviously, we don't see any
issues on the 32-bit machines. 

What I need is to know exactly what control method has executed and what
resource descriptor is being processed when the alignment fault(s)
occur. 

Enabling debugging in the ACPI subsystem will certainly give this
information. AcpiDebugLevel = 0x00FFFFFF works nicely, although a lot of
trace info is produced. You can tweak the number above to get just the
info you need, or enable/disable debugging around a particular piece of
code, such as in a driver that is calling the ACPI subsystem to get the
resource descriptor template.

Also, the length of the target buffer for the resource descriptors is
calculated taking alignment issues into account. If this is out of sync
with the code that actually populates the buffer, the buffer can be
overrun.

Bob


> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Thursday, February 09, 2006 6:08 PM
> To: Moore, Robert
> Cc: Luck, Tony; linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org
> Subject: Re: some new unaligned access while booting ia64 (HP rx2620)
> 
> Moore, Robert wrote:
> > The next thing that would be useful is to know what method(s) are
> > executing when the message pops out.
> >
> >
> >> -----Original Message-----
> >> From: Luck, Tony
> >> Sent: Thursday, February 09, 2006 1:16 PM
> >> To: Moore, Robert; 'linux-acpi@vger.kernel.org'
> >> Cc: 'linux-ia64@vger.kernel.org'
> >> Subject: RE: some new unaligned access while booting ia64 (HP
rx2620)
> >>
> >> But I goofed and muddled up my two problems.  I tried
> >> booting on my zx1 ... which was broken altogether by
> >> recent acpi changes.
> >>
> >> Getting back to the rx2620 ... deleting those lines makes
> >> no difference.  I still boot ok, I still see the unaligned
> >> access messages.
> >>
> >> /proc/acpi/dsdt for that system attached.
> >>
> >> -Tony
> 
> I also got kernel missalignment errors..., unfortunately also
> a lot of slab debugger errors until the machine rebooted, so
> I didn't care too much about the missalignments, but these
> could have the same cause?
> 
> I now could nail the mem
> corruptions down to ACPICA-20051021 by binary search.
> It's late, maybe I got something wrong, but I am quite sure the
> culprit lies there.
> 
> The patch is huge, but maybe it's just one of the other pragmas or
> whatever related?:
> 
> grep pragma ../ACPICA_20051021.patch
> +#pragma pack(1)
> +#pragma pack()
> +#pragma pack(1)
> +#pragma pack()
> 
> 
>      Thomas

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

> Enabling debugging in the ACPI subsystem will certainly give this
> information. AcpiDebugLevel = 0x00FFFFFF works nicely, although
> a lot of trace info is produced.

There is no AcpiDebugLevel in the Linux kernel.  I did find a
variable "acpidbg_level" ... so I set CONFIG_ACPI_DEBUG=y and
added
	acpi_dbg_level = 0x00FFFFFF;
at the start of init/main.c/start_kernel()

But then my system didn't boot at all :-(

Tried again w/o the "acpi_dbg_level = 0x00FFFFFF;", and that didn't
boot either.  So there is something bad in the CONFIG_ACPI_DEBUG
code.

-Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

Yes, In linux everything gets converted to lower case, sorry.

The debug trace mechanism is known to work, I hope it isn't broken on
IA64. 

Does any debug info come out?

Bob


> -----Original Message-----
> From: Luck, Tony
> Sent: Friday, February 10, 2006 1:16 PM
> To: Moore, Robert; 'Thomas Renninger'
> Cc: 'linux-acpi@vger.kernel.org'; 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> > Enabling debugging in the ACPI subsystem will certainly give this
> > information. AcpiDebugLevel = 0x00FFFFFF works nicely, although
> > a lot of trace info is produced.
> 
> There is no AcpiDebugLevel in the Linux kernel.  I did find a
> variable "acpidbg_level" ... so I set CONFIG_ACPI_DEBUG=y and
> added
> 	acpi_dbg_level = 0x00FFFFFF;
> at the start of init/main.c/start_kernel()
> 
> But then my system didn't boot at all :-(
> 
> Tried again w/o the "acpi_dbg_level = 0x00FFFFFF;", and that didn't
> boot either.  So there is something bad in the CONFIG_ACPI_DEBUG
> code.
> 
> -Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

>Does any debug info come out?

Perhaps I was too impatient ... I just assumed it was hung
because it hadn't said anything for a minute after the
"Loading initrd" message.  When I came back to the console
all sorts of messages were streaming past.

I restarted ... the delay is ~10 minutes, the the output
begins not with the regular kernel messages, but with this:

 Storing e00000407f4bd108(Integer) into node
e00000407e8e9a30(BufferField)
exstoren-0075 [18] ex_resolve_object     : ----Entry
exstoren-0155 [18] ex_resolve_object     : ----Exit- AE_OK
 exfield-0222 [18] ex_write_data_to_field: ----Entry e00000407efa7dc0
 exfield-0354 [18] ex_write_data_to_field: field_write [FROM]: Obj
e00000407f4bd108 (Integer:1), Buf e00000407f4bd120, byte_len 8
 exfield-0363 [18] ex_write_data_to_field: field_write [TO]:  Obj
e00000407efa7dc0 (BufferField:E), bit_len 20, bit_off 0, byte_off 13
 exutils-0192 [19] ex_acquire_global_lock: ----Entry
 exutils-0208 [19] ex_acquire_global_lock: ----Exit- 0000000000000000
 exfldio-0783 [19] ex_insert_into_field  : ----Entry
 exfldio-0562 [20] ex_write_with_update_r: ----Entry FFFFFFFF
 exfldio-0631 [20] ex_write_with_update_r: Mask FFFFFFFFFFFFFFFF,
datum_offset 0, Width 4, Value 00000000FF5E0000, merged_value
00000000FF5E0000
 exfldio-0355 [21] ex_field_datum_io     : ----Entry 00000000
 exfldio-0530 [21] ex_field_datum_io     : Value Written
00000000FF5E0000, Width 4
 exfldio-0534 [21] ex_field_datum_io     : ----Exit- AE_OK

It is unclear whether the system is making progress.



I tried using CONFIG_ACPI_DEBUG=y on an Intel tiger.  It booted ok.


-Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

That looks good. You'll probably need to increase your dmesg buffer or
send the output to a serial port, since you will get megabytes of info.

Zip it up and send it to me.


> -----Original Message-----
> From: Luck, Tony
> Sent: Friday, February 10, 2006 1:54 PM
> To: Moore, Robert; 'Thomas Renninger'; Brown, Len
> Cc: 'linux-acpi@vger.kernel.org'; 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> >Does any debug info come out?
> 
> Perhaps I was too impatient ... I just assumed it was hung
> because it hadn't said anything for a minute after the
> "Loading initrd" message.  When I came back to the console
> all sorts of messages were streaming past.
> 
> I restarted ... the delay is ~10 minutes, the the output
> begins not with the regular kernel messages, but with this:
> 
>  Storing e00000407f4bd108(Integer) into node
e00000407e8e9a30(BufferField)
> exstoren-0075 [18] ex_resolve_object     : ----Entry
> exstoren-0155 [18] ex_resolve_object     : ----Exit- AE_OK
>  exfield-0222 [18] ex_write_data_to_field: ----Entry e00000407efa7dc0
>  exfield-0354 [18] ex_write_data_to_field: field_write [FROM]: Obj
> e00000407f4bd108 (Integer:1), Buf e00000407f4bd120, byte_len 8
>  exfield-0363 [18] ex_write_data_to_field: field_write [TO]:  Obj
> e00000407efa7dc0 (BufferField:E), bit_len 20, bit_off 0, byte_off 13
>  exutils-0192 [19] ex_acquire_global_lock: ----Entry
>  exutils-0208 [19] ex_acquire_global_lock: ----Exit- 0000000000000000
>  exfldio-0783 [19] ex_insert_into_field  : ----Entry
>  exfldio-0562 [20] ex_write_with_update_r: ----Entry FFFFFFFF
>  exfldio-0631 [20] ex_write_with_update_r: Mask FFFFFFFFFFFFFFFF,
> datum_offset 0, Width 4, Value 00000000FF5E0000, merged_value
> 00000000FF5E0000
>  exfldio-0355 [21] ex_field_datum_io     : ----Entry 00000000
>  exfldio-0530 [21] ex_field_datum_io     : Value Written
00000000FF5E0000,
> Width 4
>  exfldio-0534 [21] ex_field_datum_io     : ----Exit- AE_OK
> 
> It is unclear whether the system is making progress.
> 
> 
> 
> I tried using CONFIG_ACPI_DEBUG=y on an Intel tiger.  It booted ok.
> 
> 
> -Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

> That looks good. You'll probably need to increase your dmesg buffer
> or send the output to a serial port, since you will get megabytes
> of info.

I only have a serial port on this machine ... but all the interesting
output happens before it is enabled ... i.e. is buffered up in log_buf
until the serial console is brought online.

I made log_buf as big as I could (2^21 bytes is the biggest it would
let me go), and that is not enough for all the ACPI messages ... so the
initial part where the unaligned messages were printed was lost in the
wraparound before anything could be dumped to the serial port.

Now I've got network problems in the lab ... when I can reconnect to
my systems, I'll change lib/Kconfig.debug to allow a bigger log_buf
and try again.

-Tony

Re: some new unaligned access while booting ia64 (HP rx2620)

[Bjorn Helgaas]

On Friday 10 February 2006 15:58, Luck, Tony wrote:
> > That looks good. You'll probably need to increase your dmesg buffer
> > or send the output to a serial port, since you will get megabytes
> > of info.
> 
> I only have a serial port on this machine ... but all the interesting
> output happens before it is enabled ... i.e. is buffered up in log_buf
> until the serial console is brought online.

This is because when you use "console=ttyS0", we can't use that
console until we know which device will be "ttyS0".  We learn
that when the serial driver discovers the devices, which is
fairly late.  (Most other architectures have hard-coded "ttyS0
is at I/O port 0x3f8" assumptions, which lets them start the
console earlier.)

But since you have an HP box with an HCDP, you can remove the
"console=ttyS0" argument (after making sure that you have only
the desired port enabled for EFI console output).  In this case,
the HCDP table tells us the port address, so we can enable the
console very early.

Alternatively, you can use "console=uart,mmio,0x<address>", which
will also work very early.  This works on any  box, since it doesn't
depend on the HCDP, but you do have to figure out the UART address
(it's printed when the serial driver discovers the port).

Bjorn

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

You may need to selectively enable/disable the debug trace during a
particular call.

I suspect that the problem is happening during the execution of the
ACPICA interface AcpiSetCurrentResources (aka
acpi_set_current_resources).

Here's the way I would do it:

Set a breakpoint on acpi_set_current_resources. When you get there,
enable debug output. When finished, disable debugging.

If this isn't possible with your debugger, you can always change the
source to enable/disable debugging at the start and end of
acpi_set_current_resources.

Bob


> -----Original Message-----
> From: Luck, Tony
> Sent: Friday, February 10, 2006 2:59 PM
> To: Moore, Robert; 'Thomas Renninger'; Brown, Len
> Cc: 'linux-acpi@vger.kernel.org'; 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> > That looks good. You'll probably need to increase your dmesg buffer
> > or send the output to a serial port, since you will get megabytes
> > of info.
> 
> I only have a serial port on this machine ... but all the interesting
> output happens before it is enabled ... i.e. is buffered up in log_buf
> until the serial console is brought online.
> 
> I made log_buf as big as I could (2^21 bytes is the biggest it would
> let me go), and that is not enough for all the ACPI messages ... so
the
> initial part where the unaligned messages were printed was lost in the
> wraparound before anything could be dumped to the serial port.
> 
> Now I've got network problems in the lab ... when I can reconnect to
> my systems, I'll change lib/Kconfig.debug to allow a bigger log_buf
> and try again.
> 
> -Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

It could be either

acpi_set_current_resources or
acpi_get_current_resources



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Friday, February 10, 2006 3:07 PM
> To: Luck, Tony; Thomas Renninger; Brown, Len
> Cc: linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> You may need to selectively enable/disable the debug trace during a
> particular call.
> 
> I suspect that the problem is happening during the execution of the
> ACPICA interface AcpiSetCurrentResources (aka
> acpi_set_current_resources).
> 
> Here's the way I would do it:
> 
> Set a breakpoint on acpi_set_current_resources. When you get there,
> enable debug output. When finished, disable debugging.
> 
> If this isn't possible with your debugger, you can always change the
> source to enable/disable debugging at the start and end of
> acpi_set_current_resources.
> 
> Bob
> 
> 
> > -----Original Message-----
> > From: Luck, Tony
> > Sent: Friday, February 10, 2006 2:59 PM
> > To: Moore, Robert; 'Thomas Renninger'; Brown, Len
> > Cc: 'linux-acpi@vger.kernel.org'; 'linux-ia64@vger.kernel.org'
> > Subject: RE: some new unaligned access while booting ia64 (HP
rx2620)
> >
> > > That looks good. You'll probably need to increase your dmesg
buffer
> > > or send the output to a serial port, since you will get megabytes
> > > of info.
> >
> > I only have a serial port on this machine ... but all the
interesting
> > output happens before it is enabled ... i.e. is buffered up in
log_buf
> > until the serial console is brought online.
> >
> > I made log_buf as big as I could (2^21 bytes is the biggest it would
> > let me go), and that is not enough for all the ACPI messages ... so
> the
> > initial part where the unaligned messages were printed was lost in
the
> > wraparound before anything could be dumped to the serial port.
> >
> > Now I've got network problems in the lab ... when I can reconnect to
> > my systems, I'll change lib/Kconfig.debug to allow a bigger log_buf
> > and try again.
> >
> > -Tony
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

A 16MB log_buf was enough.

Here is the initial trace up until the unaligned access messages:

Linux version 2.6.16-rc2-zx1-smp (aegl@linux-t10) (gcc version 3.4.3
20050227 (Red Hat 3.4.3-22.1)) #7 SMP Fri Feb 10 15:17:06 PST 2006
EFI v1.10 by HP: SALsystab=0x3fefa000 ACPI 2.0=0x3fd5e000
SMBIOS=0x3fefc000 HCDP=0x3fd5c000
PCDP: v0 at 0x3fd5c000
Explicit "console="; ignoring PCDP
warning: skipping physical page 0
Initial ramdisk at: 0xe00000407ee5b000 (1303589 bytes)
SAL 3.1: HP version 3.15
SAL Platform features: None
SAL: AP wakeup using external interrupt vector 0xff
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
GSI 36 (level, low) -> CPU 0 (0x0000) vector 48
2 CPUs available, 2 CPUs total
MCA related initialization done
Virtual mem_map starts at 0xa0007fffc7900000
Built 1 zonelists
Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-zx1-smp.gz
console=ttyS0 root=LABEL=/ ro
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 7, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 6, 1048576 bytes)
Memory: 2041632k/2086064k available (8308k code, 43248k reserved, 3585k
data, 272k init)
McKinley Errata 9 workaround not needed; disabling it
Mount-cache hash table entries: 1024
 tbxface-0109 [02] load_tables           : ACPI Tables successfully
acquired
Parsing all Control Methods:
Table [DSDT](id 000D) - 158 Objects with 11 Devices 106 Methods 0
Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 13 Objects with 1 Devices 9 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0005) - 29 Objects with 3 Devices 23 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0006) - 69 Objects with 9 Devices 41 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0007) - 69 Objects with 9 Devices 41 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0008) - 69 Objects with 9 Devices 41 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 0009) - 69 Objects with 9 Devices 41 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 000A) - 7 Objects with 0 Devices 5 Methods 0 Regions
Parsing all Control Methods:
Table [SSDT](id 000B) - 7 Objects with 0 Devices 5 Methods 0 Regions
ACPI Namespace successfully loaded at root a000000101bb41e0
evxfevnt-0079 [03] enable                : System is already in ACPI
mode
Boot processor id 0x0/0x0
CPU 1: synchronized ITC with CPU 0 (last diff -2 cycles, maxerr 554
cycles)
Brought up 2 CPUs
Total of 2 processors activated (3891.20 BogoMIPS).
migration_cost225
checking if image is initramfs... it is
Freeing initrd memory: 1264kB freed
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Subsystem revision 20060127
evgpeblk-0941 [06] ev_create_gpe_block   : GPE 00 to 0F [_GPE] 2 regs on
int 0x24
evgpeblk-0941 [06] ev_create_gpe_block   : GPE 10 to 1F [_GPE] 2 regs on
int 0x24
evgpeblk-1037 [05] ev_initialize_gpe_bloc: Found 0 Wake, Enabled 0
Runtime GPEs in this block
evgpeblk-1037 [05] ev_initialize_gpe_bloc: Found 0 Wake, Enabled 1
Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:.
Initialized 0/0 Regions 0/0 Fields 0/0 Buffers 1/1 Packages (499 nodes)
Executing all Device _STA and_INI methods:..[ACPI Debug]  String: [0x04]
"_INI"
[ACPI Debug]  String: [0x1E] "Pointer And Rev are Not valid
"
[ACPI Debug]  String: [0x29] "Initializing the SCRAM data struct access"
[ACPI Debug]  String: [0x0E] "Executing GFIT"
[ACPI Debug]  String: [0x1D] "Init of scratch RAM complete!"
......................................................
56 Devices found - executed 0 _STA, 1 _INI methods
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
[ACPI Debug]  String: [0x0A] "CLIB.SBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000002
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Sba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Sba Ptr is "
[ACPI Debug]  Integer: 0x3FEF8070
[ACPI Debug]  String: [0x0A] "CLIB.BMC 2"
[ACPI Debug]  Integer: 0x00000002
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000005
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting BMC Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "BMC Ptr is "
[ACPI Debug]  Integer: 0x3FEF8020
[ACPI Debug]  String: [0x0A] "CLIB.BMC 2"
[ACPI Debug]  Integer: 0x00000002
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000005
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting BMC Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "BMC Ptr is "
[ACPI Debug]  Integer: 0x3FEF8020
[ACPI Debug]  String: [0x06] "_STA 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
[ACPI Debug]  String: [0x06] "_HID 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
[ACPI Debug]  String: [0x06] "_STA 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
[ACPI Debug]  String: [0x06] "_BBN 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
ACPI: PCI Root Bridge [PCI0] (0000:00)
[ACPI Debug]  String: [0x06] "_CRS 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000003
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1A] "PARS.GPTR: Getting Lba Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP3"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "Lba Ptr is "
[ACPI Debug]  Integer: 0x3FEF81E0
[ACPI Debug]  String: [0x18] "Assert will not go fatal"
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000006
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x21] "PARS.GPTR: Getting SERIAL DEV Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x12] "SERIAL DEV Ptr is "
[ACPI Debug]  Integer: 0x3FEF9980
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"
[ACPI Debug]  Integer: 0x00000006
[ACPI Debug]  Integer: 0x00010000
[ACPI Debug]  String: [0x21] "PARS.GPTR: Getting SERIAL DEV Ptr"
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
[ACPI Debug]  Integer: 0x00000001
[ACPI Debug]  String: [0x12] "SERIAL DEV Ptr is "
[ACPI Debug]  Integer: 0x3FEF99A0
kernel unaligned access to 0xe000004040e7a434, ip=0xa0000001003c81a0
kernel unaligned access to 0xe000004040e7a46c, ip=0xa0000001003c81a0
kernel unaligned access to 0xe000004040e7a4bc, ip=0xa0000001003c81a0
kernel unaligned access to 0xe000004040e7a42c, ip=0xa0000001003c6ca1
kernel unaligned access to 0xe000004040e7a434, ip=0xa0000001003c6cb1
[ACPI Debug]  String: [0x06] "_CRS 0"
[ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
[ACPI Debug]  Integer: 0x00000000
[ACPI Debug]  String: [0x0B] "PARS.GPTR 2"

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

This only contains the output of stores to the ACPI "debug" object, not
the full trace output. However, "_CRS 0" may help


i.e., like this:

> exstoren-0075 [18] ex_resolve_object     : ----Entry
> exstoren-0155 [18] ex_resolve_object     : ----Exit- AE_OK


> -----Original Message-----
> From: Luck, Tony
> Sent: Friday, February 10, 2006 3:25 PM
> To: Moore, Robert; 'Thomas Renninger'; Brown, Len
> Cc: 'linux-acpi@vger.kernel.org'; 'linux-ia64@vger.kernel.org'
> Subject: RE: some new unaligned access while booting ia64 (HP rx2620)
> 
> A 16MB log_buf was enough.
> 
> Here is the initial trace up until the unaligned access messages:
> 
> Linux version 2.6.16-rc2-zx1-smp (aegl@linux-t10) (gcc version 3.4.3
> [ACPI Debug]  Integer: 0x00000000
> [ACPI Debug]  String: [0x1F] "PARS.GUID: evaluating for COMP2"
> [ACPI Debug]  Integer: 0x00000001
> [ACPI Debug]  String: [0x12] "SERIAL DEV Ptr is "
> [ACPI Debug]  Integer: 0x3FEF99A0
> kernel unaligned access to 0xe000004040e7a434, ip=0xa0000001003c81a0
> kernel unaligned access to 0xe000004040e7a46c, ip=0xa0000001003c81a0
> kernel unaligned access to 0xe000004040e7a4bc, ip=0xa0000001003c81a0
> kernel unaligned access to 0xe000004040e7a42c, ip=0xa0000001003c6ca1
> kernel unaligned access to 0xe000004040e7a434, ip=0xa0000001003c6cb1
> [ACPI Debug]  String: [0x06] "_CRS 0"
> [ACPI Debug]  String: [0x0A] "CLIB.LBA 1"
> [ACPI Debug]  Integer: 0x00000000
> [ACPI Debug]  String: [0x0B] "PARS.GPTR 2"

Re: some new unaligned access while booting ia64 (HP rx2620)

[Thomas Renninger]

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

Moore, Robert wrote:
> This only contains the output of stores to the ACPI "debug" object, not
> the full trace output. However, "_CRS 0" may help
> 
> 
Something is strange here.
With rc2-gitXY I got this:

-----------------------------------------------------------------------
slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten

Call Trace:
 [<a0000001000145c0>] show_stack+0x40/0xa0
                                sp=e00000011b7f7ae0 bsp=e00000011b7f1400
 [<a000000100014650>] dump_stack+0x30/0x60
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13e0
 [<a000000100134a50>] __slab_error+0x50/0x80
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13b0
 [<a000000100135ee0>] cache_free_debugcheck+0x220/0x600
                                sp=e00000011b7f7cb0 bsp=e00000011b7f1368
 [<a000000100139b70>] kfree+0xd0/0x480
                                sp=e00000011b7f7cb0 bsp=e00000011b7f1328
 [<a0000001002ea460>] acpi_os_free+0x20/0x40
                                sp=e00000011b7f7cc0 bsp=e00000011b7f1308
 [<a00000010031b980>] acpi_walk_resources+0x240/0x280
                                sp=e00000011b7f7cc0 bsp=e00000011b7f12c8
 [<a0000001003e4a10>] pci_acpi_scan_root+0x130/0x3e0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1278
 [<a000000100330380>] acpi_pci_root_add+0x480/0x620
                                sp=e00000011b7f7cf0 bsp=e00000011b7f1230
 [<a0000001003354c0>] acpi_bus_driver_init+0x80/0xe0
                                sp=e00000011b7f7d10 bsp=e00000011b7f1208
 [<a000000100337c80>] acpi_add_single_object+0x1480/0x1680
                                sp=e00000011b7f7d10 bsp=e00000011b7f11a0
 [<a000000100338110>] acpi_bus_scan+0x290/0x400
                                sp=e00000011b7f7d30 bsp=e00000011b7f1160
 [<a000000100645840>] acpi_scan_init+0x220/0x2c0
                                sp=e00000011b7f7d50 bsp=e00000011b7f1130
 [<a000000100009ee0>] init+0x540/0x880
                                sp=e00000011b7f7d60 bsp=e00000011b7f1108
 [<a0000001000128b0>] kernel_thread_helper+0xd0/0x100
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
 [<a0000001000094a0>] start_kernel_thread+0x20/0x40
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
e0000040f8de54c8: redzone 1: 0x170fc2a5, redzone 2: 0xf901001a00000028.
slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten

Call Trace:
 [<a0000001000145c0>] show_stack+0x40/0xa0
                                sp=e00000011b7f7ae0 bsp=e00000011b7f1400
 [<a000000100014650>] dump_stack+0x30/0x60
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13e0
 [<a000000100134a50>] __slab_error+0x50/0x80
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13b0
 [<a000000100135ee0>] cache_free_debugcheck+0x220/0x600
                                sp=e00000011b7f7cb0 bsp=e00000011b7f1368
 [<a000000100139b70>] kfree+0xd0/0x480
                                sp=e00000011b7f7cb0 bsp=e00000011b7f1328
 [<a0000001002ea460>] acpi_os_free+0x20/0x40
                                sp=e00000011b7f7cc0 bsp=e00000011b7f1308
 [<a00000010031b980>] acpi_walk_resources+0x240/0x280
                                sp=e00000011b7f7cc0 bsp=e00000011b7f12c8
 [<a0000001003e4af0>] pci_acpi_scan_root+0x210/0x3e0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1278
 [<a000000100330380>] acpi_pci_root_add+0x480/0x620
                                sp=e00000011b7f7cf0 bsp=e00000011b7f1230
 [<a0000001003354c0>] acpi_bus_driver_init+0x80/0xe0
                                sp=e00000011b7f7d10 bsp=e00000011b7f1208
 [<a000000100337c80>] acpi_add_single_object+0x1480/0x1680
                                sp=e00000011b7f7d10 bsp=e00000011b7f11a0
 [<a000000100338110>] acpi_bus_scan+0x290/0x400
                                sp=e00000011b7f7d30 bsp=e00000011b7f1160
 [<a000000100645840>] acpi_scan_init+0x220/0x2c0
                                sp=e00000011b7f7d50 bsp=e00000011b7f1130
 [<a000000100009ee0>] init+0x540/0x880
                                sp=e00000011b7f7d60 bsp=e00000011b7f1108
 [<a0000001000128b0>] kernel_thread_helper+0xd0/0x100
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
 [<a0000001000094a0>] start_kernel_thread+0x20/0x40
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
e0000040f89694c8: redzone 1: 0x170fc2a5, redzone 2: 0xf901001a00000028.
slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten

Call Trace:
 [<a0000001000145c0>] show_stack+0x40/0xa0
                                sp=e00000011b7f7a30 bsp=e00000011b7f16d8
 [<a000000100014650>] dump_stack+0x30/0x60
                                sp=e00000011b7f7c00 bsp=e00000011b7f16c0
 [<a000000100134a50>] __slab_error+0x50/0x80
                                sp=e00000011b7f7c00 bsp=e00000011b7f1690
 [<a000000100135ee0>] cache_free_debugcheck+0x220/0x600
                                sp=e00000011b7f7c00 bsp=e00000011b7f1648
 [<a000000100139b70>] kfree+0xd0/0x480
                                sp=e00000011b7f7c00 bsp=e00000011b7f1608
 [<a0000001002ea460>] acpi_os_free+0x20/0x40
                                sp=e00000011b7f7c10 bsp=e00000011b7f15e0
 [<a00000010031b980>] acpi_walk_resources+0x240/0x280
                                sp=e00000011b7f7c10 bsp=e00000011b7f15a0
 [<a00000010032c990>] find_pci_rootbridge+0x1d0/0x3a0
                                sp=e00000011b7f7c20 bsp=e00000011b7f1560
 [<a0000001003102d0>] acpi_ns_get_device_callback+0x270/0x2e0
                                sp=e00000011b7f7c60 bsp=e00000011b7f1508
 [<a000000100314880>] acpi_ns_walk_namespace+0x280/0x2e0
                                sp=e00000011b7f7c80 bsp=e00000011b7f1498
 [<a00000010030ff70>] acpi_get_devices+0xb0/0xe0
                                sp=e00000011b7f7c80 bsp=e00000011b7f1458
 [<a00000010032c790>] acpi_get_pci_rootbridge_handle+0x70/0xa0
                                sp=e00000011b7f7ca0 bsp=e00000011b7f1428
 [<a0000001002b8720>] pci_acpi_find_root_bridge+0x80/0xe0
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13f0
 [<a00000010032c0a0>] acpi_platform_notify+0x120/0x4c0
                                sp=e00000011b7f7cc0 bsp=e00000011b7f13b8
 [<a000000100391050>] device_add+0x230/0x300
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1378
 [<a000000100391150>] device_register+0x30/0x60
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1358
 [<a0000001002a7a90>] pci_create_bus+0x1b0/0x600
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1300
 [<a0000001002aa130>] pci_scan_bus_parented+0x30/0xa0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f12c8
 [<a0000001003e4b20>] pci_acpi_scan_root+0x240/0x3e0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1278
 [<a000000100330380>] acpi_pci_root_add+0x480/0x620
                                sp=e00000011b7f7cf0 bsp=e00000011b7f1230
 [<a0000001003354c0>] acpi_bus_driver_init+0x80/0xe0
                                sp=e00000011b7f7d10 bsp=e00000011b7f1208
 [<a000000100337c80>] acpi_add_single_object+0x1480/0x1680
                                sp=e00000011b7f7d10 bsp=e00000011b7f11a0
 [<a000000100338110>] acpi_bus_scan+0x290/0x400
                                sp=e00000011b7f7d30 bsp=e00000011b7f1160
 [<a000000100645840>] acpi_scan_init+0x220/0x2c0
                                sp=e00000011b7f7d50 bsp=e00000011b7f1130
 [<a000000100009ee0>] init+0x540/0x880
                                sp=e00000011b7f7d60 bsp=e00000011b7f1108
 [<a0000001000128b0>] kernel_thread_helper+0xd0/0x100
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
 [<a0000001000094a0>] start_kernel_thread+0x20/0x40
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
e00000011b7e76b0: redzone 1: 0x170fc2a5, redzone 2: 0xf901001a00000028.
slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten

Call Trace:
 [<a0000001000145c0>] show_stack+0x40/0xa0
                                sp=e00000011b7f7a30 bsp=e00000011b7f16d8
 [<a000000100014650>] dump_stack+0x30/0x60
                                sp=e00000011b7f7c00 bsp=e00000011b7f16c0
 [<a000000100134a50>] __slab_error+0x50/0x80
                                sp=e00000011b7f7c00 bsp=e00000011b7f1690
 [<a000000100135ee0>] cache_free_debugcheck+0x220/0x600
                                sp=e00000011b7f7c00 bsp=e00000011b7f1648
 [<a000000100139b70>] kfree+0xd0/0x480
                                sp=e00000011b7f7c00 bsp=e00000011b7f1608
 [<a0000001002ea460>] acpi_os_free+0x20/0x40
                                sp=e00000011b7f7c10 bsp=e00000011b7f15e0
 [<a00000010031b980>] acpi_walk_resources+0x240/0x280
                                sp=e00000011b7f7c10 bsp=e00000011b7f15a0
 [<a00000010032c990>] find_pci_rootbridge+0x1d0/0x3a0
                                sp=e00000011b7f7c20 bsp=e00000011b7f1560
 [<a0000001003102d0>] acpi_ns_get_device_callback+0x270/0x2e0
                                sp=e00000011b7f7c60 bsp=e00000011b7f1508
 [<a000000100314880>] acpi_ns_walk_namespace+0x280/0x2e0
                                sp=e00000011b7f7c80 bsp=e00000011b7f1498
 [<a00000010030ff70>] acpi_get_devices+0xb0/0xe0
                                sp=e00000011b7f7c80 bsp=e00000011b7f1458
 [<a00000010032c790>] acpi_get_pci_rootbridge_handle+0x70/0xa0
                                sp=e00000011b7f7ca0 bsp=e00000011b7f1428
 [<a0000001002b8720>] pci_acpi_find_root_bridge+0x80/0xe0
                                sp=e00000011b7f7cb0 bsp=e00000011b7f13f0
 [<a00000010032c0a0>] acpi_platform_notify+0x120/0x4c0
                                sp=e00000011b7f7cc0 bsp=e00000011b7f13b8
 [<a000000100391050>] device_add+0x230/0x300
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1378
 [<a000000100391150>] device_register+0x30/0x60
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1358
 [<a0000001002a7a90>] pci_create_bus+0x1b0/0x600
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1300
 [<a0000001002aa130>] pci_scan_bus_parented+0x30/0xa0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f12c8
 [<a0000001003e4b20>] pci_acpi_scan_root+0x240/0x3e0
                                sp=e00000011b7f7cd0 bsp=e00000011b7f1278
 [<a000000100330380>] acpi_pci_root_add+0x480/0x620
                                sp=e00000011b7f7cf0 bsp=e00000011b7f1230
 [<a0000001003354c0>] acpi_bus_driver_init+0x80/0xe0
                                sp=e00000011b7f7d10 bsp=e00000011b7f1208
 [<a000000100337c80>] acpi_add_single_object+0x1480/0x1680
                                sp=e00000011b7f7d10 bsp=e00000011b7f11a0
 [<a000000100338110>] acpi_bus_scan+0x290/0x400
                                sp=e00000011b7f7d30 bsp=e00000011b7f1160
 [<a000000100645840>] acpi_scan_init+0x220/0x2c0
                                sp=e00000011b7f7d50 bsp=e00000011b7f1130
 [<a000000100009ee0>] init+0x540/0x880
                                sp=e00000011b7f7d60 bsp=e00000011b7f1108
 [<a0000001000128b0>] kernel_thread_helper+0xd0/0x100
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
 [<a0000001000094a0>] start_kernel_thread+0x20/0x40
                                sp=e00000011b7f7e30 bsp=e00000011b7f10e0
e0000040fab29d88: redzone 1: 0x170fc2a5, redzone 2: 0xf901001a00000028.
Slab corruption: start=e0000040fab29ea8, len=256
Redzone: 0xad0e3701d2244a/0x5a2cf071.
Last user: [<a00000010028dbc0>](kobject_uevent+0x8a0/0x940)
000: 00 04 01 02 04 02 04 04 6b 6b 6b 6b 07 00 00 00
010: 0c 00 00 00 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=e0000040fab29d90, len=256
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<a0000001002ea460>](acpi_os_free+0x20/0x40)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=e0000040fab29fc0, len=256
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<a000000100415b20>](skb_release_data+0x1a0/0x1c0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
-----------------------------------------------------------------------



I startet to pack the acpi functions in arch/ia64/pci/pci.c
(pci_acpi_scan_root()) into:
acpi_dbg_level=0x21FFFF;      /* Enable ACPI DEBUG */
...
acpi_dbg_level=0xF;           /* Disable ACPI_DEBUG */

However I now used a rc3 kernel and the pci_acpi_scan_root() function
with it's ACPI invokations succeeded. Has there any work been made?

The slab error now happens a bit later in (acpi_sba_ioc_add()).
So I set the acpi_debug trace there.

It is probably the:
ACPI_MEM_FREE(dev_info);
in arch/ia64/hp/common/sba_iommu.c:

Output and changes made are attached.
Any ideas?

Thanks,

     Thomas

[-- Attachment #2: unaligned_access_debug.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 9183 bytes --]

Re: some new unaligned access while booting ia64 (HP rx2620)

[Bjorn Helgaas]

On Monday 13 February 2006 11:51, Thomas Renninger wrote:
> Something is strange here.
> With rc2-gitXY I got this:
> 
> -----------------------------------------------------------------------
> slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten

This is unrelated to Tony's original "unaligned access" problem, right?

If I understand correctly, you have CONFIG_DEBUG_SLAB turned on, and
it reported a double free in the pci_acpi_scan_root() path in the rc2
kernel.  Then you tried rc3 and saw a similar slab problem in
the acpi_sba_ioc_add() path.

I looked at both of those paths, and I don't see anything wrong.  I
tried unsuccessfully to reproduce it with an rc1-mm4 kernel on an
rx2600.  I also tried an rc3 kernel (hg pull from 10 minutes ago)
and couldn't reproduce it.

You have ACPI debug stuff turned on, don't you?  I didn't enable that.
Can you reproduce the slab problem with that turned off?

Re: some new unaligned access while booting ia64 (HP rx2620)

[Andreas Schwab]

Bjorn Helgaas <bjorn.helgaas@hp.com> writes:

> I looked at both of those paths, and I don't see anything wrong.  I
> tried unsuccessfully to reproduce it with an rc1-mm4 kernel on an
> rx2600. 

Please try rx7620 or rx8640.  Apparently this only happens on the NUMA
systems.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: some new unaligned access while booting ia64 (HP rx2620)

[Bjorn Helgaas]

On Monday 13 February 2006 15:57, Andreas Schwab wrote:
> Bjorn Helgaas <bjorn.helgaas@hp.com> writes:
> > I looked at both of those paths, and I don't see anything wrong.  I
> > tried unsuccessfully to reproduce it with an rc1-mm4 kernel on an
> > rx2600. 
> 
> Please try rx7620 or rx8640.  Apparently this only happens on the NUMA
> systems.

While I was reading your mail, I was booting an rx7620 for something else.
When I looked at it again, it was spewing the slab errors :-)

I don't have time to debug it completely today, but it looks like the
conversion of an AML vendor resource is overrunning the buffer.  p1
and p2 are pointers to the redzones before and after the object.
0x170fc2a5 is the correct value:

acpi_rs_create_resource_list: p1 0xe0000007fc1518f0 p2 0xe0000007fc1519f8
acpi_rs_create_resource_list: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: p1 0xe0000007fc1518f0 p2 0xe0000007fc1519f8
acpi_rs_convert_aml_to_resources: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x88: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x8a: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x8a: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x84: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x84: *p1 0x170fc2a5 *p2 0x170fc2a5
acpi_rs_convert_aml_to_resources: before converting AML resource 0x79: *p1 0x170fc2a5 *p2 0xf901001a00000028

AML resource type 0x84 is a vendor-defined descriptor.  This makes sense
because rx7620 and rx8620 have large vendor-defined descriptors, while
the smaller boxes like rx2600 do not.

[PATCH] ACPI: fix vendor resource length computation

[Bjorn Helgaas]

acpi_rs_get_list_length() needs to account for all the vendor-defined
data bytes.  Failing to include these causes buffers to be sized too
small, which causes slab corruption when we later convert AML to
resources and run off the end of the buffer.

I'm no expert on this code, so please scrutinize this carefully.

This causes slab corruption on machines that use ACPI vendor-defined
resources.  All HP ia64 machines do, and I'm told that some NEC
machines may as well.  So if the fix is correct, it would be good
to have it in 2.6.16.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-mm4/drivers/acpi/resources/rscalc.c
=================================--- work-mm4.orig/drivers/acpi/resources/rscalc.c	2006-02-14 13:32:50.000000000 -0700
+++ work-mm4/drivers/acpi/resources/rscalc.c	2006-02-14 13:33:25.000000000 -0700
@@ -391,8 +391,7 @@
 			 * Ensure a 32-bit boundary for the structure
 			 */
 			extra_struct_bytes -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
-			    resource_length;
+			    ACPI_ROUND_UP_to_32_bITS(resource_length);
 			break;
 
 		case ACPI_RESOURCE_NAME_END_TAG:
@@ -408,8 +407,7 @@
 			 * Add vendor data and ensure a 32-bit boundary for the structure
 			 */
 			extra_struct_bytes -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
-			    resource_length;
+			    ACPI_ROUND_UP_to_32_bITS(resource_length);
 			break;
 
 		case ACPI_RESOURCE_NAME_ADDRESS32:

Re: [PATCH] ACPI: fix vendor resource length computation

[Bjorn Helgaas]

On Tuesday 14 February 2006 16:13, Bjorn Helgaas wrote:
> acpi_rs_get_list_length() needs to account for all the vendor-defined
> data bytes.  Failing to include these causes buffers to be sized too
> small, which causes slab corruption when we later convert AML to
> resources and run off the end of the buffer.
> 
> I'm no expert on this code, so please scrutinize this carefully.
> 
> This causes slab corruption on machines that use ACPI vendor-defined
> resources.  All HP ia64 machines do, and I'm told that some NEC
> machines may as well.  So if the fix is correct, it would be good
> to have it in 2.6.16.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

I forgot to mention that this patch may be used under either the GPL
or the BSD license used for the ACPI CA.

> Index: work-mm4/drivers/acpi/resources/rscalc.c
> =================================> --- work-mm4.orig/drivers/acpi/resources/rscalc.c	2006-02-14 13:32:50.000000000 -0700
> +++ work-mm4/drivers/acpi/resources/rscalc.c	2006-02-14 13:33:25.000000000 -0700
> @@ -391,8 +391,7 @@
>  			 * Ensure a 32-bit boundary for the structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
>  
>  		case ACPI_RESOURCE_NAME_END_TAG:
> @@ -408,8 +407,7 @@
>  			 * Add vendor data and ensure a 32-bit boundary for the structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
>  
>  		case ACPI_RESOURCE_NAME_ADDRESS32:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [PATCH] ACPI: fix vendor resource length computation

[Moore, Robert]

I'll look at this. 

Does this fix all of the slab corruptions issues we have been hearing
about?

Bob


> -----Original Message-----
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> Sent: Tuesday, February 14, 2006 3:13 PM
> To: Andreas Schwab
> Cc: Thomas Renninger; Moore, Robert; Luck, Tony; Brown, Len; linux-
> acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Andrew Morton;
> efocht@hpce.nec.com
> Subject: [PATCH] ACPI: fix vendor resource length computation
> 
> acpi_rs_get_list_length() needs to account for all the vendor-defined
> data bytes.  Failing to include these causes buffers to be sized too
> small, which causes slab corruption when we later convert AML to
> resources and run off the end of the buffer.
> 
> I'm no expert on this code, so please scrutinize this carefully.
> 
> This causes slab corruption on machines that use ACPI vendor-defined
> resources.  All HP ia64 machines do, and I'm told that some NEC
> machines may as well.  So if the fix is correct, it would be good
> to have it in 2.6.16.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: work-mm4/drivers/acpi/resources/rscalc.c
> =================================> --- work-mm4.orig/drivers/acpi/resources/rscalc.c	2006-02-14
> 13:32:50.000000000 -0700
> +++ work-mm4/drivers/acpi/resources/rscalc.c	2006-02-14
> 13:33:25.000000000 -0700
> @@ -391,8 +391,7 @@
>  			 * Ensure a 32-bit boundary for the structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
> 
>  		case ACPI_RESOURCE_NAME_END_TAG:
> @@ -408,8 +407,7 @@
>  			 * Add vendor data and ensure a 32-bit boundary
for the
> structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
> 
>  		case ACPI_RESOURCE_NAME_ADDRESS32:

Re: [PATCH] ACPI: fix vendor resource length computation

[Bjorn Helgaas]

On Tuesday 14 February 2006 16:25, Moore, Robert wrote:
> Does this fix all of the slab corruptions issues we have been hearing
> about?

It fixes the one I saw with 2.6.16-rc3 on HP rx7620.  I'm pretty sure
that's the same as the one Thomas observed in pci_acpi_scan_root() and
acpi_sba_ioc_add().

But I haven't been paying attention to any other slab corruption issues,
so I can't speculate about them.

> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > Sent: Tuesday, February 14, 2006 3:13 PM
> > To: Andreas Schwab
> > Cc: Thomas Renninger; Moore, Robert; Luck, Tony; Brown, Len; linux-
> > acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Andrew Morton;
> > efocht@hpce.nec.com
> > Subject: [PATCH] ACPI: fix vendor resource length computation
> > 
> > acpi_rs_get_list_length() needs to account for all the vendor-defined
> > data bytes.  Failing to include these causes buffers to be sized too
> > small, which causes slab corruption when we later convert AML to
> > resources and run off the end of the buffer.
> > 
> > I'm no expert on this code, so please scrutinize this carefully.
> > 
> > This causes slab corruption on machines that use ACPI vendor-defined
> > resources.  All HP ia64 machines do, and I'm told that some NEC
> > machines may as well.  So if the fix is correct, it would be good
> > to have it in 2.6.16.
> > 
> > Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > 
> > Index: work-mm4/drivers/acpi/resources/rscalc.c
> > =================================> > --- work-mm4.orig/drivers/acpi/resources/rscalc.c	2006-02-14
> > 13:32:50.000000000 -0700
> > +++ work-mm4/drivers/acpi/resources/rscalc.c	2006-02-14
> > 13:33:25.000000000 -0700
> > @@ -391,8 +391,7 @@
> >  			 * Ensure a 32-bit boundary for the structure
> >  			 */
> >  			extra_struct_bytes > > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> > -			    resource_length;
> > +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
> >  			break;
> > 
> >  		case ACPI_RESOURCE_NAME_END_TAG:
> > @@ -408,8 +407,7 @@
> >  			 * Add vendor data and ensure a 32-bit boundary
> for the
> > structure
> >  			 */
> >  			extra_struct_bytes > > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> > -			    resource_length;
> > +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
> >  			break;
> > 
> >  		case ACPI_RESOURCE_NAME_ADDRESS32:
> 

RE: [PATCH] ACPI: fix vendor resource length computation

[Moore, Robert]

I think the original code may have been attempting to subtract off the
size of the descriptor header to obtain the length of the vendor data
bytes. However, something like a global replace may have broken it.



> -----Original Message-----
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> Sent: Tuesday, February 14, 2006 3:13 PM
> To: Andreas Schwab
> Cc: Thomas Renninger; Moore, Robert; Luck, Tony; Brown, Len; linux-
> acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Andrew Morton;
> efocht@hpce.nec.com
> Subject: [PATCH] ACPI: fix vendor resource length computation
> 
> acpi_rs_get_list_length() needs to account for all the vendor-defined
> data bytes.  Failing to include these causes buffers to be sized too
> small, which causes slab corruption when we later convert AML to
> resources and run off the end of the buffer.
> 
> I'm no expert on this code, so please scrutinize this carefully.
> 
> This causes slab corruption on machines that use ACPI vendor-defined
> resources.  All HP ia64 machines do, and I'm told that some NEC
> machines may as well.  So if the fix is correct, it would be good
> to have it in 2.6.16.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: work-mm4/drivers/acpi/resources/rscalc.c
> =================================> --- work-mm4.orig/drivers/acpi/resources/rscalc.c	2006-02-14
> 13:32:50.000000000 -0700
> +++ work-mm4/drivers/acpi/resources/rscalc.c	2006-02-14
> 13:33:25.000000000 -0700
> @@ -391,8 +391,7 @@
>  			 * Ensure a 32-bit boundary for the structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
> 
>  		case ACPI_RESOURCE_NAME_END_TAG:
> @@ -408,8 +407,7 @@
>  			 * Add vendor data and ensure a 32-bit boundary
for the
> structure
>  			 */
>  			extra_struct_bytes > -			    ACPI_ROUND_UP_to_32_bITS(resource_length) -
> -			    resource_length;
> +			    ACPI_ROUND_UP_to_32_bITS(resource_length);
>  			break;
> 
>  		case ACPI_RESOURCE_NAME_ADDRESS32:

Re: [PATCH] ACPI: fix vendor resource length computation

[Thomas Renninger]

Moore, Robert wrote:
> I think the original code may have been attempting to subtract off the
> size of the descriptor header to obtain the length of the vendor data
> bytes. However, something like a global replace may have broken it.
> 
Thanks, this one fixes the mem corruption.
Unaligned access messages still remain...


   Thomas

RE: [PATCH] ACPI: fix vendor resource length computation

[Moore, Robert]

I'm working on the alignment issue also, should be a fix this week.
Bob


> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Wednesday, February 15, 2006 9:50 AM
> To: Moore, Robert
> Cc: Bjorn Helgaas; Andreas Schwab; Luck, Tony; Brown, Len; linux-
> acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Andrew Morton;
> efocht@hpce.nec.com
> Subject: Re: [PATCH] ACPI: fix vendor resource length computation
> 
> Moore, Robert wrote:
> > I think the original code may have been attempting to subtract off
the
> > size of the descriptor header to obtain the length of the vendor
data
> > bytes. However, something like a global replace may have broken it.
> >
> Thanks, this one fixes the mem corruption.
> Unaligned access messages still remain...
> 
> 
>    Thomas

RE: [PATCH] ACPI: fix vendor resource length computation

[Luck, Tony]

> I'm working on the alignment issue also, should be a fix this week.

With Bjorn's tip on using console=uart,mmio,0x{address} I can now
get a complete trace from boot using acpi_dbg_level = 0xffffff ...
well in theory I can, I started the boot two days ago and have
2.2 million lines of output so far, and it is still going!  Now
I'm just curious as to whether this will actually complete, but
if it doesn't do so in the next few days I'll have to abort the
boot and get back to using that system for regression testing on
other patches.

Sadly, I think that using the "console=uart,..." flag may have
caused the kernel to skip the bit of acpi probing that caused the
unaligned traps, as I don't see any "unaligned" messages in the
output so far ... so this might be a completely futile exercise.

-Tony

Re: [PATCH] ACPI: fix vendor resource length computation

[Thomas Renninger]

Luck, Tony wrote:
>> I'm working on the alignment issue also, should be a fix this week.
> 
> With Bjorn's tip on using console=uart,mmio,0x{address} I can now
> get a complete trace from boot using acpi_dbg_level = 0xffffff ...
> well in theory I can, I started the boot two days ago and have
> 2.2 million lines of output so far, and it is still going!  Now
> I'm just curious as to whether this will actually complete, but
> if it doesn't do so in the next few days I'll have to abort the
> boot and get back to using that system for regression testing on
> other patches.
> 
> Sadly, I think that using the "console=uart,..." flag may have
> caused the kernel to skip the bit of acpi probing that caused the
> unaligned traps, as I don't see any "unaligned" messages in the
> output so far ... so this might be a completely futile exercise.
> 
Better don't use the boot parameters. Try to identify at which point
the culprit might lie and then embed the code you like to
debug in the sources into:
acpi_dbg_level=0xXY (whatever debug level, avoid mutex and other
                        unnecessary stuff you don't need)
... bad code to debug

acpi_dbg_level=0xF

I expect the output will never end, there will pop up an acpi interrupt
or some polling is done by ACPI and you are trapped in endless output...

    Thomas

RE: [PATCH] ACPI: fix vendor resource length computation

[Moore, Robert]

I recently added a new interface to ACPICA to support this kind of
debugging. It enables/disables debug for a specific control method:

ACPI_STATUS
AcpiDebugTrace (
    char                    *Name,
    UINT32                  DebugLevel,
    UINT32                  DebugLayer,
    UINT32                  Flags);

It would be nice to see this exposed in Linux somehow.

Bob


> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Thursday, February 16, 2006 12:59 AM
> To: Luck, Tony
> Cc: Moore, Robert; Bjorn Helgaas; Andreas Schwab; Brown, Len; linux-
> acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Andrew Morton;
> efocht@hpce.nec.com
> Subject: Re: [PATCH] ACPI: fix vendor resource length computation
> 
> Luck, Tony wrote:
> >> I'm working on the alignment issue also, should be a fix this week.
> >
> > With Bjorn's tip on using console=uart,mmio,0x{address} I can now
> > get a complete trace from boot using acpi_dbg_level = 0xffffff ...
> > well in theory I can, I started the boot two days ago and have
> > 2.2 million lines of output so far, and it is still going!  Now
> > I'm just curious as to whether this will actually complete, but
> > if it doesn't do so in the next few days I'll have to abort the
> > boot and get back to using that system for regression testing on
> > other patches.
> >
> > Sadly, I think that using the "console=uart,..." flag may have
> > caused the kernel to skip the bit of acpi probing that caused the
> > unaligned traps, as I don't see any "unaligned" messages in the
> > output so far ... so this might be a completely futile exercise.
> >
> Better don't use the boot parameters. Try to identify at which point
> the culprit might lie and then embed the code you like to
> debug in the sources into:
> acpi_dbg_level=0xXY (whatever debug level, avoid mutex and other
>                         unnecessary stuff you don't need)
> ... bad code to debug
> 
> acpi_dbg_level=0xF
> 
> I expect the output will never end, there will pop up an acpi
interrupt
> or some polling is done by ACPI and you are trapped in endless
output...
> 
>     Thomas

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

> This only contains the output of stores to the ACPI "debug"
> object, not the full trace output. However, "_CRS 0" may help

Ah yes.  I'd dropped the acpi_dbg_level = 0xffffff; while trying
to figure out what was going wrong with CONFIG_ACPI_DEBUG=y.

Putting it back in, 16MB is not enough for log_buf :-(

-Tony

RE: some new unaligned access while booting ia64 (HP rx2620)

[Luck, Tony]

> This only contains the output of stores to the ACPI "debug" object,
> not the full trace output. However, "_CRS 0" may help

So ignoring ACPI_DEBUG=y for the moment, I put in a WARN_ON() in the
unaligned trap handler to get some stack traces when the unaligned
access happened.

Here's the boot log from that (note that there are perhaps more
unaligned
accesses than this, but the kernel rate limiting code kicks in at five
messages).

-Tony

Linux version 2.6.16-rc2-zx1-smp (aegl@linux-t10) (gcc version 3.4.3
20050227 (Red Hat 3.4.3-22.1)) #2 SMP Fri Feb 10 16:29:13 PST 2006
EFI v1.10 by HP: SALsystab=0x3fefa000 ACPI 2.0=0x3fd5e000
SMBIOS=0x3fefc000 HCDP=0x3fd5c000
PCDP: v0 at 0x3fd5c000
Explicit "console="; ignoring PCDP
warning: skipping physical page 0
Initial ramdisk at: 0xe00000407ee5b000 (1303576 bytes)
SAL 3.1: HP version 3.15
SAL Platform features: None
SAL: AP wakeup using external interrupt vector 0xff
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
GSI 36 (level, low) -> CPU 0 (0x0000) vector 48
2 CPUs available, 2 CPUs total
MCA related initialization done
Virtual mem_map starts at 0xa0007fffc7900000
Built 1 zonelists
Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-zx1-smp.gz
console=ttyS0 root=LABEL=/ ro
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 7, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 6, 1048576 bytes)
Memory: 2058128k/2086064k available (8134k code, 26784k reserved, 3552k
data, 272k init)
McKinley Errata 9 workaround not needed; disabling it
Mount-cache hash table entries: 1024
Boot processor id 0x0/0x0
CPU 1: synchronized ITC with CPU 0 (last diff 1 cycles, maxerr 554
cycles)
Brought up 2 CPUs
Total of 2 processors activated (3891.20 BogoMIPS).
migration_cost064
checking if image is initramfs... it is
Freeing initrd memory: 1264kB freed
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
kernel unaligned access to 0xe000004040e72604, ip=0xa0000001003afb00
Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Call Trace:
 [<a000000100010a10>] show_stack+0x50/0xa0
                                spà0000407ff375c0 bspà0000407ff31428
 [<a000000100010a90>] dump_stack+0x30/0x60
                                spà0000407ff37790 bspà0000407ff31410
 [<a0000001000376f0>] ia64_handle_unaligned+0x2d0/0x2780
                                spà0000407ff37790 bspà0000407ff31388
 [<a00000010000bd70>] ia64_prepare_handle_unaligned+0x30/0x60
                                spà0000407ff37940 bspà0000407ff31388
 [<a00000010000b760>] ia64_leave_kernel+0x0/0x280
                                spà0000407ff37b50 bspà0000407ff31388
 [<a0000001003afb00>] acpi_rs_get_resource_source+0x60/0x1e0
                                spà0000407ff37d20 bspà0000407ff31328
 [<a0000001003ad9b0>] acpi_rs_convert_aml_to_resource+0x4d0/0x760
                                spà0000407ff37d20 bspà0000407ff312c8
 [<a0000001003ad190>] acpi_rs_convert_aml_to_resources+0x90/0x1c0
                                spà0000407ff37d30 bspà0000407ff31290
 [<a0000001003ac980>] acpi_rs_create_resource_list+0xc0/0x100
                                spà0000407ff37d40 bspà0000407ff31260
 [<a0000001003aff20>] acpi_rs_get_method_data+0x80/0xc0
                                spà0000407ff37d50 bspà0000407ff31230
 [<a0000001003ae3b0>] acpi_walk_resources+0xd0/0x240
                                spà0000407ff37d60 bspà0000407ff311e0
 [<a0000001006d6bd0>] pci_acpi_scan_root+0xf0/0x380
                                spà0000407ff37d70 bspà0000407ff31188
 [<a0000001003c4be0>] acpi_pci_root_add+0x4e0/0x660
                                spà0000407ff37d90 bspà0000407ff31138
 [<a0000001003d35f0>] acpi_bus_driver_init+0x70/0xe0
                                spà0000407ff37db0 bspà0000407ff31110
 [<a0000001003d53a0>] acpi_add_single_object+0x1540/0x1640
                                spà0000407ff37db0 bspà0000407ff31088
 [<a0000001003d5b40>] acpi_bus_scan+0x280/0x400
                                spà0000407ff37e00 bspà0000407ff31048
 [<a00000010097baf0>] acpi_scan_init+0x1f0/0x260
                                spà0000407ff37e20 bspà0000407ff31020
 [<a000000100009710>] init+0x470/0x7e0
                                spà0000407ff37e30 bspà0000407ff30fe8
 [<a000000100012c70>] kernel_thread_helper+0xd0/0x100
                                spà0000407ff37e30 bspà0000407ff30fc0
 [<a000000100009140>] start_kernel_thread+0x20/0x40
                                spà0000407ff37e30 bspà0000407ff30fc0
kernel unaligned access to 0xe000004040e7263c, ip=0xa0000001003afb00
Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Call Trace:
 [<a000000100010a10>] show_stack+0x50/0xa0
                                spà0000407ff375c0 bspà0000407ff31428
 [<a000000100010a90>] dump_stack+0x30/0x60
                                spà0000407ff37790 bspà0000407ff31410
 [<a0000001000376f0>] ia64_handle_unaligned+0x2d0/0x2780
                                spà0000407ff37790 bspà0000407ff31388
 [<a00000010000bd70>] ia64_prepare_handle_unaligned+0x30/0x60
                                spà0000407ff37940 bspà0000407ff31388
 [<a00000010000b760>] ia64_leave_kernel+0x0/0x280
                                spà0000407ff37b50 bspà0000407ff31388
 [<a0000001003afb00>] acpi_rs_get_resource_source+0x60/0x1e0
                                spà0000407ff37d20 bspà0000407ff31328
 [<a0000001003ad9b0>] acpi_rs_convert_aml_to_resource+0x4d0/0x760
                                spà0000407ff37d20 bspà0000407ff312c8
 [<a0000001003ad190>] acpi_rs_convert_aml_to_resources+0x90/0x1c0
                                spà0000407ff37d30 bspà0000407ff31290
 [<a0000001003ac980>] acpi_rs_create_resource_list+0xc0/0x100
                                spà0000407ff37d40 bspà0000407ff31260
 [<a0000001003aff20>] acpi_rs_get_method_data+0x80/0xc0
                                spà0000407ff37d50 bspà0000407ff31230
 [<a0000001003ae3b0>] acpi_walk_resources+0xd0/0x240
                                spà0000407ff37d60 bspà0000407ff311e0
 [<a0000001006d6bd0>] pci_acpi_scan_root+0xf0/0x380
                                spà0000407ff37d70 bspà0000407ff31188
 [<a0000001003c4be0>] acpi_pci_root_add+0x4e0/0x660
                                spà0000407ff37d90 bspà0000407ff31138
 [<a0000001003d35f0>] acpi_bus_driver_init+0x70/0xe0
                                spà0000407ff37db0 bspà0000407ff31110
 [<a0000001003d53a0>] acpi_add_single_object+0x1540/0x1640
                                spà0000407ff37db0 bspà0000407ff31088
 [<a0000001003d5b40>] acpi_bus_scan+0x280/0x400
                                spà0000407ff37e00 bspà0000407ff31048
 [<a00000010097baf0>] acpi_scan_init+0x1f0/0x260
                                spà0000407ff37e20 bspà0000407ff31020
 [<a000000100009710>] init+0x470/0x7e0
                                spà0000407ff37e30 bspà0000407ff30fe8
 [<a000000100012c70>] kernel_thread_helper+0xd0/0x100
                                spà0000407ff37e30 bspà0000407ff30fc0
 [<a000000100009140>] start_kernel_thread+0x20/0x40
                                spà0000407ff37e30 bspà0000407ff30fc0
kernel unaligned access to 0xe000004040e7268c, ip=0xa0000001003afb00
Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Call Trace:
 [<a000000100010a10>] show_stack+0x50/0xa0
                                spà0000407ff375c0 bspà0000407ff31428
 [<a000000100010a90>] dump_stack+0x30/0x60
                                spà0000407ff37790 bspà0000407ff31410
 [<a0000001000376f0>] ia64_handle_unaligned+0x2d0/0x2780
                                spà0000407ff37790 bspà0000407ff31388
 [<a00000010000bd70>] ia64_prepare_handle_unaligned+0x30/0x60
                                spà0000407ff37940 bspà0000407ff31388
 [<a00000010000b760>] ia64_leave_kernel+0x0/0x280
                                spà0000407ff37b50 bspà0000407ff31388
 [<a0000001003afb00>] acpi_rs_get_resource_source+0x60/0x1e0
                                spà0000407ff37d20 bspà0000407ff31328
 [<a0000001003ad9b0>] acpi_rs_convert_aml_to_resource+0x4d0/0x760
                                spà0000407ff37d20 bspà0000407ff312c8
 [<a0000001003ad190>] acpi_rs_convert_aml_to_resources+0x90/0x1c0
                                spà0000407ff37d30 bspà0000407ff31290
 [<a0000001003ac980>] acpi_rs_create_resource_list+0xc0/0x100
                                spà0000407ff37d40 bspà0000407ff31260
 [<a0000001003aff20>] acpi_rs_get_method_data+0x80/0xc0
                                spà0000407ff37d50 bspà0000407ff31230
 [<a0000001003ae3b0>] acpi_walk_resources+0xd0/0x240
                                spà0000407ff37d60 bspà0000407ff311e0
 [<a0000001006d6bd0>] pci_acpi_scan_root+0xf0/0x380
                                spà0000407ff37d70 bspà0000407ff31188
 [<a0000001003c4be0>] acpi_pci_root_add+0x4e0/0x660
                                spà0000407ff37d90 bspà0000407ff31138
 [<a0000001003d35f0>] acpi_bus_driver_init+0x70/0xe0
                                spà0000407ff37db0 bspà0000407ff31110
 [<a0000001003d53a0>] acpi_add_single_object+0x1540/0x1640
                                spà0000407ff37db0 bspà0000407ff31088
 [<a0000001003d5b40>] acpi_bus_scan+0x280/0x400
                                spà0000407ff37e00 bspà0000407ff31048
 [<a00000010097baf0>] acpi_scan_init+0x1f0/0x260
                                spà0000407ff37e20 bspà0000407ff31020
 [<a000000100009710>] init+0x470/0x7e0
                                spà0000407ff37e30 bspà0000407ff30fe8
 [<a000000100012c70>] kernel_thread_helper+0xd0/0x100
                                spà0000407ff37e30 bspà0000407ff30fc0
 [<a000000100009140>] start_kernel_thread+0x20/0x40
                                spà0000407ff37e30 bspà0000407ff30fc0
kernel unaligned access to 0xe000004040e725fc, ip=0xa0000001003ae901
Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Call Trace:
 [<a000000100010a10>] show_stack+0x50/0xa0
                                spà0000407ff375b0 bspà0000407ff31358
 [<a000000100010a90>] dump_stack+0x30/0x60
                                spà0000407ff37780 bspà0000407ff31340
 [<a0000001000376f0>] ia64_handle_unaligned+0x2d0/0x2780
                                spà0000407ff37780 bspà0000407ff312c0
 [<a00000010000bd70>] ia64_prepare_handle_unaligned+0x30/0x60
                                spà0000407ff37930 bspà0000407ff312c0
 [<a00000010000b760>] ia64_leave_kernel+0x0/0x280
                                spà0000407ff37b40 bspà0000407ff312c0
 [<a0000001003ae900>] acpi_resource_to_address64+0x340/0x3e0
                                spà0000407ff37d10 bspà0000407ff31280
 [<a0000001006d63d0>] resource_to_window+0x30/0xc0
                                spà0000407ff37d10 bspà0000407ff31258
 [<a0000001006d6490>] count_window+0x30/0x80
                                spà0000407ff37d10 bspà0000407ff31230
 [<a0000001003ae460>] acpi_walk_resources+0x180/0x240
                                spà0000407ff37d60 bspà0000407ff311e0
 [<a0000001006d6bd0>] pci_acpi_scan_root+0xf0/0x380
                                spà0000407ff37d70 bspà0000407ff31188
 [<a0000001003c4be0>] acpi_pci_root_add+0x4e0/0x660
                                spà0000407ff37d90 bspà0000407ff31138
 [<a0000001003d35f0>] acpi_bus_driver_init+0x70/0xe0
                                spà0000407ff37db0 bspà0000407ff31110
 [<a0000001003d53a0>] acpi_add_single_object+0x1540/0x1640
                                spà0000407ff37db0 bspà0000407ff31088
 [<a0000001003d5b40>] acpi_bus_scan+0x280/0x400
                                spà0000407ff37e00 bspà0000407ff31048
 [<a00000010097baf0>] acpi_scan_init+0x1f0/0x260
                                spà0000407ff37e20 bspà0000407ff31020
 [<a000000100009710>] init+0x470/0x7e0
                                spà0000407ff37e30 bspà0000407ff30fe8
 [<a000000100012c70>] kernel_thread_helper+0xd0/0x100
                                spà0000407ff37e30 bspà0000407ff30fc0
 [<a000000100009140>] start_kernel_thread+0x20/0x40
                                spà0000407ff37e30 bspà0000407ff30fc0
kernel unaligned access to 0xe000004040e72604, ip=0xa0000001003ae911
Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Call Trace:
 [<a000000100010a10>] show_stack+0x50/0xa0
                                spà0000407ff375b0 bspà0000407ff31358
 [<a000000100010a90>] dump_stack+0x30/0x60
                                spà0000407ff37780 bspà0000407ff31340
 [<a0000001000376f0>] ia64_handle_unaligned+0x2d0/0x2780
                                spà0000407ff37780 bspà0000407ff312c0
 [<a00000010000bd70>] ia64_prepare_handle_unaligned+0x30/0x60
                                spà0000407ff37930 bspà0000407ff312c0
 [<a00000010000b760>] ia64_leave_kernel+0x0/0x280
                                spà0000407ff37b40 bspà0000407ff312c0
 [<a0000001003ae910>] acpi_resource_to_address64+0x350/0x3e0
                                spà0000407ff37d10 bspà0000407ff31280
 [<a0000001006d63d0>] resource_to_window+0x30/0xc0
                                spà0000407ff37d10 bspà0000407ff31258
 [<a0000001006d6490>] count_window+0x30/0x80
                                spà0000407ff37d10 bspà0000407ff31230
 [<a0000001003ae460>] acpi_walk_resources+0x180/0x240
                                spà0000407ff37d60 bspà0000407ff311e0
 [<a0000001006d6bd0>] pci_acpi_scan_root+0xf0/0x380
                                spà0000407ff37d70 bspà0000407ff31188
 [<a0000001003c4be0>] acpi_pci_root_add+0x4e0/0x660
                                spà0000407ff37d90 bspà0000407ff31138
 [<a0000001003d35f0>] acpi_bus_driver_init+0x70/0xe0
                                spà0000407ff37db0 bspà0000407ff31110
 [<a0000001003d53a0>] acpi_add_single_object+0x1540/0x1640
                                spà0000407ff37db0 bspà0000407ff31088
 [<a0000001003d5b40>] acpi_bus_scan+0x280/0x400
                                spà0000407ff37e00 bspà0000407ff31048
 [<a00000010097baf0>] acpi_scan_init+0x1f0/0x260
                                spà0000407ff37e20 bspà0000407ff31020
 [<a000000100009710>] init+0x470/0x7e0
                                spà0000407ff37e30 bspà0000407ff30fe8
 [<a000000100012c70>] kernel_thread_helper+0xd0/0x100
                                spà0000407ff37e30 bspà0000407ff30fc0
 [<a000000100009140>] start_kernel_thread+0x20/0x40
                                spà0000407ff37e30 bspà0000407ff30fc0
ACPI: PCI Root Bridge [PCI1] (0000:20)
ACPI: PCI Root Bridge [PCI2] (0000:40)
ACPI: PCI Root Bridge [PCI3] (0000:60)
ACPI: PCI Root Bridge [PCI4] (0000:80)
ACPI: PCI Root Bridge [PCI6] (0000:c0)
Linux Plug and Play Support v0.97 (c) Adam Belay

Re: some new unaligned access while booting ia64 (HP rx2620)

[Robin Holt]

Tony,

Did you compile with CONFIG_DEBUG_INFO?  If so, an
objdump -l --start-address=0xa0000001003afaa0 --stop-address 000001003b0000 vmlinux
would give us an idea of the line number and operation being performed.

Thanks,
Robin


On Fri, Feb 10, 2006 at 04:39:55PM -0800, Luck, Tony wrote:
> kernel unaligned access to 0xe000004040e7263c, ip=0xa0000001003afb00
> Badness in ia64_handle_unaligned at arch/ia64/kernel/unaligned.c:1349

Re: some new unaligned access while booting ia64 (HP rx2620)

[Bjorn Helgaas]

On Thursday 02 February 2006 12:46, Luck, Tony wrote:
> Booting a snapshot of Linus' tree this morning I saw a few (new?)
> kernel unaligned access warnings:
> 
> ACPI: Subsystem revision 20060127
> ACPI: Interpreter enabled
> ACPI: Using IOSAPIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
> kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
> kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
> ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> ACPI: PCI Root Bridge [PCI1] (0000:20)

Did we ever resolve this?  Are we just waiting for new ACPI bits
to trickle into -mm and mainline?

I'd like to see the patch for just this issue, because it affects
SLES10, and Novell might balk at a complete ACPI CA update, but
might take just the individual patch.

Bjorn

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

They should be fixed in ACPICA version 20060217:

Fixed a problem where several resource descriptor types could overrun
the internal descriptor buffer due to size miscalculation: VendorShort,
VendorLong, and Interrupt. This was noticed on IA64 machines, but could
affect all platforms.


> -----Original Message-----
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> Sent: Tuesday, March 14, 2006 4:00 PM
> To: Luck, Tony
> Cc: linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Moore,
Robert;
> Thomas Renninger
> Subject: Re: some new unaligned access while booting ia64 (HP rx2620)
> 
> On Thursday 02 February 2006 12:46, Luck, Tony wrote:
> > Booting a snapshot of Linus' tree this morning I saw a few (new?)
> > kernel unaligned access warnings:
> >
> > ACPI: Subsystem revision 20060127
> > ACPI: Interpreter enabled
> > ACPI: Using IOSAPIC for interrupt routing
> > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
> > kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
> > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
> > ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> > ACPI: PCI Root Bridge [PCI1] (0000:20)
> 
> Did we ever resolve this?  Are we just waiting for new ACPI bits
> to trickle into -mm and mainline?
> 
> I'd like to see the patch for just this issue, because it affects
> SLES10, and Novell might balk at a complete ACPI CA update, but
> might take just the individual patch.
> 
> Bjorn

Re: some new unaligned access while booting ia64 (HP rx2620)

[Bjorn Helgaas]

On Wednesday 15 March 2006 08:47, Moore, Robert wrote:
> They should be fixed in ACPICA version 20060217:
> 
> Fixed a problem where several resource descriptor types could overrun
> the internal descriptor buffer due to size miscalculation: VendorShort,
> VendorLong, and Interrupt. This was noticed on IA64 machines, but could
> affect all platforms.

Did you determine that the buffer overrun problem that caused
the slab corruption was the same thing that caused the unaligned
access messages?

Can you point me to the patch?  Or possibly a place to get the
20060217 ACPICA and the previous version, so I can extract the
patch myself?  I poked around the Intel ACPI web page, but could
only find the most recent ACPICA; there didn't seem to be any
history.

Bjorn

> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > Sent: Tuesday, March 14, 2006 4:00 PM
> > To: Luck, Tony
> > Cc: linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Moore,
> Robert;
> > Thomas Renninger
> > Subject: Re: some new unaligned access while booting ia64 (HP rx2620)
> > 
> > On Thursday 02 February 2006 12:46, Luck, Tony wrote:
> > > Booting a snapshot of Linus' tree this morning I saw a few (new?)
> > > kernel unaligned access warnings:
> > >
> > > ACPI: Subsystem revision 20060127
> > > ACPI: Interpreter enabled
> > > ACPI: Using IOSAPIC for interrupt routing
> > > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003af8c0
> > > kernel unaligned access to 0xe00000407ec5a23c, ip=0xa0000001003af8c0
> > > kernel unaligned access to 0xe00000407ec5a28c, ip=0xa0000001003af8c0
> > > kernel unaligned access to 0xe00000407ec5a1fc, ip=0xa0000001003ae6c1
> > > kernel unaligned access to 0xe00000407ec5a204, ip=0xa0000001003ae6d1
> > > ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> > > ACPI: PCI Root Bridge [PCI1] (0000:20)
> > 
> > Did we ever resolve this?  Are we just waiting for new ACPI bits
> > to trickle into -mm and mainline?
> > 
> > I'd like to see the patch for just this issue, because it affects
> > SLES10, and Novell might balk at a complete ACPI CA update, but
> > might take just the individual patch.
> > 
> > Bjorn
> 

RE: some new unaligned access while booting ia64 (HP rx2620)

[Moore, Robert]

Yes, the reasons are very similar.

Probably best just to wait for the patch to bubble through the pipeline.


> -----Original Message-----
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> Sent: Wednesday, March 15, 2006 8:49 AM
> To: Moore, Robert
> Cc: Luck, Tony; linux-acpi@vger.kernel.org;
linux-ia64@vger.kernel.org;
> Thomas Renninger
> Subject: Re: some new unaligned access while booting ia64 (HP rx2620)
> 
> On Wednesday 15 March 2006 08:47, Moore, Robert wrote:
> > They should be fixed in ACPICA version 20060217:
> >
> > Fixed a problem where several resource descriptor types could
overrun
> > the internal descriptor buffer due to size miscalculation:
VendorShort,
> > VendorLong, and Interrupt. This was noticed on IA64 machines, but
could
> > affect all platforms.
> 
> Did you determine that the buffer overrun problem that caused
> the slab corruption was the same thing that caused the unaligned
> access messages?
> 
> Can you point me to the patch?  Or possibly a place to get the
> 20060217 ACPICA and the previous version, so I can extract the
> patch myself?  I poked around the Intel ACPI web page, but could
> only find the most recent ACPICA; there didn't seem to be any
> history.
> 
> Bjorn
> 
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > > Sent: Tuesday, March 14, 2006 4:00 PM
> > > To: Luck, Tony
> > > Cc: linux-acpi@vger.kernel.org; linux-ia64@vger.kernel.org; Moore,
> > Robert;
> > > Thomas Renninger
> > > Subject: Re: some new unaligned access while booting ia64 (HP
rx2620)
> > >
> > > On Thursday 02 February 2006 12:46, Luck, Tony wrote:
> > > > Booting a snapshot of Linus' tree this morning I saw a few
(new?)
> > > > kernel unaligned access warnings:
> > > >
> > > > ACPI: Subsystem revision 20060127
> > > > ACPI: Interpreter enabled
> > > > ACPI: Using IOSAPIC for interrupt routing
> > > > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > > > kernel unaligned access to 0xe00000407ec5a204,
ip=0xa0000001003af8c0
> > > > kernel unaligned access to 0xe00000407ec5a23c,
ip=0xa0000001003af8c0
> > > > kernel unaligned access to 0xe00000407ec5a28c,
ip=0xa0000001003af8c0
> > > > kernel unaligned access to 0xe00000407ec5a1fc,
ip=0xa0000001003ae6c1
> > > > kernel unaligned access to 0xe00000407ec5a204,
ip=0xa0000001003ae6d1
> > > > ACPI: PCI Interrupt Routing Table [\_SB_.SBA0.PCI0._PRT]
> > > > ACPI: PCI Root Bridge [PCI1] (0000:20)
> > >
> > > Did we ever resolve this?  Are we just waiting for new ACPI bits
> > > to trickle into -mm and mainline?
> > >
> > > I'd like to see the patch for just this issue, because it affects
> > > SLES10, and Novell might balk at a complete ACPI CA update, but
> > > might take just the individual patch.
> > >
> > > Bjorn
> >