Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Roland Tollenaar]

>> between RTdevices and non-RT devices crash the system? And whether I
>> understand correctly that later versions (2.4 up?) of xenomai do not
>> have the problem of the freezing system at least.?
> 
> Since Xenomai 2.3, actually, no system is supposed to "crash" anymore
> when IRQ conflicts between the domains arise. But if you loose, e.g.,
> your USB keyboard or your serial console or whatever input device due to
> a conflict, you may get the impression of a crash. However, if anyone
> suspects that something else happens on his system, please report the
> findings to the Xenomai mailing list!

The systems I have found to "crash" all used PS/2 input device and 
normal VGA monitor. Generally a freeze is initiated by some grafical 
action in X after starting rtnet. dmesg will tell me that there is a 
shared IRQ, and in some cases it will disable it. In the latter case the 
system does not freeze but I still have to find another IRQ address. 
When there is a shared interrupt then there might be a freeze. If it 
does not freeze immediately it never freezes and the shared IRQ is no 
problem. For a while I thought there was only a problem with the VGA 
device and the rtnet card so if I kept those two off the same IRQ there 
would be no problem. On other machines this theory was brutally smashed.
Sorry I cannot be more specific here since all problems in the end are 
"solved".

Hmm, I am just considering that since I use live linux it may be that 
the conflict was between the rtnet card and a USBport that gives access 
to the usbstick(s).

But my question remains -purely out of interest- why non-rt devices and 
rt devices can _fundamentally_ not share an IRQ?

kind

regards,

Roland.



> 
> Jan
> 

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Robert Gubler]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

>
> But my question remains -purely out of interest- why non-rt devices and
> rt devices can _fundamentally_ not share an IRQ?
>


My understanding is adeos-ipipe/xenomai provide an interrupt abstraction
layer underneath Linux.  If there is more than one consumer of an interrupt
it has to be copied/forwarded to all those that need it.  If an IRQ is
shared with an RT application, and the Linux kernel I would imagine this
would create some level of indeterministic RT software.

This is probably a good question for the xenomai, or adeos-ipipe mailing
list.  I am new to these packages, so hopefully I am not providing
misinformation on its functionality.

-Rob

[-- Attachment #2: Type: text/html, Size: 854 bytes --]

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Roland Tollenaar]

Hi Rob,

Thanks for this response.

>     But my question remains -purely out of interest- why non-rt devices and
>     rt devices can _fundamentally_ not share an IRQ?
> 
> 
> 
> My understanding is adeos-ipipe/xenomai provide an interrupt abstraction 
> layer underneath Linux.  If there is more than one consumer of an 
> interrupt it has to be copied/forwarded to all those that need it.  If 
> an IRQ is shared with an RT application, and the Linux kernel I would 
> imagine this would create some level of indeterministic RT software.
IRQs are incoming (to the kernel/CPU) signals IIUC. I imagine that at 
the end of these incoming IRQ's sit ISRs just waiting for IRQ and ready 
to respond to it in whatever manner they usually do. If this 
understanding is correct (which it probably is not) then I would not be 
able to conceive of a reason why the IRQ could not be passed on to the 
NON RT interrupt service routine after it has been handled by the 
RT-ISR. But I reiterate that my understanding of these things is as 
sketchy as my interest to improve the sketchiness is big. :)


> This is probably a good question for the xenomai, or adeos-ipipe mailing 
> list. 
Have already done so earlier. I was not aware initially that this thread 
was on the RTnet list. The duplicate and capitalised RTNet in the 
subject must have been mysteriously obscured by my client for a while. :)

Roland

> 
> -Rob

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Robert Gubler]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On 10/27/07, Roland Tollenaar <rwatollenaar@domain.hid> wrote:
>
> Hi Rob,
>
> Thanks for this response.
>
> >     But my question remains -purely out of interest- why non-rt devices
> and
> >     rt devices can _fundamentally_ not share an IRQ?
> >
> >
> >
> > My understanding is adeos-ipipe/xenomai provide an interrupt abstraction
> > layer underneath Linux.  If there is more than one consumer of an
> > interrupt it has to be copied/forwarded to all those that need it.  If
> > an IRQ is shared with an RT application, and the Linux kernel I would
> > imagine this would create some level of indeterministic RT software.


IRQs are incoming (to the kernel/CPU) signals IIUC. I imagine that at
> the end of these incoming IRQ's sit ISRs just waiting for IRQ and ready
> to respond to it in whatever manner they usually do. If this
> understanding is correct (which it probably is not) then I would not be
> able to conceive of a reason why the IRQ could not be passed on to the
> NON RT interrupt service routine after it has been handled by the
> RT-ISR. But I reiterate that my understanding of these things is as
> sketchy as my interest to improve the sketchiness is big. :)


I think the problem is once the RT-ISR passes it to the NON-RT ISR  there
are no real guarantees for how long Linux (its device driver, most likely)
will hold on to the interrupt.  This is problematic if it is causing
scheduling deadlines to be missed.   Its probably not an issue with shared
interrupts between multiple RT applications because (1) the RT apps using it
are (hopefully) written with understanding it is in a real-time context;
this is good peace of mind.  And (2) there is probably some fancy interrupt
masking or priority going on between RT-shared interrupts that make it more
deterministic.

And now for the obligatory I-don't-really-know-what-I'm-talking-about
disclaimer again:

I am new to these packages, so hopefully I am not providing misinformation
on its functionality.

:)

-Rob

[-- Attachment #2: Type: text/html, Size: 2623 bytes --]

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Roland Tollenaar]

>     IRQs are incoming (to the kernel/CPU) signals IIUC. I imagine that at
>     the end of these incoming IRQ's sit ISRs just waiting for IRQ and ready
>     to respond to it in whatever manner they usually do. If this
>     understanding is correct (which it probably is not) then I would not be
>     able to conceive of a reason why the IRQ could not be passed on to the
>     NON RT interrupt service routine after it has been handled by the
>     RT-ISR. But I reiterate that my understanding of these things is as
>     sketchy as my interest to improve the sketchiness is big. :) 
> 
> 
> I think the problem is once the RT-ISR passes it to the NON-RT ISR  
> there are no real guarantees for how long Linux (its device driver, most 
> likely) will hold on to the interrupt.  This is problematic if it is 
This corresponds to what I have understood of what happens when a 
rt-thread makes an excursion to the the non-RT world. So there may be 
truth in what you say. Only, what I then don't understand is this: There 
is no problem with the non-RT-ISR doing its thing under normal (read no 
IRQ sharing) circumstances. So I would not see why passing the IRQ to 
the non-RT-ISR once the RT-ISR has done its job would be any different 
to the situation where there is no sharing. The situation is IMHO not 
analogous to the "excursion" of a RT thread into non-rt world as would 
be the case for example if a rt-thread called a non-rt-safe driver. IOW 
passing on an IRQ does not imply that a rt-thread steps into non-rt 
world. Rather it jsut gives the non-RT world the opportunity to respond 
to its devices as it would have naturally done without a problem when it 
gets its IRQ outside xenomai's realm. I assume (due to the fact that the 
rt-monitored IRQ's can be found in /proc/xenomai/irq IIRC) that the rest 
of the IRQ's are not filtered/censured through adeos.

Maybe the explanation is as follows: There is no problem to the point 
where the nonRT-ISR gets and responds to the IRQ. But what happens if 
,during the execution of the non-RT-ISR after it has been passed the 
IRQ, the RTdevice evokes another IRQ? Then adeos must give this IRQ to 
the RT-ISR and give it precedence over the Non-RT-ISR. If the non-RT-ISR 
is atomic or non-pre-emptible (not sure that is not the same thing or 
that I am not talking out of my hat here) this might be a problem. But 
again  I would not see why this is then not a problem  under the 
aforementioned "normal" circumstances. So I remain confused.

Roland.

> And now for the obligatory I-don't-really-know-what-I'm-talking-about 
> disclaimer again:



> 
> I am new to these packages, so hopefully I am not providing 
> misinformation on its functionality.
> 
> :)
> 
> -Rob
> 
>  
> 

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

