Experimental Physics and
| |||||||||||||||||
|
Does the thread remain stuck in that subroutine (in asAddClient in the Well, I have to reboot the affected IOCs rather quickly, so I can't wait and test for long. But it just happened on 2 other IOCs, so I now found a total of 3 IOCs with a task trace like this: 1fa774 vxTaskEntry +68 : 1b60b3c () 1b60bac epicsThreadPrivateGet+f8 : camsgtask () 1a777e8 camsgtask +36c: camessage () 1a7c744 camessage +320: 1a79de4 () 1a79de4 casUserNameInitiatingCurrentThread+2404: asAddClient () 1a88cec asAddClient +110: epicsMutexLock () 1b5787c epicsMutexLock +24 : semTake () 1f0c74 semTake +13c: semMTake () value = 0 = 0x0 I did run tt twice, a few minutes in between, w/o any change. Pity is that I can't get at the 'static' AS semaphore ID to run a semShow and see which task is holding the lock. Our CA security config was changed before this beam test run. Basically, these a few more hosts were added by name, example: HAG(phyServers) {ics-srv-phy1,ics-srv-phy2,ics-srv-phy3,ics-srv-phy4} But those names are not explicitly mapped to IP addresses via "hostAdd". So could the IOC use NFS to resolve those host names, and what I see is a result of CA security waiting for NFS? Thanks, -Kay
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |