Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

[Olaf Dabrunz <od@suse.de>]

On 14-Jan-09, Jon Masters wrote:
> On Wed, 2009-01-14 at 14:42 -0800, Eric W. Biederman wrote:
> > Jon Masters <jcm@redhat.com> 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.
> > 
> > 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.
> 
> Is a patch broken because hardware has limitations? If that were always
> true then many of the patches we see in the kernel wouldn't be there.
> 
> > Which leads me to conclude.
> > - IRQ handling in the RT kernel is hopelessly broken.
> 
> Nope. It's done in a very similar way to other real time kernels already
> out there - really there are only so many ways to do this.
> 
> > - IRQ threads are a bad idea.
> 
> Why? IRQ threads actually make life so much easier - you have a task
> context, you can do everything inside that rather than scheduling all
> kinds of deferred work (that in RT will be done in another task later),
> and so forth.
> 
> > None of this works reliably on level triggered ioapic irqs.

Actually it works very well. The patches are also not _that_
complicated. We have two kinds of patches:

    1) if possible on the chipset, disable boot irqs (if in APIC mode)

       - this works as designed and has no problems

       - we cover up for broken BIOSes here that forget to disable boot
         irqs

    2) if we cannot disable boot irqs, disable the original interrupt
       line and only use the boot irq line -> no duplicated interrupts,
       but increased interrupt sharing

       - this is a hack for older, but widely used chipsets

       - we cover up for broken hardware (wrt threaded IRQ handling)

       - when the broken hardware falls out of use, this is not needed
         anymore


The only limitations we have so far:

    - For newer chipsets, we have to make sure that we find the disable
      bit. Vendors should put this bit in a common place.

    - It is a lot of work to describe all of the findings and
      experimental results we had, in a digestable way.

> Level triggered IOAPIC IRQs have quirks, film at 11!

Love this. *grin* :)

-- 
Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html