Re: update on inode problem

[Igor Gueths <igueths@attbi.com>]

Hi Kerry. I will check into the bad ram. Unfortunately, I do not have
another Linux box to test whether it is something I am doing wrong or a
corrupt bit in my ram. I will check out that url. In the meantime, would
anyone possibly be interested in testing the filesystem I am currently
working with? This would involve either uploading the entire iso from me
or just putting the filesystem on a floppy. Then create another floppy
containing a kernel of your choice. Note that BLK_DEV_LOOP, FAT, MSDOS_FS,
PROCFS, EXT2, BLK_DEV_RAM, and ISO9660. The only problem is that my upload
is unfortunately limited to about 40 KBPS. Please mail me off-list if
interested. Thanks!

May you code in the power of the source,
may the kernel, libraries, and utilities be with you,
throughout all distributions until the end of the epoch.

On Sun, 10 Nov 2002, Kerry Hoath wrote:

> 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
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>