-
Notifications
You must be signed in to change notification settings - Fork 20
testConnectivity OH Masking Issue #292
Comments
This is known behavior. The current values are jumping because all the OHs receive hard reset and got reprogrammed. However this should not cause any issues unless you're doing something on them in parallel. The communication to the frontend should remain stable (GBT config should not be affected). Could you please elaborate on the subsequent communication failures on other chambers? |
After we did
This happens with any of the other OHs on shelf01-amc11at p5. The only way to recover one of the other chambers is to power cycle |
Okay, so something strange is happening. I first noticed this last week at point 5 on a different amc. Then I was able to reproduce this twice at p5 today. But just now, we did |
Hmmm... this is really interesting @evka85, please take a look. Under normal operations we are supposed to get resyncs from time to time as well as hard resets, which will be forwarded to front end and it is important to restore the system properly... |
@bregnery, since you could reproduce the issue, did you read some registers and/or made some dumps? Such as reading the GTH transceiver or the GBT link statuses (before and after a link reset for the latter)? It rather difficult to do post-mortem analysis with very little information. We are/were using Also, the IPBus issue is not related since it is not for the same link and there is not IPBus-related error messages in the current issue. |
It would seem that the OH masks are not working properly on the
testConnectivity.py
Say for example, that we want to do testConnecivity with a GBT phase scan on (1,11,5). So we run testConnectivity with OH mask 0x20. As we do that, we notice all of the other OH's on the same CTP7 start jumping around in current values. Then, testConnectivity will fail with all of the other chambers on that CTP7 and to test another, the chamber must be powercycled in order to recover it.
Types of issue
Expected Behavior
We should be able to run testConnectivity one chamber at a time without affecting current/communication with masked chambers.
Current Behavior
running testConnectivity on one chamber will mess up the communication with an unprogrammed chamber.
Steps to Reproduce (for bugs)
Possible Solution (for bugs)
Context (for feature requests)
Your Environment
Name : gempython_vfatqc
Arch : x86_64
Version : 2.7.7
Name : gempython_vfatqc
Arch : noarch
Version : 1.0.5
The text was updated successfully, but these errors were encountered: