Thread: [RTnet-developers] Interrupt sharing realtime / non-realtime
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers
|
From: Klaus K. <kla...@in...> - 2005-08-04 09:20:25
|
Hello,
I'm actually porting drivers for RTnet (hope to tell you more in
some days). But now I have a *real* problem...
In one of my development PCs are two NICs: one for "normal"
ethernet operation, and one as the RTnet interface.
(Different chipsets, different drivers)
After several hours (days) of debugging I found out that my
system hangs up when my new RTnet driver is enabled and a
packet on the "normal" interface arrives. I looked into
the PCI table and: yes, these two f*cking NICs share their
interrupt request line (IRQ 10).
As I'm relative new to realtime development, I suppose that
it's not possible to share an IRQ between realtime and
non-realtime domains?
Nevertheless I think that it's the job of Adeos to handle the
interrupts, and when an IRQ 10 is raised, it should first
be handled by RTAI and then (if remaining unhandled) by
the "normal" linux... or not?
However - I added debugging output to my new driver interrupt
handler to see whenever an interrupt arrives; indeed only
local interrupts of the new RTnet drivers are shown, but
when my "killing" packet (from the normal NIC) arrives, the
system hangs immediately.
Currently I'm using RTnet-0.8.3 and RTAI-3.2.
Any ideas?
Best regards,
Klaus
--
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de
|
|
From: Zhang Y. <y.z...@st...> - 2005-08-04 12:28:57
|
The most straightforward way: Open your box, plug one NIC to another PCI slot. Keep on trying, until = the two use dfferent IRQ. Yuchen > -----Original Message----- > From: rtn...@li...=20 > [mailto:rtn...@li...] On=20 > Behalf Of Klaus Keppler > Sent: Thursday, August 04, 2005 11:20 AM > To: rtn...@li... > Subject: [RTnet-developers] Interrupt sharing realtime / non-realtime >=20 > Hello, >=20 > I'm actually porting drivers for RTnet (hope to tell you more=20 > in some days). But now I have a *real* problem... >=20 > In one of my development PCs are two NICs: one for "normal" > ethernet operation, and one as the RTnet interface. > (Different chipsets, different drivers) > After several hours (days) of debugging I found out that my=20 > system hangs up when my new RTnet driver is enabled and a=20 > packet on the "normal" interface arrives. I looked into the=20 > PCI table and: yes, these two f*cking NICs share their=20 > interrupt request line (IRQ 10). >=20 > As I'm relative new to realtime development, I suppose that=20 > it's not possible to share an IRQ between realtime and=20 > non-realtime domains? > Nevertheless I think that it's the job of Adeos to handle the=20 > interrupts, and when an IRQ 10 is raised, it should first be=20 > handled by RTAI and then (if remaining unhandled) by the=20 > "normal" linux... or not? > However - I added debugging output to my new driver interrupt=20 > handler to see whenever an interrupt arrives; indeed only=20 > local interrupts of the new RTnet drivers are shown, but when=20 > my "killing" packet (from the normal NIC) arrives, the system=20 > hangs immediately. >=20 > Currently I'm using RTnet-0.8.3 and RTAI-3.2. >=20 > Any ideas? >=20 > Best regards, >=20 > Klaus >=20 > -- > Institut f=FCr Informatik > Friedrich-Alexander-Universit=E4t Erlangen-N=FCrnberg = http://www.cs.fau.de >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development=20 > Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams *=20 > Testing & QA > Security * Process Improvement & Measurement *=20 > http://www.sqe.com/bsce5sf > _______________________________________________ > RTnet-developers mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-developers >=20 |
|
From: Klaus K. <kla...@in...> - 2005-08-04 13:20:20
|
That's clear - but I wasn't sure if there's really a problem
whith shared interrupts.
In the meantime I swapped my "new" NICs with some via-rhine based
cards and experienced the same problem when sharing interrupts.
(so I proved that there's no bug in my freshly ported driver...)
Concluding I can say that RTnet (+RTAI) can't be used on NICs
which share their interrupt with non-realtime NICs (which are
in use at the same time).
Klaus
Zhang Yuchen schrieb:
> The most straightforward way:
>
> Open your box, plug one NIC to another PCI slot. Keep on trying, until the
> two use dfferent IRQ.
>
> Yuchen
--
Institut für Informatik
Friedrich-Alexander-Universität Erlangen-Nürnberg
http://www.cs.fau.de
|
|
From: Jan K. <ki...@rt...> - 2005-08-06 07:42:57
|
Klaus Keppler wrote: > That's clear - but I wasn't sure if there's really a problem > whith shared interrupts. > > In the meantime I swapped my "new" NICs with some via-rhine based > cards and experienced the same problem when sharing interrupts. > (so I proved that there's no bug in my freshly ported driver...) > > Concluding I can say that RTnet (+RTAI) can't be used on NICs > which share their interrupt with non-realtime NICs (which are > in use at the same time). > The problem with sharing IRQ line between RT and non-rt drivers is that the non-RT driver at least has to be given the chance to acknowledge and switch off the IRQ source on its related device. Otherwise, the IRQ line will remain active, shadowing any IRQ from the RT device. I once made Philippe to add the required infrastructure to Adeos. It now takes a specifically patched non-RT driver to register a real-time-safe acknowledge handler with Adeos to quickly release the IRQ line again. Not trivial. The reason we once thought we need it was some nice PC104+ NIC which shared the same IRQ line than the onboard NIC of the attached embedded PC. As it finally turned out that we had to change some other jumper than the one labelled with "IRQ No." to actually switch the line (really a great piece of hardware...), we no longer had to solve it in software. Jan |
Thanks for helping keep SourceForge clean.
X