M. Koehrer wrote: > Hi everybody, > > I have one Intel PC, that uses (on one of the few PCI slots) the same IRQ > for the onboard network > device and an additional PCI (eepro100) network device. > I am using the latest rtai 3.3, kernel 2.6.15.4 and the latest SVN snapshot > from rtnet. > When starting the rtnet and configuring the driver (rtifconfig rteth up), the > onboard net is "dead", > however working locally on the PC still works fine. > When rtnet is stopped (rtifconfig rteth down) everything is fine again. > > This is probably caused by the same IRQ. However, I thought I read a while > ago, that > this shared interrupt issue should be solved?!?
Nope. If you are interested in a deeper discussion on this and if you have a lot of spare time, follow our endless thread on the Xenomai core list about IRQ sharing and related return flags :). We tried to find a generic and clean solution - but we failed. To sum up the result: the only way to handle this is to write hardware-specific stubs for the Linux devices sharing RT-IRQ lines. This is feasible, but the RT-Linux extension cannot support you much in this regard. For this reason I also decided to drop the related IRQ return flag (RTDM_IRQ_PROPAGATE) from the latest RTDM API revision, as RTDM is intended for common portable drivers. > > When I plugin the PCI NIC to another PCI slot it works fine. > However, as new PCs have only very few PCI slots this not really a long-term > option... The only long-term option is MSI, but this is already fragile with standard Linux and not yet very common for embedded/industrial PCs. > > Can the rt-eepro100 driver or the RTDM framework somehow be "tuned" to work > with > the shared interrupts? > I've once written such a stub for a eepro100, see e.g. this reposting: https://mail.gna.org/public/xenomai-core/2005-11/msg00012.html > Thanks for any answer on that! > > > Regards > > Mathias > Jan
signature.asc
Description: OpenPGP digital signature
