From: ebiederm@xmission.com (Eric W. Biederman)
To: Steffen Persvold <sp@scali.no>
Cc: nick@snowman.net, Girard Roudier <groudier@club-internet.fr>,
lkml <linux-kernel@vger.kernel.org>,
davej@suse.de, troels@thule.no
Subject: Re: ServerWorks LE and MTRR
Date: 30 Apr 2001 02:55:26 -0600 [thread overview]
Message-ID: <m1bspercld.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0104291813490.32327-100000@ns> <3AEC9823.EEC8EC46@scali.no>
In-Reply-To: Steffen Persvold's message of "Sun, 29 Apr 2001 17:39:31 -0500"
Steffen Persvold <sp@scali.no> writes:
> nick@snowman.net wrote:
> > On Sun, 29 Apr 2001, Steffen Persvold wrote:
> >
> > > I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a
> > > Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption
> on
>
> > > the last double word (4 bytes) in a 64 byte PCI burst when I use write
> > > combining on the CPU. On the Tyan however the transfer is always ok.
> > >
> >
> > Are you sure that is not due to board design differences?
>
> No I can't be 100% certain that the layout of the board isn't the reason since
> I haven't asked ServerWorks about this and it doesn't say anything in their
> docs (yes my company has the NDA, so I shouldn't get to much in detail here),
> but if this was the case it would be totally wrong to disable write combining
> on any LE chipset.
>
> The test case that I have been using to trigger this is sort of special because
> we are using SCI shared memory adapters to write (with PIO) into remote nodes
> memory, and the bandwidth tends to get quite high (approx 170 MByte/sec on LE
> with write combining). I've been able to run this case on 5 different
> motherboards using the LE and HE-SL ServerWorks chipsets, but only two of them
> are LE (the DL360 and the S2510). Everything works fine with write-combining on
> every motherboard except the DL360 (which has rev 5).
>
> One basic test case that I haven't tried, could be to enable write-combining on
> your PCI graphics adapter memory and see if the X display gets screwed up.
>
> I will try to get some information from ServerWorks about this problem, but I'm
> not sure if ServerWorks would be happy if I told you the answer (because of the
> NDA).
I'd like to put my small plug in that this make me a little nervous.
It could also be a problem with the firmware (aka BIOS) missetting
something up. Working with linuxBIOS I have seen burst-writes
(enabled with write-combining or write-back) cause data corruption
when non-burst-writes to memory don't cause problems, when the memory
controller is setup wrong. (This is was with intel 440GX & 440BX
chipsets).
Eric
next prev parent reply other threads:[~2001-04-30 8:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-29 18:55 ServerWorks LE and MTRR Steffen Persvold
2001-04-29 17:05 ` Gérard Roudier
2001-04-29 21:05 ` Steffen Persvold
2001-04-29 22:14 ` nick
2001-04-29 22:39 ` Steffen Persvold
2001-04-30 3:35 ` Gérard Roudier
2001-04-30 8:55 ` Eric W. Biederman [this message]
2001-04-30 1:06 ` Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2001-04-30 13:44 Mark_Rusk
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=m1bspercld.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=davej@suse.de \
--cc=groudier@club-internet.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=nick@snowman.net \
--cc=sp@scali.no \
--cc=troels@thule.no \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.