Bug 4977
Summary: | ACPI 20050708 fails on HP RX2600 platform | ||
---|---|---|---|
Product: | ACPI | Reporter: | Khalid Aziz (khalid) |
Component: | ACPICA-Core | Assignee: | Len Brown (lenb) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | blocking | CC: | acpi-bugzilla, nacc |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.13-rc3-mm3 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | dmesg log |
Description
Khalid Aziz
2005-08-01 08:17:20 UTC
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. |