From owner-cvs-src@FreeBSD.ORG Tue Apr 8 10:31:02 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2724337B410; Tue, 8 Apr 2003 10:30:59 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AAD943F75; Tue, 8 Apr 2003 10:30:59 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id F267D2ED411; Tue, 8 Apr 2003 10:30:58 -0700 (PDT) Date: Tue, 8 Apr 2003 19:30:58 +0200 From: Maxime Henrion To: Nate Lawson Message-ID: <20030408173058.GF1750@elvis.mu.org> References: <20030408130518.AD52137B496@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2003 17:31:02 -0000 Nate Lawson wrote: > On Tue, 8 Apr 2003, Maxime Henrion wrote: > > Modified files: > > sys/dev/fxp if_fxp.c > > Log: > > Fix the hangs people have been seeing. For some reason, the > > atomic operation change caused this, so backout it until I > > can figure out what's wrong with it. > > > > Revision Changes Path > > 1.163 +7 -11 src/sys/dev/fxp/if_fxp.c > > Thank you. > > > - atomic_clear_32((u_int32_t *)&last->tx_cb->cb_status, > > - htobe32(bswap16(FXP_CB_COMMAND_S))); > > - > > + atomic_clear_short(&sc->fxp_desc.tx_last->tx_cb->cb_command, > > + FXP_CB_COMMAND_S); > > +#else > > + sc->fxp_desc.tx_last->tx_cb->cb_command &= ~FXP_CB_COMMAND_S; > > +#endif /*__alpha__*/ > > Um, are each of those cases semantically equivalent? Yes they are. The only difference, and that's probably where the problem lies, is that we are now rewriting (but not changing) cb_status. The cb_status word is probably mapped to a register in the fxp(4) card and thus rewriting it might not be safe. Cheers, Maxime