Date: Thu, 20 Jul 2000 11:56:20 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Mike Smith <msmith@FreeBSD.ORG>, Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <Pine.BSF.4.10.10007201149120.45697-100000@beppo.feral.com> In-Reply-To: <Pine.LNX.4.10.10007201951140.1699-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 agent > is the host bridge as you know and not another CPU. > What's our knowledge about the behaviour of the bridge? The Alpha Architecture reference manual is a little ambiguous about this, but it is our belief (based on feedbacdk from this list) that the memory subsystem must be architected such that it doesn't matter whether or not it is a CPU or any other device. > > 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. > 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 DWORD ? The underlying instruction covers either 32 or 64 bits. In the FreeBSD alpha implementation, the 64 bit instruction is used (maybe overkill) and shifts and ors and masks are done as appropriate. The object being changed is 16 bits, so the usage is correct. As long as either the 32 or 64 bits of address fully overlaps the access that the PCI device will be making (which is likely to be an RMW cycle), the semantics of the interlock will guarantee that the disparate size of access will be irrelevant. > the offending instruction and after it. I donnot seem to see that just > adding these 2 barriers has been investigated. This should be tried, IMHO. > As you know modern CPUs do speculative executions and other optimizations > that may reorder LOADs and STOREs in a way that can break programmer > assumptions about ordering of LOADs and STOREs when carried out to the > system BUS. A memory barrier here would not help since they are implied by the ldq_l/stq_c pair, but, hell, let's put one just for grins. Drew? -matt 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.BSF.4.10.10007201149120.45697-100000>