Experimental Physics and
Industrial Control System

"Paul Sichta" <[email protected]> · Mon, 14 Jan 2002 09:53:01 -0500

Brian,
As Jeff indicated,  we have certain device drivers that will
usually hang the 'reboot' process.  We use a macro to first
delete the driver tasks (preceded by a spy and casr listing
to display system info), delay a bit, and then issue the
'reboot' command as the last line.

IOCx>  <st.shutdown_iocx

--
Paul Sichta
Princeton Plasma Physics Laboratory
609-243-3477       FAX 3030

----- Original Message -----
From: "Brian McAllister" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Friday, January 11, 2002 6:58 PM
Subject: channel access reboot behavior

>
> As currently implemented, Channel Access on the IOC tries
to communicate
> with remote clients/servers when shutting down prior to
reboot (this is
> inferred from error messages seen during the shutdown).
Unfortunately,
> network services will always have been shut down first, so
these
> notification attempts always fail, and will continue to do
so unless the
> VxWorks reboot processing is modified to allow user hooks
to be handled
> first, which seems unlikely.
>
> Occasionally, one of our IOCs will hang on reboot,
requiring physical
> access to push the reset button.  I am wondering if this
hang might in part
> be due to the system trying to do things while in a
partially shut down
> state, and if there is any reason not to eliminate the CA
server behavior
> noted above, on the chance that it may be contributing to
the problem.
>
> Or perhaps, EPICS could have a "shutdown" routine, which
terminates the
> EPICS tasks appropriately, and then calls reboot ?
>
> ----
> Brian McAllister                    Controls
Programmer/Beam Physicist
> [email protected]                        MIT-Bates Linear
Accelerator
> (617) 253-9537
Middleton, MA
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System