On 17/06/10 10:00, Youssef Bengelloun-Zahr wrote:
Hello again Jeroen,
Looked at the Cisco page regarding resolved caveats regarding
12.2(33)SXH rebuilds, only found entry CSCsm84267 about
%CPU_MONITOR-SP-6-NOT_HEARD but the symptoms doesn't match our case.
Still digging.
Well, my comment was related to whether SXI worked for the feature set
you asked about, rather than your original %CPU_MONITOR issue.
Having said that: I'm fairly sure the SXH and SXI have significant
differences in the way IPC happens, some of which is related to ISSU,
some of which seems to be more aggressive monitoring (or even just
logging of such)
We've had %XDR_* errors where standby supervisors "go away"; TAC claimed
it was a hardware fault, but to my mind that's not credible, especially
since the hardware passes full GOLD diags in our test chassis, and
various combinations of reboots and upgrades made it "go away".
[Having said that: TAC basically say "duh RMA the sup" about 50% of the
time in cases like this. Some engineers seem to think memory corruption
twice in a row means hardware fault, because of course memory corruption
can't come from a software bug. We end up having to explain "memory
santiy debug" to them, and the fact that corruption might not have been
caused by the process that triggered the traceback...]
In short; I think all this infrastructure changed from SXF to SXH/SXI
and I think the early versions had bugs. I know from past experience
that Cisco don't necessarily expose all bugs fixed in the bug toolkit,
so there may be a bug that matches yours and I'd just upgrade and see if
it stops.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
