Kernel Bug Tracker – Bug 4977
ACPI 20050708 fails on HP RX2600 platform
Last modified: 2006-09-28 13:19:54 UTC
Debian Sarge 3.1
HP RX2600, Dual Mckinley processors
Debian Sarge userspace with 2.6.13-rc3-mm3 kernel
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
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
Please see the thread at
<http://www.ussg.iu.edu/hypermail/linux/kernel/0507.3/1773.html> for details.
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.
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.
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.
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:
does 2.6.13-rc6 work?
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:
make: `arch/ia64/kernel/asm-offsets.s' is up to date.
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: *** [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).
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.
Created attachment 5935 [details]
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?
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
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.