Open MarkRivers opened 1 year ago
Thanks for following up. To provide more info, it can also be reproduced on asyn-R4-43 and asyn-R4-42.
To provide more info, it can also be reproduced on asyn-R4-43 and asyn-R4-42.
I believe I have identified the issue. The problem is that devAsynXXXArray::interruptCallback should be returning immediately if interruptAccept is not yet 1. It currently does this if a ring buffer is being used: https://github.com/epics-modules/asyn/blob/f9d492ed58f4bd730cf49ac7feccc201cd2b17b0/asyn/devEpics/devAsynXXXArray.cpp#L431
But it needs to do this even if a ring buffer is not being used.
This problem is not new in R4-44, it was also present in older versions when devAsynXXXArray.h was a giant C macro.
I have fixed the problem. interruptCallback() now returns immediately if interruptAccept is 0. I have pushed the fix to the master branch.
It works, wonderful.
A problem is manifested in testAsynPortDriver if P_Run is set to 1 in the .cpp file.
The driver will print these messages right after iocInit:
Both of these observations suggest a problem in the initialization of devAsynXXXArray.cpp. That was completely re-written in asyn R4-44.