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.


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to