Roland Tollenaar wrote: > Hi Jan!, > > >>> >>> -I then rmmod e1000 (for the other network card) >>> -pinging on eth0 still going >>> -I mknod bla di bla >>> -pinging on eth0 still going >>> -I insmod rtnet.ko >>> -pinging on eth0 still going >>> -I insmod rtpacket.ko >>> -pinging on eth0 still going >>> -I insmod rt_loopback.ko >>> -pinging on eth0 still going >>> -I insmod rt_e1000.ko >>> -pinging on eth0 still going >>> -I rtifconfig rtlo up >>> -pinging on eth0 still going >>> -I rtifconfig rteth0 up >>> --pinging on eth0 STOPS dead!!! >> >> I didn't followed this thread from the beginning (hell, I never thought >> I would have to say this on _THIS_ mailing list :) ), but my usual guess >> on this "strange" side effect is once again... IRQ conflict between both >> adapters? > The thought had crossed my mind considering I have had IRQ conflict > problems before on this particular machine. You indeed pointed that out > at the time. The cards this time however are set at different IRQ > Priority ( I still have no idea what the "priority") means in the BIOS > but I do know that if I leave this particular setting in "auto" the > entire machine freezes when rtnet goes up. For some reason this machine > seems to have kamakaze tendencies when it comes to assigning IRQ's.
"Priority" doesn't sound like "IRQ number" or "line" - maybe you are still facing the same conflict, just a bit papered over due to that priority switch. Can't tell, ask your board vendor, use a different hardware, sorry. > > My problem, I shamefully have to confess, is even though the thought > crossed my mind, I have no idea how to figure out what IRQ's are > assigned to the cards, how to obtain warnings to this effect and how to > rectify the matter. The latter being probably the least of my worries > for now, I might be able to jippo in the BIOS until I get something that > works. lspci -v should list all devices in your system and their assigned (but not necessarily used) resources like IRQs. Then there is /proc/interrupt for Linux usages and /proc/xenomai/irq for real-time usages. > >>Check the kernel console to confirm my assumption, there >>should be a warning message. > > Just to make sure you no longer feel like you are reading a LKML thread > here's a newbie question: What is the kernel console and how do I check > it? :) Sigh. Roland, get used to Linux, really. Ever heard or read of dmesg? Or do you know what (among other things) your local logging daemon collects (/var/log/messages or .../syslog)? > > >> Besides shared _hardware_ resources, there is no further conflict to be >> expected. > > Thanks. I don't know whether you noticed but you have joined a thread > that has spontaneously ignited. I'm still frantically trying to beat out > the flames..... :) I did notice this unneeded fire. As usual, it took at least two posters to ignite the flames... :) Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
