EPICS Controls 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  2021  2022  2023  2024  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  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Weird stream device behavior when using the IOC shell's exit function
From: Dirk Zimoch via Tech-talk <[email protected]>
To: Mark Rivers <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Thu, 7 Feb 2019 09:22:12 +0100
StreamDevice never calls pasynManager->lockPort().
It calls pasynManager->queueRequest() and then in the callback pasynManager->blockProcessCallback().



On 06.02.19 18:46, Mark Rivers wrote:
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 <[email protected]>
Sent: Wednesday, February 6, 2019 9:59 AM
To: Mark Rivers <[email protected]>
Cc: [email protected]
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: [email protected] <[email protected]> On
Behalf Of Dirk Zimoch via Tech-talk
Sent: Wednesday, February 6, 2019 6:51 AM
To: [email protected]
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/>


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
RE: Weird stream device behavior when using the IOC shell's exit function Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: Weird stream device behavior when using the IOC shell's exit function Mark Rivers via Tech-talk
Next: RE: Weird stream device behavior when using the IOC shell's exit function Abdalla Ahmad 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  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Weird stream device behavior when using the IOC shell's exit function Mark Rivers via Tech-talk
Next: Changing record fields while PACT=1 Klemen Vodopivec 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  2021  2022  2023  2024 
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 ·