Date: Tue, 18 Jul 2000 09:26:57 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Tony Griffiths <tonyg@OntheNet.com.au> Cc: mjacob@feral.com, David Greenman <dg@root.com>, Bernd Walter <ticso@cicely8.cicely.de>, Mike Smith <msmith@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <14708.21581.689293.987109@grasshopper.cs.duke.edu> In-Reply-To: <39740E1D.7F2AF81D@OntheNet.com.au> References: <Pine.BSF.4.10.10007180008390.41622-100000@beppo.feral.com> <39740E1D.7F2AF81D@OntheNet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Griffiths writes: > I'm stretching my memory synapses here but I seem to remember that the > actual 'lock' > h/w was part of the memory subsystem and didn't really care who or what > wrote to the > cache block that was locked. Ie. The same or another cpu or a device > DMA'ing to > anywhere in the cache block would clear the 'lock' flag causing a STx_C > to fail! > I thought of this, but the Green Book only seems to mention locking between CPUs, not as part of the memory subsystem. I then looked at the 21264 CPU manual. (http://ftp.digital.com/pub/Digital/info/semiconductor/literature/21264hrm.pdf) Paraphrasing from page 4-14, it says that when a load-lock instruction exectutes, it loads the data from the D-cache; if there is a miss, its associated cache line is filled in a clean state. When the store-conditional instruction executes, it is allowed to succeed if the associated cache line is still in the D-cache and can be made writable. This works because something else writing to the same cache line would make it invalid in the Dcache. Sure enough, the following patch works on a UP1000 (21164A). However, I'm uncertain about other CPUs. In particular, the 21164's description is more complex & I don't really understand it. Bernd -- Can you try this new patch on your machine (you have a 21164, right?): Index: pci/if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v retrieving revision 1.77.2.4 diff -u -r1.77.2.4 if_fxp.c --- pci/if_fxp.c 2000/07/13 07:53:06 1.77.2.4 +++ pci/if_fxp.c 2000/07/18 13:24:39 @@ -1051,11 +1051,25 @@ ifp->if_timer = 5; } txp->tx_threshold = tx_threshold; - + /* * Advance the end of list forward. */ + +#ifdef __alpha__ + /* + * On platforms which can't access memory in 16-bit + * granularities, we must prevent the card from DMA'ing + * up the status while we update the command field. + * This could cause us to overwrite the completion status. + */ + atomic_clear_short(&sc->cbl_last->cb_command, + FXP_CB_COMMAND_S); +#else + sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S; +#endif /* __alpha__ */ + sc->cbl_last = txp; /* Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 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?14708.21581.689293.987109>