lxrt task prevents interrupt from occuring

[Suessmilch Bernd]

> -----Original Message-----
> From: rtai-admin at rtai.org [mailto:rtai-admin at rtai.org]On 
> Behalf Of Petr
> Grillinger
> Sent: Montag, 30. Januar 2006 15:30
> To: rtai at rtai.org
> Subject: Re: lxrt task prevents interrupt from occuring
> 
> 
> Petr Grillinger wrote:
> 
> >Hallo,
> >
> >I have a problem with an RTAI interrupt from my network card. The
> >interrupt works nicely when the LXRT tasks in the system 
> leave some CPU
> >time for the interrupt execution, but not when an LXRT task 
> runs in an
> >endless loop (there is no CLI instruction in the task). The interrupt
> >does not occur at all in such case. The LXRT task can still be
> >interrupted by a high priority kernel-mode task, but not by 
> the network
> >interrupt. The network interrupt is registered using 
> rt_request_irq(). I
> >have added debugging code to the ISR and I am certain that it is not
> >active and also that it does not hang in a previous activation.
> >
> >It looks like the timer interrupt is able to preempt the LXRT task to
> >schedule a higher priority task, but my network interrupt is not. Can
> >you help me solve this problem?  It does not make much sense to me.
> >
> >I use the RTAI version 3.1r2 with the kernel 2.6.9, adeos 
> patch r10. The
> >hardware is a Soekris 4521 board with natsemi network card 
> and 586 type
> >CPU. Compiled with gcc 3.3.
> >
> >Thank you and best regards,
> >    Petr Grillinger
> >
> So I can aswer myself now: the problem is a rt_task_resume() 
> call in the
> interrupt handler. The resumed task is started immediately 
> and does not
> allow the interrupt to handler to finish in time.
> 
> Now my problem is different: How can I resume a task from interrupt
> handler in a way that allows the interrupt handler to finish 
> before the
> task is executed?
In RTAI 3.2 and above the solution is easy: just enable RTAI config option
"Base system -> scheduler options -> disable rescheduling from ISRs".
But I am not sure whether this option is already available in 3.1 or not.

Best regards,
Bernd