public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Heflin <rogerheflin@gmail.com>
To: linasvepstas@gmail.com
Cc: Alistair John Strachan <alistair@devzero.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: amd64 sata_nv (massive) memory corruption
Date: Sat, 02 Aug 2008 16:55:18 -0500	[thread overview]
Message-ID: <4894D7C6.8030804@gmail.com> (raw)
In-Reply-To: <3ae3aa420808011951l58da4010r1ff0876f255565b0@mail.gmail.com>

Linas Vepstas wrote:
> 2008/8/1 Alistair John Strachan <alistair@devzero.co.uk>:
>> On Friday 01 August 2008 18:30:34 Linas Vepstas wrote:
>>> Hi,
>>>
>>> I'm seeing strong, easily reproducible (and silent) corruption on a
>>> sata-attached
>>> disk drive on an amd64 board.  It might be the disk itself, but I
>>> doubt it; googling
>>> suggests that its somehow iommu-related but I cannot confirm this.
>> Nowhere do you explicitly say you have memtest86'ed the RAM.
> 
> It passes memtest86+ just fine. The system has been in heavy
> use doing big science calculations on big datasets (multi-gigabyte)
> for months; these do not get corrupted when copied/moved around
> on the old parallel IDE disk, nor moving/copying on an NFS mount
> to a file server. Only the SATA disk is misbehaving.

That MB uses DDR2 so I don't know if this is useful or not, I saw the issue on 
MB's using DDR.

I have seen issues when using all 4 dimm slots on a number of MB's that only 
appear to show up on DMA when using fast dual core cpus, if the CPU is slower 
things work just fine, and if you don't do heavy use of network or disk things 
are just fine.   And these machines would pass memtest without any issues.

You might try slowing down the cpu to the slowest and see if you can still 
duplicate it, if you cannot, bring the speed up a step and retest, if it only 
happens at the highest speed, it might be something similar.   In the end the 
solution was to have the MB maker add an option in the bios to slow down the 
ram, in the DDR case we had 4 double sided dimms (8 loads on the CPU) and AMD 
documents said DDR memory with 6 or more loads needed to be running at 333 and 
not 400, and as I said I don't know if it also applies to DDR2 in a similar way. 
   Note that if we used a slower dual core cpu it did not push things hard 
enough to show the error either, I believe we had the issues with 280/285's but 
not with 275's and lower (these were dual socket boards, with 4 dimms on each 
cpu, 8 loads per cpu).

                                  Roger

  parent reply	other threads:[~2008-08-02 21:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01 17:30 amd64 sata_nv (massive) memory corruption Linas Vepstas
2008-08-01 20:51 ` John Stoffel
2008-08-02  3:06   ` Linas Vepstas
2008-08-01 22:19 ` Alistair John Strachan
2008-08-02  2:51   ` Linas Vepstas
2008-08-02 20:09     ` John Stoffel
2008-08-02 22:01       ` Linas Vepstas
2008-08-03  2:41         ` John Stoffel
2008-08-03 22:23           ` Linas Vepstas
2008-08-03 22:16             ` Alan Cox
2008-08-05 17:02               ` Linas Vepstas
2008-08-05 17:21                 ` Alan Cox
2008-08-06 21:33                   ` Linas Vepstas
2008-08-07  2:59                     ` Martin K. Petersen
2008-08-07  4:32                       ` Linas Vepstas
2008-08-07 16:42                         ` Martin K. Petersen
2008-08-07 17:23                           ` Linas Vepstas
2008-08-07 18:53                           ` John Stoffel
2008-08-07  7:45                     ` Pavel Machek
2008-08-02 21:55     ` Roger Heflin [this message]
     [not found] <fa.qB5d+HsAJ6G05jNoeU8Q9GV6Dow@ifi.uio.no>
     [not found] ` <fa.fxlDAHxOnGgcBiOH/EOauE67ZPc@ifi.uio.no>
     [not found]   ` <fa.1WYUmN6FHR5yW+sXoYRFN22Y8S8@ifi.uio.no>
     [not found]     ` <fa.LAUkvEUlYiF69V/F8F3wigxqH9w@ifi.uio.no>
     [not found]       ` <fa.mXeFXYNkfZfUYPQcGwzok0IOIfY@ifi.uio.no>
     [not found]         ` <fa.KjbvCGbUr2JeQTcwA1/sFGIIMik@ifi.uio.no>
2008-08-04  3:22           ` Robert Hancock
2008-08-05  5:29             ` Linas Vepstas
2008-08-05  6:36               ` Robert Hancock
2008-08-05 12:29               ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4894D7C6.8030804@gmail.com \
    --to=rogerheflin@gmail.com \
    --cc=alistair@devzero.co.uk \
    --cc=linasvepstas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox