From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from executioner.lis.net.au ([203.35.83.3]) by speech.braille.uwo.ca with esmtp (Exim 3.35 #1 (Debian)) id 18At0K-0001OE-00 for ; Sun, 10 Nov 2002 09:24:00 -0500 Received: from uucp by executioner.lis.net.au with local-rmail (Exim 3.12 #1 (Debian)) id 18At0F-0000ea-00 for ; Mon, 11 Nov 2002 01:23:55 +1100 Received: from kerry by gotss1.gotss.net with local (Exim 3.12 #1 (Debian)) id 18Asd1-0004iw-00 for ; Sun, 10 Nov 2002 21:59:55 +0800 Date: Sun, 10 Nov 2002 21:59:55 +0800 To: speakup@braille.uwo.ca Subject: Re: update on inode problem Message-ID: <20021110215955.A18144@joana.gotss.net> References: <200211080832.gA88WUa15732@sunset.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200211080832.gA88WUa15732@sunset.net>; from rreid@sunset.net on Fri, Nov 08, 2002 at 12:32:29AM -0800 From: Kerry Hoath Sender: speakup-admin@braille.uwo.ca Errors-To: speakup-admin@braille.uwo.ca X-BeenThere: speakup@braille.uwo.ca X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: speakup@braille.uwo.ca List-Help: List-Post: List-Subscribe: , List-Id: Speakup is a screen review system for Linux. List-Unsubscribe: , List-Archive: On Fri, Nov 08, 2002 at 12:32:29AM -0800, Ralph W. Reid wrote: > Igor Gueths staggered into view and mumbled: > > > >Hi all. Well after digging into this problem a bit further, I figured out > >that the 1:0 reported in the errors about ext2_read_inode were refering to > >/dev/ram0 according to /usr/src/linux/Documentation/devices.txt. That ... > Hmmm. I wonder if this is an indication of a bit of bad RAM. I have > heard that Linux is not very tolerant of bad memory, but RAM problems > are rare enough that I have never heard exactly how they manifest > themselves. If all else fails (and I do mean _all_ else), you might Ram problems are quite regular. Unless you have ECC ram; it is not unheard of to have a few cells fail in the millions of cells in the average computer's sdram/dram/rdram etc. True; memory has become more reliable; but as we run it at faster clock rates; the margin for error deminishes. I had 1 failing bit in 3 sticks totalling 768 megabytes of sdram. The error would quietly corrupt a bit in 768 megabytes whenever that location got used. The error took 30 kernel compiles or 2-3 days to manifest itself in an md5 sum failure or segmentation fault etc. Testing all the memory in the machine with t he memory test at http://www.memtest86.com (you can enable a serial console at compile time) found the error reliably in 40-50 minutes. A switching of the sticks and watching the failing address tracked the module at fault. I removed and tested t he memory again. No errors. I then send the 256-meg stick back for replacement under Waranty. Now I have 768-meg of working memory and audio files or compresssed files do not become corrupt. I used to test the error by bzipping and unbzipping an iso image 10 times or more and checking for errors in the data. This was done on a backup of the image since it would reliably corrupt the original. Regards, Kerry. > try swapping memory module locations on your mother board to see if > this affects the situation at all. RAM failures are very rare, but > they can happen. The simple RAM test performed during system boot > can miss some memory errors, but this is pretty rare as well. I hope > you can get your system working soon. > > Have a _great_ day! > > > > -- > Ralph. N6BNO. Wisdom comes from central processing, not from I/O. > rreid@sunset.net http://personalweb.sunset.net/~rreid > Opinions herein are either mine or they are flame bait. > y = x ^ LOG_B (x, y) > > _______________________________________________ > Speakup mailing list > Speakup@braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup > > -- Kerry Hoath: kerry@gotss.net kerry@gotss.eu.org or kerry@gotss.spice.net.au ICQ: 8226547 msn: kerry@gotss.net Yahoo: kerryhoath@yahoo.com.au