[c-nsp] Odd error after Interface flap [GSR/Engine 5]
Oliver Boehmer (oboehmer)
oboehmer at cisco.com
Wed Aug 4 04:14:31 EDT 2010
> I have seen the same messages recently on several slots after TE
tunnels
> flap, but they caused a lot of issues (FIA errors, CEF disable and so
on).
>
> %EE48-3-QM_SANITY_WARNING: Few free buffers(0) are available in ToFab
FreeQ
> pool# 3
> %EE48-3-QM_SANITY_WARNING: Few free buffers(0) are available in ToFab
FreeQ
> pool# 1
> %EE48-3-QM_SANITY_WARNING: Few free buffers(0) are available in ToFab
FreeQ
> pool# 1
...
> %EE48-3-QM_SANITY_WARNING: ToFab FreeQ buffers depleted. Recarving the
ToFab
> buffers
> %EE192-3-BM_QUIESCE:
> Rx FIM/LIM failed to go idle. Value: 0x50000000
> -Traceback= 400312FC 4063DD24 4063DE50 40648B48 40648BAC 40636B08
40B13274
> 403CAC4C 40107ED4 400AF4A0 400DB2F4 400DB2E0
>
> The version is 12.0(33)S6 and the modules are Engine 5...
>
> It seems a bug. What would cause this?
I guess there are mulitple aspects here:
a) Something causes the buffers to be depleted
b) QM-sanity kicks in, notices that something is really wrong and tries
to remedy the lack of buffers by re-carving the pool
c) re-carving causes CEF issues
Are you able to reproduce the issue? If so, it might make sense to a)
try to disable qm sanity check and see if it makes a difference (no
hw-module slot <n> qm-sanity both), I somehow would expect you to see
other problems with traffic not going through, and b) work with TAC on
finding the cause why buffers are not freed up, and root cause of
FIA/CEF errors when re-carving the buffer (it doesn't surprise me, but
this should not happen).
oli
More information about the cisco-nsp
mailing list