Re: Possible dcache BUG

[Daniel Blueman]

I find that memtest86 [1] does a great job of checking memory, especially
since you can boot the available ISO image.

Perhaps worth a try here?

--- [1]

http://www.memtest86.com/

---

There is still that possibility Marcelo.  Someone recommended I get 
cpuburn and memburn, and before fixing the scanf statement (it was 
broken) in memburn, I had compiled it for a 512 meg test the first 
time, and a 768 meg test the next couple of runs.

All exited with errors like this:
Passed round 133, elapsed 4827.19.
FAILED at round 134/14208927: got ff00, expected 0!!!

REREAD: ff00, ff00, ff00!!!

[root@coyote memburn]# vim memburn.c
[root@coyote memburn]# gcc -o memburn memburn.c
[root@coyote memburn]# ./memburn
Starting test with size 768 megs..

Passed round 0, elapsed 44.36.
Passed round 1, elapsed 74.13.
Passed round 2, elapsed 105.12.
FAILED at round 3/25777183: got 2b00, expected 0!!!

REREAD: 2b00, 2b00, 2b00!!!

I've now rebuilt it with a better printf format string, and its 
running over 768 megs again.  But this time the round counter is up 
to 90 and still going...

Interesting too is that memburn has now allocated a 768 meg wide block 
5 times, and still no Oops.  Over a hundred megs in swap, but its 
still running.

I lost the BUG_ON patches in fs/buffer.c, this is now 2.6.8.1-mm2 (but 
I can go back if this fails of course)

Or can I just copy that 2.6.8-rc4/fs/buffer.c file over this one?

-- 
Daniel J Blueman

NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/