Philippe Gerum wrote: > On Thu, 2007-10-04 at 16:06 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Thu, 2007-10-04 at 14:42 +0200, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> On Thu, 2007-10-04 at 11:34 +0200, Philippe Gerum wrote: >>>>>>> Well, this trace also reveals a second bug that can cause nasty priority >>>>>>> inversion: a high-prio domains executes when a fasteoi-IRQ arrives for a >>>>>>> low-prio domain. This will now block all IRQs until the low-prio domain >>>>>>> was able to run its IRQ handler completely. Thus we must _mask_ fasteoi >>>>>>> IRQs for low-prio domains while high-prio ones are running! >>>>>>> >>>>>> This code was actually there up to 2.6.17-1.5-02, and was removed at >>>>>> some point in the 2.6.19 series, due to some severe conflicts with the >>>>>> vanilla IO-APIC support which used to be a hell of a moving target at >>>>>> that time. I guess it's time to bring this code back. >>>>>> >>>>> Does the following work for you? >>>> Will give it a try later. Meanwhile... >>>> >>>>> diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c >>>>> index 2ae79e9..517937b 100644 >>>>> --- a/arch/i386/kernel/io_apic.c >>>>> +++ b/arch/i386/kernel/io_apic.c >>>>> @@ -2022,6 +2022,8 @@ static void ack_ioapic_quirk_irq(unsigned int irq) >>>>> __unmask_and_level_IO_APIC_irq(irq); >>>>> spin_unlock(&ioapic_lock); >>>>> } >>>>> + >>>>> + __mask_IO_APIC_irq(irq); >>>>> } >>>> ...I have problems understanding this hunk. Typo? Should this read >>>> __unmask_IO_APIC_irq? >>>> >>> No, you want to mask it here. EOI in the IO-APIC case goes through some >>> quirks which you want to apply immediately on behalf of the primary >>> I-pipe ack handler, basically to work around some IO-APIC errata. Then, >>> either the high priority domain (__ipipe_end_fasteoi_irq) or the root >>> one (handle_fasteoi_irq) will unmask the IRQ as needed, whichever comes >>> first (and only). >> ack_ioapic_quirk_irq == eio for fasteoi, so it is specifically executed >> on exit of handle_fasteoi_irq. I still don't see why you want to leave >> the IRQ masked here. >> > > It is not executed on IRQ exit anymore when the I-pipe is enabled. The > EOI handler is called earlier in the latter case to ack the LAPIC, then > mask the interrupt source from the IO-APIC, waiting for the Linux > handler to process the device which triggered the interrupt. The source > is eventually unmasked when either the high priority domain or Linux is > done with the interrupt.
Ah, ok, too blind to see the full picture: handle_fasteoi_irq was changed in that direction. Jan (who just kicked off a patched kernel rebuild) -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
