Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mailrus!ncar!ames!pasteur!helios.ee.lbl.gov!bevb.bev.lbl.gov!biocca
From: biocca@bevb.bev.lbl.gov (Alan Biocca)
Newsgroups: comp.realtime
Subject: Re: rebooting hung vxWorks system
Message-ID: <4393@helios.ee.lbl.gov>
Date: 6 Dec 89 17:31:54 GMT
References: <5321@ncar.ucar.edu> <41645@srcsip.UUCP>
Sender: usenet@helios.ee.lbl.gov
Reply-To: biocca@bevb.bev.lbl.gov (Alan Biocca)
Distribution: na
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 24
X-Local-Date: 6 Dec 89 09:31:54 PST

In article <5321@ncar.ucar.edu> martin@aster.UCAR.EDU (Charlie Martin) writes:
>Has anybody devised a method for remotely booting 
>(ie. over the network) a vxWorks system which has crashed?

    This is not quite what you are asking, but may be of use:

    We have had good success using the Deadman timer available on many
    CPU boards.  Essentially a monitor task periodically checks on the
    health of the system (in whatever way you like) and resets the
    deadman timer.  This timer produces a reset when it times out, 
    causing the crate to automatically reboot when crashes occur.

    In the Motorola 147 we are using the deadman timer has a very short
    maximum timeout and we found that a regular task could not reliaby
    reset it often enough.  We added some code to the clock interrupt
    handler to manage a longer timer and reset the hardware deadman
    until the longer software timer expired.

    We are planning to put this in the vxWorks archive soon.

		Alan K Biocca
		Deputy Project Manager
		BEVALAC Controls Group
		Lawrence Berkeley Laboratory