Distribution: 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 f8a00), AE_BAD_PARAMETER 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 console.
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. Thanks, Nish
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 http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/ acpi-20050729-2.6.12.patch.gz For a 2.6.13 (post -rc5) baseline go here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/ acpi-20050729-2.6.13-rc6.diff.gz 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: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
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: 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 `ia64_acpiid_to_sapicid') 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).
Please test the latest ACPI patch, currently: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.13/ acpi-20050902-2.6.13.diff.gz Please also test the latest acpidump, currently in pmtools: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools- 20050823.tar.gz 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 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?
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.
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. Closing. 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.