From owner-cvs-all@FreeBSD.ORG Wed Sep 8 21:09:13 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C6716A4CE; Wed, 8 Sep 2004 21:09:13 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B570F43D5C; Wed, 8 Sep 2004 21:09:12 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i88L96Es079154; Wed, 8 Sep 2004 17:09:06 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i88L95sq079153; Wed, 8 Sep 2004 17:09:05 -0400 (EDT) (envelope-from green) Date: Wed, 8 Sep 2004 17:09:05 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20040908210905.GG928@green.homeunix.org> References: <20040908152956.GD928@green.homeunix.org> <20040908.112100.102577181.imp@bsdimp.com> <20040908174506.GE928@green.homeunix.org> <20040908.145846.71090050.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908.145846.71090050.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 21:09:13 -0000 On Wed, Sep 08, 2004 at 02:58:46PM -0600, M. Warner Losh wrote: > It turns out that Brian's change typically is the same as the old > code. However, there are a few cases where it isn't: > > (1) Where the application doesn't close the device when it gets an > error. Stupid application, I know, but in this case the device > never detaches. This is one of the things that caused our > appliction to die with the new code, but not the old code. phk's > work with deadfs and dev_t ref counting may help here. > > A simple cat /dev/ugenX.Y would behave the same both ways, but > buggy applications do behave differently. > > (2) It changes the timing of things such that my uhci controller > panics a little more often. This panic is 'related' to detach, > but not exactly directly. This seems related to interrupt load > and timing, but could be something else, like loadable modules. > > I'm not sure what the right thing to do architecturally about #1 is, > so for the moment I'm going to leave the change backed out. However, > I'll start a discussion on arch@ to see if some consensus can develop > as to the right thing to do in general. > > I'd also like to appologize to Brian for backing things out w/o > talking to him first. Like I said before, I let my frustration at > wasted time get the better of me. Either way, we should be able to fix "my" problem with the close() operation panicking the system easily by modifying the detach routine to wait for closes to happen without screwing with the refcount logic. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\