From owner-freebsd-alpha Thu Jul 20 13:15:41 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B73637C24E for ; Thu, 20 Jul 2000 13:15:23 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from nas1-93.guy.club-internet.fr (nas1-93.guy.club-internet.fr [195.36.205.93]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA06222; Thu, 20 Jul 2000 22:14:48 +0200 (MET DST) Date: Thu, 20 Jul 2000 21:54:24 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Andrew Gallatin Cc: mjacob@feral.com, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE In-Reply-To: <200007201911.PAA15726@gale.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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