ECC prevents parity error crashes through error correction. So, if you have a bad RAM and your IOS device has no ECC, it will crash and the error handling code will print a sig 20, sig 22, PMPE, etc. depending on where the parity errors were found. Not a SegV.
Furthermore, IOS has processes that constantly validate the integrity of its memory data structures eg checkheaps. Quite a few people read these threads for support. Therefore, It will be irresponsible to encourage them to schedule maint windows and start ripping out their DRAMs for SegV exceptions that are *clearly* caused by software bugs in IOS. I understand some folks enjoy commenting, but it should always be to add value rather than throwing out unfounded speculations without factual data to back it up. /eninja ex-Technical Leader - OS & big fat (and skinny) routers. On Nov 12, 2010, at 3:17 AM, Gert Doering <[email protected]> wrote: > Hi, > > On Fri, Nov 12, 2010 at 12:55:23AM -0800, Eninja wrote: >> Either way, I'd hate to bust your bubble and this is the last time I'll say >> this, SegV exceptions in IOS are always caused by software bugs. > > You don't seem to understand anything about hardware failure modes. > > If you have a bad RAM that will change a pointer value for you *without* > triggering a RAM parity error (because it's on a platform that has no > ECC/parity, like 'early 7200 NPEs'), and the software uses that pointer, > and accesses a bad memory location *because the RAM corrupted the pointer*, > how can the resulting SegV be "always a software bug"? > > gert > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany [email protected] > fax: +49-89-35655025 [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
