Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jul 2000 21:54:24 +0200 (CEST)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        mjacob@feral.com, freebsd-alpha@FreeBSD.ORG
Subject:   Re: fxp0 hangs on a PC164 using STABLE
Message-ID:  <Pine.LNX.4.10.10007202141260.1970-100000@linux.local>
In-Reply-To: <200007201911.PAA15726@gale.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help


On Thu, 20 Jul 2000, Andrew Gallatin wrote:

> On the last, (putting in a memory barrier) -- I object because its implic=
it
> in the atomic instructions & would be totally superfulous.  An addition=
=20
> to the comment to point this out might be appropriate though..

This has been a misunderstanding.

> WRT memory barriers on i86 -- I though that writes to device memory space
> were uncachable & flushed the write buffers unless an mtrr was set
> up for the region & it was made cacheable.  I defer to the i86 experts..
> As for flushing writes to main memory for better device communication,
> I have no clue..

We are speaking about a PCI device and its driver sharing main memory.
There are ordering issues in such situations even for IA32 due to
possible reordering of LOADs notably.

Only considering ordering of IO/MMIO is not enough when the PCI device=20
and its software driver communicates through the main memory.
The NewBus IO/MMIO stuff does not help here. At most, it may be enough=20
for device/driver pairs that only communicate through IO/MMIO.

I want to say that any PCI device / software driver pair that share main
memory (for command queues, for example) that donnot use additional
explicit memory barriers are very likely to be broken on modern RISC
processors and may also be broken on PII/PIII if processor ordering (as
described by Intel) is not enough for ordering to be as program expects.

It is my opinion. You may disagree but it will hard for anybody to
convince me that I am wrong. ;-)

  G=E9rard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10007202141260.1970-100000>