Exactly! The only way to determine 100% if it's a hardware problem or software problem is to either go through TAC for a bug scrub, try a known good version for the features you are using, or go through the code one line at a time and figure out why the SegV happened. I was just pointing out that it's impossible to know with 100% certainty if it's software or hardware corrupting that memory location. Most software crashes are caused by things such as buffer overruns, NULL pointers, etc. But sometimes it's the hardware flaky out and causing it, not the software. That's why unfortunately TAC is the only solution unless you have a spare chassis and can swap it out to see if the problem follows the IOS, or the chassis. Ken
________________________________ From: David Rothera [mailto:[email protected]] Sent: Thu 11/11/2010 3:13 PM To: Eninja Cc: Matlock, Kenneth L; Dominic Ogbonna; <[email protected]> Subject: Re: [c-nsp] Unstable IOS Version for LNS on Cisco 7206 NPE-G2 I think the point that myself and others were trying to put across was rather than purely head towards it being a SW issue log a case with TAC and get them to look into it. On Thu, Nov 11, 2010 at 9:49 PM, Eninja <[email protected]> wrote: Rather than speculate, do you have an actual example of a crash that IOS reported as 'SegV exception' that was caused by failed hardware? _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
