PA4187 (R52, I52) DPM_PEND using new DPM
I52/R52 are not able to use the new DPM. The program throws a DPM_PEND for the bpm_get_data_c routine consistently. The proram has no problem on the old DPM.
#2 Updated by Richard Neswold over 3 years ago
- Status changed from New to Assigned
- Assignee set to Richard Neswold
We need to know which underlying devices are being accessed to figure this out. Since it's a BPM, it may a non-linearly addressed device. A database edit may fix this problem (Brian and I recently went through DPM's length/offset calculations for non-linear devices, so we think it's working -- the database entry may need an update, however.)
#3 Updated by Richard Neswold over 3 years ago
From Kyle Hazelwood:
As many of you are aware the Operators have been reporting that the MI and RR loss plots have been failing (SA4001 and SA4022). I thought I’d list what I know in hopes of finding a fix.
- I originally thought this was a DPM issue
- Toggling the DPM to old seemed to fix the displays on a couple occasions
- Yesterday both the MI loss plot and RR loss plot died at around the same time. The plots were on different consoles with one on the new DPM and the other on the old DPM. It is probably not a DPM issue.
- I believe the majority of instances the plots are not actually dying but rather showing stale blm readings, the majority of stacktraces I get are from Operators aborting the displays
- The stacktraces from instances when the display was not aborted are not consistent.
- The plots run without issue for a day or so before “dying”, though sometimes they “die” immediately upon restart.
- Occasionally, when the plots are restarted they show one pulses losses with an old timestamp (Sometimes from hours ago) and never show further updates. I believe this suggests the BLM profile buffer is stale.
- Twice now the Operators have resorted to restarting all the BLM nodes to get the displays working and this does fix the problem
I’m adding some error checking to the displays to try and capture what is actually happening.
#8 Updated by Richard Neswold over 2 years ago
- Target version set to DPM v1.6
This fix: 945cf54f
Fixed a bug when a request timed out, it wasn't restarted (so DPM_PENDs were reported forever.)
Fixed a bug when requests were being removed from a combined request.
Please test your application against
FGATE by entering the following on your console and then running your app (the title bar of the window should show
FGATE as the name of the DPM being used.)
Let me know if this seems to fix your problem.