Eric W. Biederman wrote: > Jon Masters <jcm@xxxxxxxxxx> writes: > >> On Wed, 2009-01-14 at 12:40 +0100, Ingo Molnar wrote: >> >>> it's not just -rt, but it is also needed for the concept of threaded IRQ >>> handlers - which was discussed at the Kernel Summit to be desired for >>> mainline. >> Right. I'm poking at Thomas' patches and hope to post something soon on >> that front - I'm acutely aware that this will be impacted aswell but >> because it's vaguely RT related had banded it under that banner. > > Stepping back a moment. The only way I can see this working reliably > is if we disable the boot interrupt. Anything that leaves the boot interrupt > enabled means that when we disable the primary interrupt the boot interrupt > will scream, and thus we must disable it as well. Disabling Boot Interrupts is our goal, if they don't appear everything is fine. Now if you take a closer look at United States Patent 6466998 you can read that there has to be a way to disable Boot Interrupts on APIC aware OSes. Let me back this up with a quote from that patent: "Therefore, 8259 PIC may be incorporated into a system board along with the APIC system to ensure proper operation of an operating system (OS) regardless whether such an operating system (OS) may or may not support an APIC system. However, external logic devices are required to route particular interrupts from a non-legacy peripheral bus to the 8259 PIC. General purpose I/O pins are then needed to enable/disable this functionality once an operating system (OS) which understands the APIC system is loaded." We already managed to successfully disable Boot Interrupt generation on several chipsets. See the following posts: http://lkml.org/lkml/2008/7/8/213 http://lkml.org/lkml/2008/7/8/215 http://lkml.org/lkml/2008/6/2/270 What makes things complicated is that we have to deal with buggy hardware which can't disable the generation of Boot Interrupts, that's why we introduced the reroute to legacy interrupt patch. > Which leads to my problem with the entire development process of this feature. > > People want the feature. > People don't want to pay attention to the limits of the hardware. > Which leads to countless broken patches proposed. Sorry if you feel that way, really trying to pay attention to hardware limitations here. I bet you have a lot more experience in this field than I have, so please let me know what technical reasons you see for this being a dead end. > Which leads me to conclude. > - IRQ handling in the RT kernel is hopelessly broken. > - IRQ threads are a bad idea. > > Because it is all leading to stupid patches and stupid development. > > None of this works reliably on level triggered ioapic irqs. We're trying really hard to make it work reliably, but this is a complicated matter and it sure needs a lot of research. > > Eric Stefan -- Stefan Assmann | SUSE LINUX Products GmbH Software Engineer | Maxfeldstr. 5, D-90409 Nuernberg Mail: sassmann@xxxxxxx | GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
