From owner-freebsd-alpha Fri Jul 21 16:53:23 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 9D1CA37C182 for ; Fri, 21 Jul 2000 16:53:19 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id RAA01857; Fri, 21 Jul 2000 17:02:43 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007220002.RAA01857@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE In-reply-to: Your message of "Fri, 21 Jul 2000 20:32:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jul 2000 17:02:43 -0700 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > = > = > On Thu, 20 Jul 2000, Mike Smith wrote: > = > > > It is my opinion. You may disagree but it will hard for anybody to > > > convince me that I am wrong. ;-) > > = > > On x86, it's very hard for you to be right; the CPU specification and= bus > > bridge behaviour both guarantee retirement of writes in order of issu= ance. > > This combined with strong cache coherency makes barriers irrelevant o= n > > this platform. > = > Let a PCI device perform: > STORE A > STORE B > = > Let the CPU perform and expect: > LOAD B > LOAD A > = > Let some CPU speculative execution carry out to the system BUS: > LOAD A > LOAD B > = > My reading of the the Intel docs didn't convince me that such reorderin= g > is not possible. > = > Typically A is some indicator of an IO completion pushed to a completio= n = > queue and B is the associated status data. You've got those the wrong way around; A will be the status, and B the = indicator (since we have to assume the peripheral is correctly designed).= I don't believe that the x86 re-orders read operations (but I don't have = the P6 architecture manuals here to be certain). If it does, then to = remain compatible with older x86 processors, it would have to invalidate = the pipeline and re-fetch when the bus snoop code detected the STORE B. > > As far as other platforms are concerned, however, you're quite correc= t. > = > Are you still so sure. ;-) Yes. x86 has so much seralised legacy baggage that it's a special case. = = Everyone else needs help. 8) > > There does need to be an extension to the busspace API to define a ra= nge = > > of host memory with a tag/handle pair for barrier activity. > = > Hmmm... Barrier semantics vary so much between architectures that an > unified semantic that also address device driver's concerns (not only > CPU<->CPU) is either close to impossible or will just be extremally poo= r, > in my opinion. I'm open to edification here, but I think that the ability to define the = sort of barrier operation required for a memory region and to then = invoke said barrier is about the best we can hope for. > The drivers I maintain will always contain any stuff needed for them to= be > as correct as I want them to be, modulo my knowledge and competence on > addressed platforms obviously. I don't think anyone could ask for any more than that. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message