Date: Thu, 20 Jul 2000 20:18:53 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <Pine.LNX.4.10.10007201951140.1699-100000@linux.local> In-Reply-To: <200007192341.QAA27822@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jul 2000, Mike Smith wrote:
> > I think I have a fix. It feels like overkill, but if the programming
> > interface of the chip does not allow for something better why not just
> > turn off DMA while we update cb_command?
>=20
> The gotcha with this is of course that you have no idea what "turning off=
=20
> DMA" actually entails. If the chip is in the middle of a DMA operation,=
=20
> what happens then? Do you lose the entire DMA? Does it keep going? How=
=20
> often does the chip test the flag, etc...
>=20
> > Can a PCI expert comment on its safety? Mike?
>=20
> I think the approach you've taken with using atomic updates is definitely=
=20
> the right one.
I donnot think so. ;-)
Here are some of the reasons:
1) Use of Load/Locked Store/Conditional CPU instructions to synchronize=20
with another agent on the system BUS requires the other agent to=20
implement some given protocol for the involved access. The other agent=
=20
is the host bridge as you know and not another CPU.
What's our knowledge about the behaviour of the bridge?
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 only win of this patch is that it (seems to?) work, and obviously user=
=20
want to use it. Early committing it is another story and you can count me=
=20
as opposed to this commit. ;-)
What is 100% sure is that the change does force a memory barrier before
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=20
system BUS.
As a result ( applying to my opinion ;-) ), when a PCI device and its
software driver communicates through the main memory, it is _very_ likely
memory barrier to be needed in some places so that program-expected
ordering as seen from the system BUS will happen.
G=E9rard.
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.LNX.4.10.10007201951140.1699-100000>