Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 13.0.0
Fixed In:
13.1.0, 13.0.0 HF1, 12.1.2 HF1, 11.6.2, 11.5.4 HF3
Opened: Dec 15, 2016 Severity: 3-Major
A new db variable has been added to print diagnostic information when Cavium Nitrox devices encounter a 'request queue stuck' error. When this occurs, the system posts a log message such as: crit tmm1[19936]: 01010260:2: Hardware Error(Co-Processor): cn1 request queue stuck.
The system will automatically run 'nitrox_diag' to collect diagnostic information to help F5 determine the cause of the queue stuck error before rebooting. The system immediately fails over to the standby system, but will then spend approximately one minute gathering diagnostic information before rebooting. See https://support.f5.com/csp/article/K95944198 for more information about nitrox_diag.
-- A Cavium Nitrox 'request queue stuck' error occurs. -- The db variable 'crypto.ha.action' is set to reboot.
None.
The system now automatically gathers nitrox data collection when request queue stuck errors occur.
Under rare conditions, the system will take approximately one additional minute to reboot. If a Cavium Nitrox 'request queue stuck' error occurs and the db variable 'crypto.ha.action' is set to reboot, the system will automatically run 'nitrox_diag' to collect diagnostic information to help F5 determine the cause of the queue stuck error before rebooting. When the error happens, failover to the standby system will still happen immediately. The delay occurs only on rebooting the system that has already gone to standby mode.