hda: lost interrupt

i remember hackus had some problems with his apic while trying to use redhat 9. i think a lot of sagers have a faulty apic. (and now that i think about it, it could very well be a design flaw; and may even be responsible for the whole 'hang on install' problem during autodetection)

the Local Advanced Programmable Interrupt Controller is a component of the processor for generating and accepting interrupts, and is also a timer. the I/O APIC is a separate chip linked to the local apic that handles forwarding of interrupts to specific cpus in a multiprocessor system. so yes, it is related to smp - when you enable smp, both the Local APIC and the I/O APIC are automatically enabled; smp needs it, after all. when you disable smp, you should see a couple options, 'Local APIC on uniprocessor systems' and 'i/o apic support' or something like that. i can't recall what the third one is at the moment. that's the way it is in 2.4; i'm not sure what it is in 2.2, never bothered with that series.

(sorry if this is obvious info that everyone knew)

actually, if the i/o apic is a separate chip for forwarding interrupts, and it's enabled with smp... we only have one processor, though, because we're only hyperthreading... could that be a problem, trying to route to a different cpu when there's only one? or maybe it's a problem because uniprocessor motherboards don't usually have an i/o apic? i'm not a computer hardware architect, so i don't know. just speculating at this point.

i think it's been fixed in 2.6 because the dev tree has a lot of hyperthreading enhancements and fixes... hyperthreading (as a viable home consumer option) is so new that the patches probably haven't made their way into 2.4.

hmm, i've never heard that before. compiling smp in regardless, i mean. i know that it changes the way that almost everything is compiled, though... and it could possibly add more overhead (trying to distribute and schedule parallel threads evenly when there's no need to). i don't know for sure, though. it wouldn't break with one cpu because it doesn't have to do any irq routing at all. but with hyperthreading enabled, it essentially sees two logical cpus - so the kernel (a non-hyperthreading-aware one like 2.4) may see that and try to call the i/o apic to route to each cpu in separate places when they are, in fact, both the same cpu in the same place. dunno, whatever, i'm not an smp expert.

if you disabled the local apic, then it would possibly still support smp... some motherboards have that functionality (or something similar) built in to work in place of a local apic. the question, then, is whether ours have that...

eh, whatever. i've officially switched to the dev kernels and have compiled my system with nptl and converted my lvm to lvm2, so i really can't turn back to 2.4 even if i wanted to. it's not really a big deal for me anymore.

although, as always, i'm still curious about the actual truth behind this. the quest for linux knowledge and all that...

my 2 cents:
Somewhere in the Kernel-HOWTO (i think), there is a recommendation to always use SMP. Doesn't say why, just says its a good idea. If anyone knows why I would be interested to know...

I had the same problem. A kernel built using vanilla-sources with SMP enabled would never boot, although a non-SMP kernel would. I found that using the gentoo-sources kernel I am able to boot with SMP. The only problem I have seen with the gentoo-sources kernel is that my 8139too card does not work. (Most likely I messed up the kernel build) That is a story for a different thread.

Thanks for the noapic boot option, that solves many of my problems.

David Stanek