Roland Tollenaar wrote: > Hi, > >> which means you might have used the wrong interface. >> Anything beyond that is a configuration issue that you have to work out. > I doubt it. > > I have a very simple situation > Before any real time rtnet is activate the realtek card is eth0. > I leave this card on and and ping a host. Pinging is succesful and I > leave it on to see at what point things go wrong. > > -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? Given a recent Xenomai version, such conflicts are detected and the involved line is shut down. Thus no IRQs arrive anymore for both sides, RT and Linux. Check the kernel console to confirm my assumption, there should be a warning message. > > After about 15 seconds it (ping on eth0) gives > > From 10.0.0.6 icmp_seq=# Destination Host Unreachable > > and sometimes: ping sendmsg: No buffer space available > ???? Never seen that one before :) > > I then try > > ifconfig eth0 up > > which executes but makes no difference. > > I tried using rteth1 instead of rtet0 but that does not help either. > > If I then unplug the ethernet cable from the realtek card the PC tells > me the connection on eth0 was broken. So it still thinks that the > realtek card is eth0 but somehow it is dead. > > Any ideas because this, from what you posted, does not seem normal to me? > > Afraid my concern about running normal ethernet with another NIC on > rtnet was justified? :( Besides shared _hardware_ resources, there is no further conflict to be expected. Jan PS: This thread made me feel like I were reading LKML - is this a good or a bad sign...?
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
