Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: RE: Weird stream device behavior when using the IOC shell's exit function
From: Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>
To: 'Dirk Zimoch' <dirk.zimoch@psi.ch>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 6 Feb 2019 17:46:02 +0000
> 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.

I don't think that is necessarily true.  If you have a thread that very rapidly calls pasynManager->unlock() and then pasynManager->lock(), either directly or indirectly, then other threads may not be able to access the port.  The reason is that, unlike what you say above, pasynManager->lockPort() does not queue a request.  For exactly this reason I added another function, pasynManager->queueLockPort() which does queue the lock request.  That is what the asynXXXSyncIO routines use.  See the asyn RELEASE_NOTES for R4-14, R4-20, and R4-21.

Mark


-----Original Message-----
From: Dirk Zimoch <dirk.zimoch@psi.ch> 
Sent: Wednesday, February 6, 2019 9:59 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: tech-talk@aps.anl.gov
Subject: Re: Weird stream device behavior when using the IOC shell's exit function



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/>
>>

Replies:
Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk
References:
Weird stream device behavior when using the IOC shell's exit function Abdalla Ahmad via Tech-talk
Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk
RE: Weird stream device behavior when using the IOC shell's exit function Mark Rivers via Tech-talk
Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk

Navigate by Date:
Prev: Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk
Next: RE: Weird stream device behavior when using the IOC shell's exit function Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk
Next: Re: Weird stream device behavior when using the IOC shell's exit function Dirk Zimoch via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 07 Feb 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·