Re: Possible dcache BUG

[V13 <v13@priest.com>]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Friday 20 August 2004 18:06, Gene Heskett wrote:
> On Friday 20 August 2004 03:33, Marcelo Tosatti wrote:
> [...]
>
> >> >I can't see how that could be caused by flaky hardware.
> >>
> >> 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!!!
>
> The latest output of memburn after a bit of format hacking:
>
> FAILED at round 78/165714207: got 0000ff00, expected 00000000!!!
> REREAD: 0000ff00, 0000ff00, 0000ff00!!!
>
> and
>
> FAILED at round 160/200780831: got 02025302, expected 02020202!!!
> REREAD: 02025302, 02025302, 02025302!!!
>
> So it appears that its the third byte of 4 each time thats fubar'd.
> I'l run it a few more times to confirm.  Is memory byte wide per chip
> on these things today?

I had a simillar problem some years ago. I had core dumps and gcc errors all 
the time but memtest could not find a thing. 99% it was a CPU problem and not 
a memory problem. It seemed that there were errors at random times even when 
there was no cpu load.

I believe it was a cache problem. I made a simple prog (like memburn) that 
allocated memory blocks and then did some read/write on them (alloc+write 5 
blocks, check 1, free 1, alloc+write 6, check 2, free 2 alloc+write 7....). 
After that whenever the program encountered an error it looped on this block 
forever. 

The errors occured after a random period of time (from 1 block allocation to 
more than an hour) and were never reproduced after a stop/start. When this 
test program was running and looping on the bad block, gcc never displayed 
errors. The problem was fixed when I replaced the CPU and I'm still using the 
same DIMMs without problems. I also did a lot of checks before replacing the 
CPU, like changing the position of the DIMMs, removing one of them, change 
their timing, and much more without success. Even removed all the PCI cards.

Disabling the CPU cache or replacing it can be a good test.

<<V13>>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]