Bug 4977 - ACPI 20050708 fails on HP RX2600 platform
ACPI 20050708 fails on HP RX2600 platform
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core
i386 Linux
: P2 blocking
Assigned To: Len Brown
Depends on:
  Show dependency treegraph
Reported: 2005-08-01 08:17 UTC by Khalid Aziz
Modified: 2006-09-28 13:19 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.13-rc3-mm3
Tree: Mainline
Regression: ---

dmesg log (8.36 KB, text/plain)
2005-09-08 11:27 UTC, Bjorn Helgaas

Description Khalid Aziz 2005-08-01 08:17:20 UTC
          Debian Sarge 3.1

Hardware Environment:
          HP RX2600, Dual Mckinley processors

Software Environment:
          Debian Sarge userspace with 2.6.13-rc3-mm3 kernel

Problem Description:
    2.6.13-rc3-mm3 kernel fails to boot on RX2600 since it fails to find a
console device. Failure to find a tty device for console happens because ACPI
fails and this results in kernel not being able to scan PCI bus and set
interrupt routing. Here is a snippet of bootup messages showing failure:

ACPI: bus type pci registered
ACPI: Subsystem revision 20050708
    ACPI-0509: *** Error: Method execution failed [\PARS.GFIT] (Node e0000002fff
    ACPI-0509: *** Error: Method execution failed [\_SB_.SBA0._INI] (Node e00000
02ffffa780), AE_BAD_PARAMETER
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing

Steps to reproduce:
    Build a kernel with defconfig and try to boot on an HP RX2600 with serial
Comment 1 Khalid Aziz 2005-08-01 08:22:05 UTC
Please see the thread at
<http://www.ussg.iu.edu/hypermail/linux/kernel/0507.3/1773.html> for details.
Comment 2 Nishanth Aravamudan 2005-08-01 09:04:32 UTC
Does the same problem exist in 2.6.13-rc4-mm1? I know akpm dropped many ACPI
patches in rc4-mm1 relative to rc3-mm3.

Thanks, Nish
Comment 3 Khalid Aziz 2005-08-01 13:59:36 UTC
This problem does not exist in 2.6.13-rc4-mm1, but then the ACPI version in
2.6.13-rc4-mm1 in 20050408, not 20050708.
Comment 4 Andrew Morton 2005-08-04 17:06:31 UTC
I'll include the latest acpi tree in mext -mm.  Please let us know how tht goes.

We do seem to have several problems in the ACPI devel tree.
Comment 5 Len Brown 2005-08-04 23:18:49 UTC
Good to know that 2.6.13-rc3 works fine.
Does 2.6.13-rc5 and later work fine too?

Is it possible to test the latest ACPI code against Linus' vanilla kernel (eg. 
outside the context of the -mm patch?)

For a 2.6.12 baseline go here

For a 2.6.13 (post -rc5) baseline go here:

It is possible that this is related to the module-level-code issue.
Note that we disabled module-level-code between 0708 and 0729 patches.
We could confirm that by disassembling your DSDT.  Is it possible
to attach the output from acpidump for this box?
acpidump can be found in in the latest pmtools here:

Comment 6 Len Brown 2005-08-11 22:20:22 UTC
does 2.6.13-rc6 work?
Comment 7 Khalid Aziz 2005-08-15 12:31:06 UTC
2.6.13-rc6 works fine which still has the old 20050408 ACPI. 2.6.13-rc6 with
acpi-20050729-2.6.13-rc6.diff.gz patch fails to build:

  CHK     include/linux/version.h
make[1]: `arch/ia64/kernel/asm-offsets.s' is up to date.
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  CC      arch/ia64/kernel/acpi.o
arch/ia64/kernel/acpi.c:77:44: too many decimal points in number
arch/ia64/kernel/acpi.c:77: error: nonconstant array index in initializer
arch/ia64/kernel/acpi.c:77: error: (near initialization for
arch/ia64/kernel/acpi.c:141:10: too many decimal points in number
arch/ia64/kernel/acpi.c:141: error: nonconstant array index in initializer
arch/ia64/kernel/acpi.c:141: error: (near initialization for `platform_intr_list')
make[1]: *** [arch/ia64/kernel/acpi.o] Error 1
make: *** [arch/ia64/kernel] Error 2

acpidump does not seem to work on this machione. It compiles fine with multiple
warnings "cast to pointer from integer of different size". When I run acpidump,
it returns immediately with no output. Exit code is set to 5 (EIO).
Comment 8 Len Brown 2005-09-08 00:44:00 UTC
Please test the latest ACPI patch, currently:

Please also test the latest acpidump, currently in pmtools:

As I mentioned above, it is likely that this error was due
to the module-level code issue.  Should be able to confirm
that suspicion with acpidump output.
We believe the module-level-code issue is fixed in ACPICA 20050902 above.
Comment 9 Bjorn Helgaas 2005-09-08 11:27:59 UTC
Created attachment 5935 [details]
dmesg log

dmesg from 2.6.13 + acpi-20050902-2.6.13.diff.gz on HP zx6000 (essentially
the same as zx2600).  Everything looks fine to me.

(BTW, the acpi patch didn't apply cleanly to 2.6.13.  But the rejects
didn't look serious, so I didn't fix any.)

I also tested pmtools-20050823, which worked fine.

I think this bug can be closed.  Khalid?
Comment 10 Khalid Aziz 2005-09-08 13:09:32 UTC
Since Bjorn's testing shows ACPI 20050902 works, we can close this bug. It would
be a good idea to update this bug with the kernel version ACPI 20050902 gets
incorporated in.
Comment 11 Len Brown 2005-09-08 13:38:56 UTC
Thanks for verifying that the patch works.

It is in Linus' git tree as of today, so it should be
included in kernel.org's 2.6.13-git9 snapshot.

yes, the patch not applying cleanly is due to it being against
Linus' top of tree, which is still called 2.6.13 -- even though
it is newer than 2.6.13 final.  benh asked Linus if he could update
the kernel Makefile upon cutting a release to avoid exactly this
issue between 2.6.X and 2.6.X+1-rc1, but he didn't see the need.

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