Introduction:
This documents describes an issue of SDVs getting black screen because of difference of bandwidth between VSRM and RFGW10 (SQB1) release. This difference was caused mainly due to some bandwidth getting reserved without having a video session on it.
Problem Description & Troubleshooting:
- End user STB is seeing black screens on all SDV channels
- Many Service Groups were affected
- Debugs on VSRM show RmCmdFail, RmBwReqResSelectFail, RmResourceFail which means blocking events and no bandwidth available
- Debugs on RFGW show 'rfgw_gqi_session_create -> Tx [-805306363]: Unable to create Video Session [INSUFFICIENT QAM BANDWIDTH]'
- It was found that there is a difference in actual bandwidth on the RFGW and stated bandwidth on the VSRM
- Linecard switch over was performed to rule out issues with the card giving the wrong computations, but it did not resolve the issue.
- It found that QAM consumed reserved BW value of 3.75Mbps without having any video session on it
Qam-red 8/7.27 Downstream is down
RF Profile is not assigned
LQAM Group is not assigned
Annex B, Power: 35.0 dBmV
Frequency: 0 Hz , lane: -1, block: -1
Modulation: 256QAM, TSID: 0, QAM IDB_State: UP
Bandwidth Reserved for Video: 3750000 bps
Bandwidth Used: 0 bps
Bandwidth Total: 38810700 bps
Transport Mode: QAM_MODE_OFF Qam Owner: NONE
Qam License: Exists
Interleave Level: 2, FEC I: 32 FEC J: 4
SNMP LINK TRAP: Disabled
- BW denial during session creation for the QAM might result in Video blackout as the session is not established in RFGW10
- Removing QAM from QP did not help to resolve the issue
- Defaulting QAM configuration did not release the QAM reserved BW in RFGW10
Workaround:
Below are the steps provided as a work around for time being:
- Reload the peer SUP (redundancy reload peer), to remove the QAM stale BW entry in the standby SUP
- Do SUP switchover (redundancy force-switchover), to recover the system
Solution:
It is found to be a BUG and solution will be available in SQD Release.
