Summary: | sys-kernel/hardened-sources-2.6.28-r9 won't boot with ACPI support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | lou <whitehatcheck> |
Component: | [OLD] Core system | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | brayan, bugs.gentoo.devel, kernel, kfm, klondike, vahur.sinijarv |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Config that has ACPI.. and does not boot
Config that boots. ACPI is removed dmesg from successful boot without ACPI dmesg from successful boot with ACPI of 2.6.28-r7 The original DSDT. The change I made to the DSDT to eliminate the compile error. Output from lspci -vv |
Description
lou
2009-06-01 01:26:29 UTC
(In reply to comment #0) > > Let me know if you'd like me to attach my config Yes, please. By the way, please don't CC maintainers/herds yourself. Leave that to the bug-wranglers. Created attachment 193739 [details]
Config that has ACPI.. and does not boot
Created attachment 193741 [details]
Config that boots. ACPI is removed
> > Let me know if you'd like me to attach my config > > Yes, please. Added both working and non-working configs. > By the way, please don't CC maintainers/herds yourself. Leave that to the > bug-wranglers. I don't think I CC'd anyone when I created the bug.. I just created the report. Let me know if this is a setting or something, and I'll adjust. Thanks! I've got this same problem, and can confirm that removing ACPI allows a boot (though this being a laptop, it's useless as a workaround). I'll attach a DMESG from booting 2.6.28-r9 with ACPI disabled. Created attachment 193773 [details]
dmesg from successful boot without ACPI
Created attachment 193828 [details]
dmesg from successful boot with ACPI of 2.6.28-r7
Forgot to do this earlier: this might show something interesting in the ACPI messages.
I see that your DSDT was compiled with the Microsoft compiler (MSFT in your dmesg log), which may be causing your issue. Would you be kind enough to check this forum thread: http://forums.gentoo.org/viewtopic.php?t=122145 to diagnose if your DSDT is indeed problematic (and possibly even fix it)? Thanks! I will test the DSDT hack shortly. For now, though, I do have the following data point to note: near the end of the compilation of the kernel, there's a warning message about "section mismatches". For -r7, there is one section mismatch reported. For -r9, there are 3028 (over *THREE THOUSAND*) section mismatches. I tried the DSDT hack (it looks like the necessary config option is already in the kernel). It didn't help. I will post my original DSDT and a diff showing my changes. Created attachment 194347 [details]
The original DSDT.
Compilation output from iasl is:
dsdt-orig.dsl 3197: Wait (\_SB.PCI0.PCIB.DKSQ, 0x0BB8)
Warning 1104 - Possible operator timeout is ignored ^
dsdt-orig.dsl 3217: Wait (\_SB.PCI0.PCIB.DKSQ, 0x1388)
Warning 1104 - Possible operator timeout is ignored ^
dsdt-orig.dsl 3377: Increment (Local0)
Error 4050 - ^ Method local variable is not initialized (Local0)
Created attachment 194348 [details, diff]
The change I made to the DSDT to eliminate the compile error.
(In reply to comment #12) > Created an attachment (id=194348) [edit] > The change I made to the DSDT to eliminate the compile warning. > (sorry, I meant the compile *error* - the warnings are still there) Probably a regression, not a problem with your DSDT. Please attach the output of lspci -vv. Also, can you try 2.6.29 and see if you experience the same issue? Created attachment 194439 [details]
Output from lspci -vv
2.6.29 boots fine! Now to mask -r9 and wait for 29 to go stable :) Hi, 2.6.29 probably won't ever go stable and 2.6.30 is just starting out. I'll probably end up supporting 2.6.28 for awhile. When I get some time (scarce unfortunately :( ) I'll see if I can't find the regression *if* you are willing to test patches (please) for me since I cannot reproduce this issue. Please let me know. Thanks. Sure, I can test patches. I think the bug is caused by the changes introduced in "arch/x86/kernel/acpi/sleep.c" in fact, reverting that file to the r7 version solved the bug for me. In case this helps the diff between both files is: diff linux-2.6.28-hardened-r7/arch/x86/kernel/acpi/sleep.c linux-2.6.28-hardened-r9/arch/x86/kernel/acpi/sleep.c 13a14 > #include <asm/e820.h> 18c19 < unsigned long acpi_wakeup_address; --- > unsigned long acpi_wakeup_address = 0x2000; 150,157c151,152 < acpi_realmode = (unsigned long)alloc_bootmem_low(WAKEUP_SIZE); < < if (!acpi_realmode) { < printk(KERN_ERR "ACPI: Cannot allocate lowmem, S3 disabled.\n"); < return; < } < < acpi_wakeup_address = virt_to_phys((void *)acpi_realmode); --- > reserve_early(acpi_wakeup_address, acpi_wakeup_address + WAKEUP_SIZE, "ACPI Wakeup Code"); > acpi_realmode = (unsigned long)__va(acpi_wakeup_address);; But I have no idea on the effect those changes had on the overall kernel code :( klondike's patch solves this for me. The thus-modified kernel does at least boot and run fine for the couple of minutes I've tested. (In reply to comment #21) > klondike's patch solves this for me. The thus-modified kernel does at least > boot and run fine for the couple of minutes I've tested. > Does your system boot with the latest stable kernel (gentoo-sources-2.6.30-r5)? The 2.6.30 should work as the code causing the problem seems to come from the pax patches: http://www.grsecurity.net/test/pax-linux-2.6.28.10-test26.patch Maybe we should post this bug upstream. (In reply to comment #23) > The 2.6.30 should work as the code causing the problem seems to come from the > pax patches: http://www.grsecurity.net/test/pax-linux-2.6.28.10-test26.patch > > Maybe we should post this bug upstream. > I don't think that upstream will be really interested in an issue regarding the 2.6.28 kernel version, since it's fixed in 2.6.29. What we should do, is backport the patch for 2.6.28 and ship it with gentoo-sources-2.6.28*. I'll try to do it later tonight or tomorrow. That way everyone is happy and we can close this bug :3 PS: If you feel like it, you can certainly post the bug upstream, but I think it will be better to let it pass, since it's concerning a quite outdated kernel release (especially for the upstream standards). Thanks! (In reply to comment #24) > I don't think that upstream will be really interested in an issue regarding the > 2.6.28 kernel version, since it's fixed in 2.6.29. The problem is that the affected sources are not the gentoo ones but the hardened ones and when talking by upstream I meant the PAX team and not the linux kernel developers. > What we should do, is backport the patch for 2.6.28 and ship it with > gentoo-sources-2.6.28*. I'll try to do it later tonight or tomorrow. I don't think that would solve the bug as the problem is inserted by the PAX patch used on hardened gentoos. Anyway I can give a try to gentoo-sources-2.6.28 (if it is still avaiable) and check if the bug happens there, but I doubt it much :/ Thanks for taking your time anyway ^^ I have tried gentoo sources 2.6.30 and it booted without any problem. I still think the problem is on the PAZ patch anyway :/ It is part of PAX patch and it doesn't need to be reported upstream because the problem shouldn't be in their latest patches either. We will take care of reporting upstream if/when necessary. As you can see on the latest patch: http://www.grsecurity.net/test/pax-linux-2.6.30.5-test28.patch the changes to the acpi/sleep.c remain the same so I don't have much faith that the bug has been solved. Anyway as I haven't tested 2.6.30 neither 2.6.29 I can't assure this will solve the problem. Though I still think somebody should check why this changes have been made. (In reply to comment #28) > As you can see on the latest patch: > http://www.grsecurity.net/test/pax-linux-2.6.30.5-test28.patch the changes to > the acpi/sleep.c remain the same so I don't have much faith that the bug has > been solved. > > Anyway as I haven't tested 2.6.30 neither 2.6.29 I can't assure this will solve > the problem. Though I still think somebody should check why this changes have > been made. > This is most likely due to the compiler not being utilized properly by the kernels cc checks. If you can duplicate this with gcc vanilla profile and let everyone know it would make it alot easier to understand why the code is breaking. I just ran info this problem a few weeks ago and can confirm the same results: 2.6.28-r7 works, 2.6.28-r9 won't boot, but 2.6.29 (~x86) works. This is all with hardened-sources. So does this mean the bug has been fixed, or was something backported or patched into .28-r9 that isn't in .29 yet? I'm updating this, as this is still reproducible with the recently stabilized gcc 4.3 toolchain. IMHO this bug is due to either, A bad usage of the reserve_early function as it is not panicquing instead of throwing an error if the address is properly reserved. Picking up on this bug. Its not clear from Comments #27 forward whether this was fixed in the PaX patches or not. Can someone confirm whether the problem is persisting in the latest stable hardened sources 2.6.32-r9? 2.6.32-r9 does not have the problem and boots fine for me on two machines that experienced the problem with 2.6.28-r9 I'll try ASAIC I hope in a week tops :-) Thanks for the hard work blueness. Upgraded the server, tried and the bug has vanished :D Thanks again for the work hardened team. Two confirmed resolutions with 2.6.32-r9. I'm closing this one even though we haven't deprecated 2.6.28-r9 yet. The recommendation will be to upgrade for anyone else hitting up against this bug. |