Has anyone run into the following mutex locking failure before? I have
only seen the problem when drvSerialPortConfigure is called and a sscan
record is loaded. In the example below there is only the sscan record
specified in sscantest.db. Occasionally the IOC will start fine.
We have been running an IOC using base 3.14.9, asyn 4.9 and sscan 2-5-6
and never seen this problem.
dly@antares14:~/sscantest/iocBoot/iocsscantest>
../../bin/linux-x86_64/sscantest st.cmd
#!../../bin/linux-x86_64/sscantest
## You may have to change sscantest to something else
## everywhere it appears in this file
< envPaths
epicsEnvSet("ARCH","linux-x86_64")
epicsEnvSet("IOC","iocsscantest")
epicsEnvSet("TOP","/home/dly/sscantest")
epicsEnvSet("ASYN","/usr/local/src/EPICS/asyn/4-12")
epicsEnvSet("SSCAN","/usr/local/src/EPICS/sscan/2-6-5")
epicsEnvSet("EPICS_BASE","/usr/local/src/EPICS/base-3.14.11")
cd /home/dly/sscantest
## Register all support components
dbLoadDatabase "dbd/sscantest.dbd"
sscantest_registerRecordDeviceDriver pdbbase
drvAsynSerialPortConfigure("src", "/dev/ttyr07")
## Load record instances
dbLoadRecords("db/sscantest.db","user=dlyHost")
cd /home/dly/sscantest/iocBoot/iocsscantest
iocInit
Starting iocInit
########################################################################
####
## EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$
## EPICS Base built Nov 16 2009
########################################################################
####
A call to 'assert(status == epicsMutexLockOK)'
by thread '_main_' failed in ../dbPvdLib.c line 90.
EPICS Release EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$.
Local time is 2009-11-16 14:24:25.500100161 EST
Please E-mail this message to the author or to [email protected]
Calling epicsThreadSuspendSelf()
Thanks,
Damien Lynch
Accelerator IT Systems Engineer
Institute of Environmental Research
Australian Nuclear Science and Technology Organisation
PMB 1, Menai NSW 2234
Important: This transmission is intended only for the use of the
addressee. It is confidential and may contain privileged information or
copyright material. If you are not the intended recipient, any use or
further disclosure of this communication is strictly forbidden. If you
have received this transmission in error, please notify me immediately
by telephone and delete all copies of this transmission as well as any
attachments.