Giammarco Zacheo wrote: > On 12/6/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> >> Giammarco Zacheo wrote: >> > Hi, >> > >> > we are currently working with RTnet 0.9.7 and RTAI magma on Debian Etch >> > 2.6.17 kernel. >> > RTnet works fine until we use the rtnet script to stop the slave host. >> When >> > the script reaches 'rtifconfig rteth0 down' the machine freezes (i.e. >> does >> >> Master still running at that point, i.e. are packets arriving? Does >> pulling the wire make a difference? > > > Yes, the master is still running, as we see lots of activity on the Nic's > led (sync packets, we presume). Pulling the wire does not make a difference > on the slave machine, as it keeps freezed; when plugging it back there is a > pause of about 30 seconds then the activity led starts to blink again.
I meant pulling the cable before calling rtnet stop - to avoid that packets arrive while the shutdown takes place. > >> not accept any input at all from mouse or keyboard). We have two >> machines, >> > both Pentium 4 with Intel boards (ICH5), they act the same way. We have >> no >> > such problem when stopping them as a master. >> >> All machines UP, or are they SMP? All standard, means simple rtnet.conf >> script? Please provide configuration information for reference, also the >> .config of your failing host (either packed or sent to me privately). >> What is your irq layout? No conflicts RT/non-RT? > > > all the machines are UP, the rtnet.conf is the simplest you can imagine > (with default values, 5000/200 :-) ), no tdma.conf involved. If you think > that taking a look to che .config file would be useful, we will send it to > you privately. Yes, please. I'm going to try your precise scenario then when time permits. > > >> We tried also Xenomai 2.2.4, 2.3rc1 and 2.3rc2 with RTnet 0.9.6, too, >> > but we >> > did not manage to solve the problem. >> >> Means you observed exactly the same failure? Well, this really sounds >> like an RTnet issue. >> >> > We tried on a Realtek 8169 and a Intel >> > E100, nope. >> >> So it's likely a core issue. >> >> > But...on my damn slow Duron 1200 without APIC and a R8139 everything >> seems >> > to work fine (currently running with Xenomai 2.3rc1 and RTnet 0.9.6). >> > >> > ...any ideas about it? >> >> Any oops visible? Try catching it via a serial console. There are also >> soft-watchdogs available under both RTAI and Xenomai. Please arm them to >> check if we have a run-away thread. Xenomai additionally has support for >> a NMI watchdog (maybe RTAI as well, dunno). That one triggers if not >> touched and dumps a backtrace. May help if we are in a tight endless >> loop. > > no visible oops as we can see. The console just stops its output when we > call "rtnet stop". We recompiled Xenomai with watchdog support but nothing > changed, it keeps on freezing and no dump is produced. Shall we fine-tune > the watchdog in order to obtain more infos? > NMI watchdog or soft-watchdog? If the NMI watchdog doesn't trigger, the RT core must continue to work somehow, only Linux stalls. In that case, the soft-watchdog of Xenomai should catch the missing Linux timer updates. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
