-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECAL GPU unpacker - Add detection of corrupted DCC tower headers and recovery - backport 12_3_X #37435
Conversation
A new Pull Request was created by @thomreis (Thomas Reis) for CMSSW_12_3_X. It involves the following packages:
@jpata, @cmsbuild, @clacaputo, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Backport of #37430 |
type bugfix |
enable gpu |
@cmsbuild please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-cbe6c8/23616/summary.html GPU Comparison SummarySummary:
Comparison SummarySummary:
|
+reconstruction
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_12_3_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_12_4_X is complete. This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1
|
PR description:
Backport of #37430
Up to now the ECAL GPU unpacker did not check the DCC tower headers consistency when using it. A corrupted header with tower block length extracted as 0 leads to an infinite loop.
This PR fixes this by first building a list of FE channels that are expected to contain data and checking the TT id extracted from the tower header against it. In case of a mismatch the tower block is skipped and the next good tower header is searched in the raw data. The unpacking then continues with the tower block with the next good header.
This PR fixes #37323.
PR validation:
No infinite loop anymore with the configuration and data described in #37323.