Date: Thu, 20 Jul 2000 15:00:59 -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: <200007202201.PAA00657@mass.osd.bsdi.com> In-Reply-To: Your message of "Thu, 20 Jul 2000 20:18:53 %2B0200." <Pine.LNX.4.10.10007201951140.1699-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Can a PCI expert comment on its safety? Mike? > > = > > I think the approach you've taken with using atomic updates is defini= tely = > > the right one. > = > I donnot think so. ;-) I've considered this and, in this instance, I disagree with you. > Here are some of the reasons: > = > 1) Use of Load/Locked Store/Conditional CPU instructions to synchronize= = > with another agent on the system BUS requires the other agent to = > implement some given protocol for the involved access. The other age= nt = > is the host bridge as you know and not another CPU. > What's our knowledge about the behaviour of the bridge? The behaviour of the PCI bridge is defined by the EV6 bus protocol, and = it is required to behave correctly with regards to these instructions. > 2) We also ignore the width of the access performed by the PCI device. > Is it a 16 bit access or a full DWORD access. This is defined by the relevant Intel datasheet; it is a 16-bit access to= = the status word. > And how will the memory controller do the memory access if 16bit: > A) Use 16 bit atomic modify (if supported by the hardware) ? > or > B) Read a full DWORD atomically, clear the bit, Modify the full DWOR= D ? This is irrelevant, since both the CPU and the PCI bridge are talking to = the memory controller, so from either perspective the 16-bit cycle is = atomic. > As a result ( applying to my opinion ;-) ), when a PCI device and its > software driver communicates through the main memory, it is _very_ like= ly > memory barrier to be needed in some places so that program-expected > ordering as seen from the system BUS will happen. I am inclined to agree with you that there are probably cases in the fxp = driver where the author has made assumptions regarding the x86 normal = behaviour of retiring writes in program order, however that's not the = issue that this change is trying to address. -- = =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?200007202201.PAA00657>