Re: Weird stream device behavior when using the IOC shell's exit function

[Dirk Zimoch via Tech-talk <tech-talk@aps.anl.gov>]

On 06.02.19 16:15, Mark Rivers wrote:
> > Can it be that several records have queued up on the asyn port when the ioc exits?
> > In that case scanning would already have been stopped, but still records may be scheduled to access the port when the ioc is already shutting down.
>
> I am not sure if scanning has stopped.  epicsExit is hung up trying to close the socket.  The question is when that happens in the shutdown.  The epicsAtExit call to register that exit function  is called when the drvAsynIPPort is created, which is before iocInit.  Does that mean it will be called before or after record scanning is stopped?

epicsAtExit calls the handlers in inverse order. Last installed is first 
called.

> Is it possible that Stream is repeatedly calling pasynOctet->read with the port lock held, so the exit handler never can get the lock with pasynManager->lockPort()?

Yes, StreamDevice may call pasynOctet->read repeatedly with the port 
lock held, as long as those reads are successful. Once the read fails 
(e.g. timeout expires) the lock will be released. The timeout is 
specified by the user in the protocol file.

So no, this should not block the exit handler from ever getting the 
lock. All the exit handler needs to do is request the lock and asyn 
should queue it in.

> Mark
>
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Dirk Zimoch via Tech-talk
> Sent: Wednesday, February 6, 2019 6:51 AM
> To: tech-talk@aps.anl.gov
> Subject: Re: Weird stream device behavior when using the IOC shell's exit function
>
> Can it be that several records have queued up on the asyn port when the ioc exits? In that case scanning would already have been stopped, but still records may be scheduled to access the port when the ioc is already shutting down. Maybe I need to check the ioc run state and discard all queued records when the ioc is shutting down.
> Also this behavior may be a side effect of the new cases in that the @init handler is supposed to run, namely after asyn port re-connect and after ioc resume (iocRun). I need to check...
>
> Dirk
>
> On 04.02.19 08:41, Abdalla Ahmad via Tech-talk wrote:
> > Hi
> >
> > We are using the following setup to test control of the agilent XGS
> > gauge controllers and Gamma ion pump controllers:
> >
> > 1.EPICS Base 3.15.6
> >
> > 2.Asyn R4-33
> >
> > 3.Stream R2-7-7c
> >
> > For agilent controllers we get the following error:
> >
> > asynError in write. Asyn driver says: device:port disconnected.
> >
> > But eventually the IOC exits. For the gamma controllers we get
> > something really strange. There a point in the database where the IOC
> > never exits, the exit command just freezes and Ctrl-C is the only way
> > to shut down the IOC. For now I can see that this behavior occurs
> > because more DB substitutions are configured which means more PVs and more controllers.
> > But that was not the case when we had:
> >
> > 1.EPICS Base 3.14.12.3
> >
> > 2.Asyn R4-18
> >
> > 3.Stream R2-5-1
> >
> > Where the IOC exits with no errors or freezing. Should we upgrade our
> > support modules or change the EPICS base?
> >
> > Another problem we are facing with this new setup is that I can't find
> > some asyn IOC shell function like asynTraceMask for example. The IOC
> > is configured properly in RELEASE and src/Makefile. Is there anything
> > we miss in the new setup?
> >
> > Best Regards,
> >
> > Abdalla Ahmad
> >
> > Control Engineer
> >
> > SESAME
> >
> > Allan, Jordan.
> >
> > Tel: (+962-5) 3511348 , ext. 265
> >
> > Fax: (+962-5) 3511423
> >
> > Mob: (+962-7)88183296
> >
> > www.sesame.org.jo <http://www.sesame.org.jo/>