Robert Gubler wrote:
> On 10/27/07, Roland Tollenaar <rwatollenaar@domain.hid> wrote:
>> Hi Rob,
>>
>> Thanks for this response.
>>
>>>     But my question remains -purely out of interest- why non-rt devices
>> and
>>>     rt devices can _fundamentally_ not share an IRQ?
>>>
>>>
>>>
>>> My understanding is adeos-ipipe/xenomai provide an interrupt abstraction
>>> layer underneath Linux.  If there is more than one consumer of an
>>> interrupt it has to be copied/forwarded to all those that need it.  If
>>> an IRQ is shared with an RT application, and the Linux kernel I would
>>> imagine this would create some level of indeterministic RT software.
> 
> 
> IRQs are incoming (to the kernel/CPU) signals IIUC. I imagine that at
>> the end of these incoming IRQ's sit ISRs just waiting for IRQ and ready
>> to respond to it in whatever manner they usually do. If this
>> understanding is correct (which it probably is not) then I would not be
>> able to conceive of a reason why the IRQ could not be passed on to the
>> NON RT interrupt service routine after it has been handled by the
>> RT-ISR. But I reiterate that my understanding of these things is as
>> sketchy as my interest to improve the sketchiness is big. :)
> 
> 
> I think the problem is once the RT-ISR passes it to the NON-RT ISR  there
> are no real guarantees for how long Linux (its device driver, most likely)
> will hold on to the interrupt.  This is problematic if it is causing
> scheduling deadlines to be missed.   Its probably not an issue with shared
> interrupts between multiple RT applications because (1) the RT apps using it
> are (hopefully) written with understanding it is in a real-time context;
> this is good peace of mind.  And (2) there is probably some fancy interrupt
> masking or priority going on between RT-shared interrupts that make it more
> deterministic.
> 
> And now for the obligatory I-don't-really-know-what-I'm-talking-about
> disclaimer again:
> 
> I am new to these packages, so hopefully I am not providing misinformation
> on its functionality.
> 
> :)

You're providing very accurate explanations in fact! And if you or
Roland things have the impression that the related FAQ entry on
xenomai.org is not the clear, please enhance it!

One further note on why it is hard to handle cross-domain-shared IRQs:
For the non-RT user, you always need a minimal (and, of course,
deterministic) IRQ handling stub in the RT domain that shut ups the IRQ
at device level and then forward it for later handling to the non-RT
domain. We a) have no really smart way for forwarding the IRQ at the
moment (*) and we b) would then still have to maintain those
hardware-specific stubs, which we cannot do for each and every Linux
driver out there.

Jan

(*) You currently need an additional virtual IRQ. Reusing the Adeos
pipeline with the same IRQ line is a yet unimplemented idea of mine for
a smarter alternative.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Roland Tollenaar wrote:
>>> between RTdevices and non-RT devices crash the system? And whether I
>>> understand correctly that later versions (2.4 up?) of xenomai do not
>>> have the problem of the freezing system at least.?
>> Since Xenomai 2.3, actually, no system is supposed to "crash" anymore
>> when IRQ conflicts between the domains arise. But if you loose, e.g.,
>> your USB keyboard or your serial console or whatever input device due to
>> a conflict, you may get the impression of a crash. However, if anyone
>> suspects that something else happens on his system, please report the
>> findings to the Xenomai mailing list!
> 
> The systems I have found to "crash" all used PS/2 input device and 
> normal VGA monitor. Generally a freeze is initiated by some grafical 
> action in X after starting rtnet. dmesg will tell me that there is a 

If there is a conflict with your graphic adapter, using a VESA X driver
or disabling acceleration (Option "NoAccel") should remove the need to
use the related IRQ under Linux.

> shared IRQ, and in some cases it will disable it. In the latter case the 
> system does not freeze but I still have to find another IRQ address. 
> When there is a shared interrupt then there might be a freeze. If it 
> does not freeze immediately it never freezes and the shared IRQ is no 
> problem. For a while I thought there was only a problem with the VGA 
> device and the rtnet card so if I kept those two off the same IRQ there 
> would be no problem. On other machines this theory was brutally smashed.
> Sorry I cannot be more specific here since all problems in the end are 
> "solved".
> 
> Hmm, I am just considering that since I use live linux it may be that 
> the conflict was between the rtnet card and a USBport that gives access 
> to the usbstick(s).
> 
> But my question remains -purely out of interest- why non-rt devices and 
> rt devices can _fundamentally_ not share an IRQ?
> 
> kind
> 
> regards,
> 
> Roland.
> 
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]