Skip site navigation (1)Skip section navigation (2)
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>