Date: Tue, 15 Jun 2010 19:02:30 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Masoom Shaikh <masoom.shaikh@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: disable RAM parity error Message-ID: <4C17A416.7030909@icyb.net.ua> In-Reply-To: <AANLkTiksJ53X3eJcuZK8gjTpX7x3Nk1Fo-dITYDgYLa4@mail.gmail.com> References: <AANLkTinr7O6O95Kp_bQmlAULxkpR6Wus890VmhPqej6x@mail.gmail.com> <AANLkTiksJ53X3eJcuZK8gjTpX7x3Nk1Fo-dITYDgYLa4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 15/06/2010 08:34 Masoom Shaikh said the following: > Hello List, > > In continuation to my earlier mail, I am now convinced(nearly) that > the freezes faced by me are "RAM parity error" indeed. > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70730.html > > when using internet via wpi0, FreeBSD freezes are very prone to occur > compared to when I am using bfe0. But they do occur, due to some > reason it feels stable when connected via bfe0. > Over course of time I have accumulated some core.txt.<n> files, which > I have uploaded to pastebin and their links are below. My question is > why only FreeBSD minds about RAM parity error check, while latest > offering from Redmond does not ? > is there a way to IGNORE RAM parity check ? is it possible to get hold > of offending address from these core files ? > while I observe "stack pointer" and "frame pointer" have repeated > values in core files, I cannot conclude anything from this > observation. Anybody here care ? If I were you I'd be concerned with finding and replacing the flaky hardware instead of wasting time before disaster happens. As to why "other OS" doesn't report errors - it could have been the other way around, different OSes have different usage/load patterns and hit different hardware problems with higher probability. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C17A416.7030909>