Re: Problem activating multiple cores ONLY if I press any key before kernel is loaded

[Robert Hancock <hancockr@shaw.ca>]

S K wrote:
> Hi,
> 
> This is 100% reproducible. I'm using a Shuttle SG33G5, Q9300 (45nm)
> and Fedora 9 with kernel 2.6.25.3-18.fc9.i686.
> 
> When the PC boots up, if I don't press any key till I see "Redhat nash
> version..." everything works fine (well, good enough).
> 
> But if I press a key during the boot and end up inside GRUB boot menu
> and choose Linux (Linux is the default), the boot hangs after the line
> "Booting the kernel." and before "Redhat nash..." is displayed.
> 
> So I went into GRUB and removed the "quiet" kernel option to see
> what's happening. I saw some errors (posted at end of email) and I
> waited for a while (1-2 mins?) and the boot continued. But only one
> core was activated. I saw several such thread on many websites and
> most suggested "noapic" and "nolapic" and some also suggested
> "acpi=off".
> 
> If I added "noapic nolapic acpi=off" using the GRUB menu, the boots
> succeeds 1 out of may be 5 times with all cores active.
> 
> Just using "acpi=off" or just "noapic nolapic" didn't help -- it could
> have been intermittent, but I didn't try these many times.
> 
> I'm mailing LKML because the "fix" given in other websites is
> intermittent and not always working.
> 
> This is a new PC and I have my old one which is my primary PC till I
> get the new one working fine. So I'm willing to do any kind of tests
> on my new PC. This might be a good test oppurtunity for kernel
> programmers.
> 
> Please let me know if there is a known fix that work all the time or
> if you are interested having your fix/patch tested on my PC.
> 
> Thanks,
> SK
> P.S: Relevant output of dmesg follows.
> 
> I see this in dmesg:
> CPU 1 irqstacks, hard=c07ba000 soft=c079a000
> Not responding.
> Inquiring remote APIC #1...
> .. APIC #1 ID: failed
> .. APIC #1 VERSION: failed
> .. APIC #1 SPIV: failed
> CPU #1 not responding - cannot use it.

Is this a USB keyboard? Might be that pressing keys before the kernel 
does the USB handoff from BIOS/SMI causes the BIOS to do something that 
screws things up..