FS#11174 - kernel 2.6.26.2-1 doesn't boot without acpi=off

Attached to Project: Arch Linux
Opened by Kris Vek (krisvek) - Sunday, 10 August 2008, 23:58 GMT
Last edited by Thomas Bächler (brain0) - Wednesday, 15 October 2008, 13:29 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Arch is running on a Dell Inspiron 1501 laptop. I have had this problem with previous kernel versions and other distros, so maybe it's an upstream thing? Everything booted fine with kernel 2.6.25, but I can't boot up with 2.6.26 without adding acpi=off to GRUB.

Nothing very noteworthy concerning packages other than the kernel: 2.6.26.2-1
This task depends upon

Closed by  Thomas Bächler (brain0)
Wednesday, 15 October 2008, 13:29 GMT
Reason for closing:  Fixed
Comment by Daniel Simionato (weseven) - Monday, 11 August 2008, 10:00 GMT
confirmed, here the problem is with the 2.6.26.2-1 kernel on a HP Pavilion dv6507el. With 2.6.25, all went fine. Same problem in other distros with 2.6.22 kernel i.e. . Btw, the boot seems to freeze without acpi=off, but i can resume it sending the system an acpi signal (= i press the power button and everything keeps going as usual). I guess it's a regression bug in the mainstream kernel, iirc it was a bug corrected in 2.6.25 (maybe earlier version) about broken acpi (dsdt) tables.
Hope this helps,
Daniel
Comment by Thomas Bächler (brain0) - Monday, 11 August 2008, 10:21 GMT
There are several other problems related to sleep()s in the kernel code that cause hangs (in my case, at S3 resume) unless a signal is sent. Could you please report this upstream? ACPI is falling apart since 2.6.24+ and the kernel devs should know this.
Comment by Xavier (shining) - Tuesday, 12 August 2008, 08:09 GMT
I believe I have the same problem when running Arch inside virtualbox (1.6.2).
I get the following:
SMP alternatives: switching to UP code
Freeing SMP alternatives: 9k freed
BUG: unable to handle kernel <1>BUG: unable to handle kernel <1>BUG: unable to handle kernel <1>......

It works nicely with acpi=off, thanks for the tip.
Comment by Simon Hoxer Bønding (burgermann) - Tuesday, 12 August 2008, 18:44 GMT
My system hangs directly after displaying the message: Setting up standard PCI resources

It seems ACPI should have taken over from there but fails. The system's also bootable with acpi=off.
Comment by Kris Vek (krisvek) - Sunday, 24 August 2008, 18:41 GMT
I've checked the kernel.org Bug reports, and I think I've found the same error there. Haven't finished reading through it all yet, but adding "nolapic_timer" to the kernel line should also allow you to boot, if you have the same error as I.

In short, it DOES appear to be a kernel regression. I'll update if there is a solution readily available.
Comment by Xavier (shining) - Sunday, 24 August 2008, 19:05 GMT
I mentioned virtualbox in my comment above, and later found there was a more specific bug report for it :  FS#11141 
Comment by Kris Vek (krisvek) - Sunday, 24 August 2008, 21:24 GMT
I've checked the kernel.org Bug reports, and I think I've found the same error there. Haven't finished reading through it all yet, but adding "nolapic_timer" to the kernel line should also allow you to boot, if you have the same error as I.

In short, it DOES appear to be a kernel regression. I'll update if there is a solution readily available.
Comment by Michael (SiD) - Friday, 29 August 2008, 14:15 GMT
I have a similar problem since I updated to kernel26 2.6.26.3-1 (2.6.26.2 worked for me).
The system does boot, but the initscript takes a long time to do "Loading standard ACPI modules".

System seems to run fine, but when I shutdown with /usr/sbin/halt it shuts down, but doesn't power of the laptop.
Booting the kernel with "nolapic_timer" solve it, but it still takes a long time to load the ACPI modules at boot time.

My Hardware: Acer Extensa 3001 WLMi
Comment by Tobias Powalowski (tpowa) - Saturday, 11 October 2008, 20:36 GMT
status on kernel .27?
Comment by Simon Hoxer Bønding (burgermann) - Wednesday, 15 October 2008, 12:54 GMT
The bugs seems to have perished in .27. I'm requesting closure.
Comment by Daniel Simionato (weseven) - Wednesday, 15 October 2008, 13:24 GMT
confirmed, all works fine.
requesting closure.

Loading...