Just a quick follow-up to let everyone know: There actually wasn't any
problem with asyn.
Despite several "make clean", "make realclean", "make rebuild", etc
commands issued at numerous levels in the tree (and even some manual
deletions of files that still weren't being wiped or replaced), somehow
I missed the fact that things (including, apparently asyn) were NOT
recompiled, and I didn't discover that until I added some diagnostic
printf's to the code (after which everything worked fine, because that
DID cause it to recompile).
My bad. Although I still have no explanation as to why several things
were NOT recompiled or how I missed that fact that asyn in particular
was not.
On 1/15/2014 11:55 AM, Mark Davis wrote:
I have an asynPortDriver module I wrote that is currently running fine
on an a VME create running RTEMS on a MVME3100 board. Development and
testing was done on a Linux SIOC using EPICS version R.3.14.9 without
any problems (although it had to be removed from our base config for
that version because the 4.21 version of the asyn module used caused
problems for other modules).
I now have a project that will require the in-house module (and
asyn4-21 or later) to run on a a soft IOC running a newer version of
EPICS and I am having problems. In particular, the asynManager
appears to be getting a lock and never releasing it.
Current environment:
asyn version: 4.21
EPICS base version: 3.14.12.2
OS: 3.2.0-57-generic-pae #87-Ubuntu SMP Tue Nov 12 21:57:43 UTC
2013 i686 i686 i386 GNU/Linux
Below is a trace of the relevant portions of the IOC startup. I added
indentation to indicate the operations surrounded by locks. The
problem appears to be that asynManager never releases one of the
locks. The end result is (not too surprising) that the first attempt
to write a value to any of the records linked to the
asynPortDriver-based module after IOC initialization effectively locks
up the asyn driver.
Has anyone ever run in to this before? Any idea what could cause this?
#
#===== Setup for simulated FastCounter device (running on eowyn test
IOC)=====
drvAsynIPPortConfigure("simFCdev", "192.168.4.28:3333 udp", 0, 0, 1)
asynSetTraceMask("simFCdev", 0, 0xFF)
asynSetTraceIOMask("simFCdev", 0, 0xFF)
#===== initialize in-house asynPortDriver-derived module =====
devFastCounterConfig("simFC", "simFCdev", 1000)
=== devFastCounter::devFastCounter: 'simFC' connected to 'simFCdev' ===
asynSetTraceMask("simFC", 0, 0xff)
...
2014/01/13 11:16:14.015 simFC asynManager::queueLockPort locking port
2014/01/13 11:16:14.015 asynPortDriver:readInt32: function=5, value=0
2014/01/13 11:16:14.015 asynInt32SyncIO read: 0
2014/01/13 11:16:14.015 simFC queueUnlockPort
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=SEQS_PER_GROUP, index=4
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=SEQS_PER_GROUP, index=4
2014/01/13 11:16:14.015 simFC asynManager::queueLockPort locking port
2014/01/13 11:16:14.015 asynPortDriver:readInt32: function=4, value=10
2014/01/13 11:16:14.015 asynInt32SyncIO read: 10
2014/01/13 11:16:14.015 simFC queueUnlockPort
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=COUNT_TIMES, index=9
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=COUNT_VALUES, index=8
2014/01/13 11:16:14.015 simFC asynManager::queueLockPort locking
port(<--- never released)
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=ACQUIRE, index=0
2014/01/13 11:16:14.015 simFC -1 registerInterruptUser
2014/01/13 11:16:14.015 asynPortDriver:drvUserCreate:
drvInfo=ACQUIRE, index=0
2014/01/13 11:16:14.015 simFC asynManager::queueLockPort locking port
2014/01/13 11:16:14.015 asynPortDriver:readInt32: function=0, value=0
2014/01/13 11:16:14.015 asynInt32SyncIO read: 0
2014/01/13 11:16:14.015 simFC queueUnlockPort
2014/01/13 11:16:14.015 FastCount:TimePerCount_Read
devAsynFloat64::getIoIntInfo registering interrupt
2014/01/13 11:16:14.015 FastCount:TimePerCount_Read
devAsynFloat64::getIoIntInfo created ring buffer, size=10
2014/01/13 11:16:14.015 simFC -1 registerInterruptUser
2014/01/13 11:16:14.015 FastCount:TimePerSeq_Read
devAsynFloat64::getIoIntInfo registering interrupt
2014/01/13 11:16:14.015 FastCount:TimePerSeq_Read
devAsynFloat64::getIoIntInfo created ring buffer, size=10
2014/01/13 11:16:14.015 simFC -1 registerInterruptUser
...
iocRun: All initialization complete
...
2014/01/13 11:18:10.965 simFC queueRequest synchronous
- Replies:
- Re: asyn lock issue? Andrew Johnson
- References:
- asyn lock issue? Mark Davis
- Navigate by Date:
- Prev:
Re: SNL monitor and pvPutComplete Benjamin Franksen
- Next:
mca Matlab. Problems on compilation Rafael Antonio Baron
- 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
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
asyn lock issue? Mark Davis
- Next:
Re: asyn lock issue? Andrew Johnson
- 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
2019
2020
2021
2022
2023
2024
|