Tim and Andrew,
We have discovered a serious problem with the scaler record running under the following configuration.
Base 7.0.3.1
vxWorks 6.9.4.1
std master
mca master
vme master
asyn master
The problem is the following:
-
If the scaler display update rate (.RATE field) is 59 (Hz) or less it works fine. The cbHigh task is using less than 2% of the CPU as shown by spy.
-
If .RATE=60 then the following happens:
o
The cbHigh task uses >50% of the CPU
o
The timerTask uses >20% of the CPU
o
There is 0% IDLE time in the CPU
o
The crate becomes unresponsive and loses CA connections
o
Typing ‘dbpf “13LAB:scaler1.RATE”,”59”’ fixes the problem immediately, the crate becomes responsive and CA connections are restorerd.
-
We observe this problem on both the Joerger scaler and the SIS3820 scaler.
-
The problem also happens if Autocount is enabled and .RAT1=60.
We are certain that this is a new problem, because we have autosave files from 2 vxWorks IOCs going all the way back to 2014 and .RATE was always 60 for those scalers. This includes the last run in December 2019.
We first observed the failures yesterday (the first day of the run, naturally!)
Nothing has changed in the scaler record, or in the device support for the Joerger scaler and the SIS3820 scaler since 2018. We have been running the master branch of these all the time, so the fact that it was working all of 2019 means
the problem is unlikely to be in those modules.
The Joerger scaler does not use asyn, so the problem cannot be in asyn.
The main thing that has changed in this run is that we have updated from base 7.0.3 to 7.0.3.1.
Is there anything that could have changed in base 7.0.3.1 that might cause this behavior?
We can work around the problem for now by setting .RATE less than 60, but others are likely to be hit by the same problem.
Thanks,
Mark