When booting with ACPI support enabled, I received the following message: Booting 'Gentoo (bzImage-2.6.28-hardened-r9)' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel (hd0,0)/boot/bzImage-2.6.28-hardened-r9 root=/dev/sda4 [Linux-bzImaeg, setup=0x2a00, size=0x165990] Decompressing Linux... Parsing ELF... done. Booting the kernel. Reproducible: Always Steps to Reproduce: 1.Configure kernel with [x]Power Management -> [x] ACPI Support 2.Reboot 3.System hangs Actual Results: System hangs with: Booting 'Gentoo (bzImage-2.6.28-hardened-r9)' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel (hd0,0)/boot/bzImage-2.6.28-hardened-r9 root=/dev/sda4 [Linux-bzImaeg, setup=0x2a00, size=0x165990] Decompressing Linux... Parsing ELF... done. Booting the kernel. Expected Results: A bootable machine. ACPI has been enabled for years on this box. Prior kernel hardened-sources-2.6.28-r7 with ACPI support boots fine. I do have PAX and Grsecurity enabled. I initially suspected that and removed those features, and it would not boot. It's definitely related to ACPI. Here is my emerge --info Portage 2.1.6.11 (default/linux/x86/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.28-hardened-r9 i686) ================================================================= System uname: Linux-2.6.28-hardened-r9-i686-Intel-R-_Pentium-R-_4_CPU_2.80GHz-with-glibc2.0 Timestamp of tree: Sun, 31 May 2009 07:00:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.7 dev-lang/python: 2.5.4-r2 dev-python/pycrypto: 2.0.1-r8 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.4.3-r4, 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl apache2 berkdb bzip2 cli cracklib crypt dri fortran gdbm iconv isdnlog midi mudflap mysql ncurses nptl nptlonly openmp pam pcre perl php pppd python readline reflection sasl session snortsam spl ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="threads" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Let me know if you'd like me to attach my config
(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.
