Issue with jackhammering into a slot #382
Replies: 3 comments 4 replies
-
|
Hi Aashrita, so those The thing that concerns me from what you posted above are these logs: which to me makes it seem like you are using an incorrect pysmurf-config file, which is only configured for 1 AMC. You can check out our config files from P10R1 to copy: https://github.com/simonsobs/ocs-site-configs/tree/main/ucsd/sat1/smurf-srv20/pysmurf_configs/P10R1, (just make sure you're using an I'm not entirely sure if this is what's causing the setup to crash, but it's possible. |
Beta Was this translation helpful? Give feedback.
-
|
Also, if you are currently mounting in |
Beta Was this translation helpful? Give feedback.
-
|
Hey thanks - yeah I actually had already fixed the band X bay warnings, but i went ahead and updated the config files to whatever sat1 has anyways just in case it was giving me issues. I'm not quite sure what you mean about the commenting something out in the volumes section - can you direct me to what exactly you're referring to? I'm a little new to all of this still |
Beta Was this translation helpful? Give feedback.
-
|
In docker-compose.yml, in the x-smurf-service block (and smurf-jupyter block, and others), there is a 'volumes' section where various things get mounted into the docker. You probably have a line like |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that's the line we should comment out. It was required at one point, when pysmurf was still in active development, but now the correct version of pysmurf should be automatically built into all of the containers, so it should no longer be required unless you want to make changes in the pysmurf repo itself. |
Beta Was this translation helpful? Give feedback.
-
|
Here's what's happening under the hood on this one (the Rogue server logs): The first attempt to run low level initialization is failing for this board, but the second succeeds. Unfortunately by the time the second attempt succeeds, Looking at the I think this may be the issue: For some reason in the SO-built server dockers, the core pysmurf instance isn't able to query the pysmurf version. I'm not sure why but I had a similar issue with this recently in the SLAC-built server dockers that I fixed here - slaclab/pysmurf#777. The behavior of the This carrier passed SLAC testing which means it booted reliably, but our testing would have been running the enhanced version of the defaults initialization. Separately @aashrita it is pretty weird if as you say the RTM is causing carriers to do this. If it's not too painful, could you try a couple of more swaps just to confirm it wasn't a coincidence. If not a coincidence I think we'll want to take a close look at that RTM at SLAC. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @aashrita, I've built a new version of all of the SO dockers that have that fix that shawn pointed out. I've tested and can get the pysmurf-version using these new dockers, so this should let pysmurf know that it should retry to accommodate for failed attempts. If you update your SODETLIB tag in the sys-config to: then the version checking should work. You can check by checking |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I get the following issue when jackhammering into slot 6:
I checked the streamer logs to see if I get a
Elastic buffer check passed!message, but I dont. Instead the log suggests buffers have the following errors:I still tried to manually enter pysmurf session via
jackhammer pysmurf 6and runS.setup(force_configure=True)which ended successfully with a 'Done with setup.' message and dumped me into an ipython session.Not sure what is happening here. For reference, the problem seems to follow the RTM for some reason as I tried swapping slots to see if I could isolate the problem. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions