Date: Fri, 21 Jul 2000 17:02:43 -0700 From: Mike Smith <msmith@freebsd.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <200007220002.RAA01857@mass.osd.bsdi.com> In-Reply-To: Your message of "Fri, 21 Jul 2000 20:32:00 %2B0200." <Pine.LNX.4.10.10007211948560.1465-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> = > = > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007220002.RAA01857>