Teresa Noviello wrote: > On 3/10/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> >> I'm picking a standard answer first: please check if there is no IRQ >> conflict between the realtime NIC and some Linux device (see >> /proc/interrupts). This can have ugly side effects, up to >> crashes/lock-ups. > > > > In my /proc/interrupts AT BOOT TIME, > I have: > ----------- > " > CPU0 > 0: 19287 XT-PIC timer > 1: 110 XT-PIC i8042 > 2: 0 XT-PIC cascade > 4: 6 XT-PIC serial > 15: 14206 XT-PIC ide1 > MMI: 0 > ERR: 1 > " > -------------- > > When then i insert the eth0' driver, which is "e100", i have another row in > this file (for eth0): > ----------- > " > CPU0 > 0: 19287 XT-PIC timer > 1: 110 XT-PIC i8042 > 2: 0 XT-PIC cascade > 4: 6 XT-PIC serial > 11: 1601 XT-PIC eth0 > 15: 14206 XT-PIC ide1 > MMI: 0 > ERR: 1 > " > --------------
Ok, obviously no IRQ conflict. > > Before starting with inserting RTAI' modules and doing 'rtnet start', i do > > 'rmmod e100' > and the row for eth0 isn't still present in /proc/interrupts. > > Then, we have the same problem i told you. > > When we do in the master host > > "rtnet stop" > > we have a Segmentation Fault but we do not have Kernel oops. But something does go wrong in the kernel, otherwise we wouldn't see this "rtnet: unregistering rteth0 deferred -refcount=2". It does not cause an oops but a deadlock in the unregistration path. This is either some bug or a symptom for a deeper one. Need to be identified and fixed. > > Maybe we can try by hand with the command "rtcfg" with utilities described > in > > " > http://www.rts.uni-hannover.de/rtnet/lxr/source/Documentation/RTcfg.spec?v=0.9.1 > " > > line 359?? I would start with instrumenting the rtnet script, i.e. putting some "echo XXX" before and after the potentially failing rtcfg invocations. That's easier and avoids that running all the stuff manually creates a different error (or none at all). But before starting another test cycle, please switch on RTcfg debugging in the RTnet setup of both stations and recompile it. This will dump the internal RTcfg states on the kernel console and can help to identify which node does what. > > > We have tested that the host ping internet with rtnet on (rtping). So the NIC works (on both nodes?). That's a good starting point to narrow down this issue. We'll get it! Jan
signature.asc
Description: OpenPGP digital signature
