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?
> 
> 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);
>  }
>  
>  static int ioapic_retrigger_irq(unsigned int irq)
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index ba497a7..1560b4a 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -422,8 +422,13 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc 
> *desc)
>  
>       spin_lock(&desc->lock);
>       desc->status &= ~IRQ_INPROGRESS;
> +#ifdef CONFIG_IPIPE
> +     desc->chip->unmask(irq);
> +out:
> +#else
>  out:
>       desc->chip->eoi(irq);
> +#endif
>  
>       spin_unlock(&desc->lock);
>  }
> @@ -533,11 +538,12 @@ void fastcall __ipipe_end_level_irq(unsigned irq, 
> struct irq_desc *desc)
>  
>  void fastcall __ipipe_ack_fasteoi_irq(unsigned irq, struct irq_desc *desc)
>  {
> +     desc->chip->eoi(irq);
>  }
>  
>  void fastcall __ipipe_end_fasteoi_irq(unsigned irq, struct irq_desc *desc)
>  {
> -     desc->chip->eoi(irq);
> +     desc->chip->unmask(irq);
>  }
>  
>  void fastcall __ipipe_ack_edge_irq(unsigned irq, struct irq_desc *desc)
> 

Good news: The patches seems to stabilise the Xenomai-free use of
I-pipe. I'm writing this mail while compiling a kernel on an
i-pipe-enabled 2.6.22-box.

Bad news: Loading Xenomai still causes a hard reboot after while. Maybe
I was too quick with re-importing the no-COW bits. Now trying to revert
them again to check if they are still involved in nasty page faults...

Jan

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

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to