Kernel Bug Tracker – Bug 5331
Can't boot SMP kernel >=2.6.13
Last modified: 2006-09-06 09:01:19 UTC
Most recent kernel where this bug did not occur: 22.214.171.124 (haven't tried any
other from 2.6.12 series)
Distribution: Fedora Core 4
Hardware Environment: P4 3.06GHz HT revision 09
Problem Description: If I boot an SMP version of >=2.6.13 kernel, depending on
the boot options it either hangs or boots up to a certain point very very slowly.
Steps to reproduce:
1. Build an SMP vanilla kernel >=2.6.13
2. Boot it
I have also posted here http://bugzilla.kernel.org/show_bug.cgi?id=5171 but it
seems to be another bug.
-If I boot the kernel with the noapic option as I do with the 126.96.36.199 kernel,
it hangs hard at:
'isapnp:Scanning for PnP cards...'
-If I boot the kernel with no option, it boot very very slowly up to 'Starting
udev...' where it just stays (waited at least 10 minutes) until I press CTRL+C
and then continues still very slowly but everything fails because the root
device is mounted read-only up to a point where it stops but doesn't hang.
Created attachment 6188 [details]
Dmesg of 188.8.131.52 kernel
This is the dmesg of the working kernel. Unfortunately I can't post the dmesg
of the non-working kernel but while booting I don't see any oops or another
please test the patch in bug 5165
if that doesn't work, does booting with "idle=poll" help,
or how about disabling acpi/processor.ko altogether?
The patch in the other bug didn't work (kernel 184.108.40.206) but the idle=poll
Unfortunately I had another problem with some irq (?) but that was sorted out
with irqpoll boot option. I don't know if this was related to the first option I
Just to note here that after using idle=poll my cpu is heating more which I
guess is because it doesn't go into a lower state.
Hope you guys fix this bug quickly. Cheers
When does the slowness start?
Is it from the beginning of the boot or it goes at normal speed until some point
and then starts to slow down?
Does "processor.max_cstate=1" boot parameter help?
The "processor.max_cstate=1" option works fine and doesn't cause the cpu to
The slowness seems to start from the beginning.
> If I boot the kernel with the noapic option as I do with the 220.127.116.11
Why were you using "noapic" on 2.6.12?
Does the system work properly if booted with just "maxcpus=1"?
Please reopen the bug if you can provide the requested information.