Running the new external EDCU model h1edc on h1susauxh34 resulted in a dmesg error:
h1edcepics[896] general protection ip:7f1c80b48ced sp:7fffe66841a0 error:0 in libc-2.12.2.so[7f1c80ae5000+15d000]
Daniel has called a halt to maintenance, so we will work this problem offline.
Details:
The external edcu has been extensively tested with no problems on the DAQ Test Stand all last week, and yesterday I rebuilt x1edc against Rolf's tagged 3.5.0 release. I followed this install and build procedure on H1 this morning:
For each HnEDCU_{name}.ini file in the DAQ master, in its userapps location I created an equivalent HnEPICS_{name}.ini file (minus the default header) and created a symbolic link to it from /opt/rtcds/lho/h1/chans/daq/. Also in this directory I created the edcuheader.txt and edcumaster.txt files.
On h1boot1 I edited the rtsystab file adding h1edc to h1susauxh34. The tested x1edc.mdl model was copied to h1edc.mdl with the appropriate X1->H1 conversions. The model was compiled and install-nort'ed.
When I ran h1edc, it emptied the H1EDC.ini file but did not populate it with the full channel list. The channel count PVs briefly existed with zero values before the code crashed.
I had queued up the DAQ changes needed for the extenal EDCU:
These changes have been reverted out of the DAQ for now.
Jonathan, Dave:
We found the error, I had introduced a bad carriage return in the edcumaster.txt file, and I remembered Keith alogging that any spaces in this file is bad. I fixed the file and restarted h1edc. Initially it was not connecting to the 3,404 guardian channels, and when guardian was started h1edc connected to the full list of 40,069 epics channels.
We will schedule a DAQ restart to switch from internal to external EDCU at the next target-of-opportunity.
I tracked the crash point down in the code. See CDS bug 1136.