Messages in this thread | | | Date | Thu, 15 Jul 1999 18:56:25 +0200 | From | Harald Koenig <> | Subject | Re: need multiple e2fsck runs |
| |
now the final notes about my problems: I got my memory replaced and there are no errors anymore (neither with memtest86 nor Daniel's test) and compilation doesn't corrupt fs anymore (still running the same 2.2.10-ac9).
thanks for suggestions and help, and sorry for the bandwidth about broken hardware:(
On Jul 12, Harald Koenig wrote:
> long tests during the weekend showed that it's bad memory in my case (or other > hardware problem, I'll replace memory tomorrow and we'll know for sure:-(. > > > thanks to Daniel Kobras <daniel.kobras@student.uni-tuebingen.de> I got a > nice small hack for testing ram which has only _very_ rare bit errors like in > my case. it allocates and reserves (almost) all memory, fills it with > all 1s (in my case) and then only sits there and tests the memory for changes > from time to time. > > in my case, in bytes with address regexp pattern 0x07[01].[159d]c68 and 0x07[89].[159d]468 > (just below 128M) sometimes bit 5 got cleared (0xff -> 0xbf) after many minutes > (usually many 10 minutes to hours). > > > this also matches the pattern which I found once when the emacs binary > was corrupted in buffer cache (do the decimal/octal/hex math yourself > and keep in mind that `cmp' starts counting at 1!) : > > # cmp -l /usr/bin/emacs.good /usr/bin/emacs.bad > 300137 355 255 > > and dropping bits in the ext2fs allocation bitmap pages can explain the `duplicate block's > which I got as only fs curruption pattern. > > > Harald > > PS: memtest86 really should be improved to do such a test "wait _long_ time for bit flips" > since it's now the 3rd time where I see/know such problems.
Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |