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/