From owner-cvs-src@FreeBSD.ORG Wed Sep 8 20:59:21 2004 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 0774516A4CE; Wed, 8 Sep 2004 20:59:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B2243D48; Wed, 8 Sep 2004 20:59:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i88KwHbt052397; Wed, 8 Sep 2004 14:58:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 08 Sep 2004 14:58:46 -0600 (MDT) Message-Id: <20040908.145846.71090050.imp@bsdimp.com> To: green@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040908174506.GE928@green.homeunix.org> References: <20040908152956.GD928@green.homeunix.org> <20040908.112100.102577181.imp@bsdimp.com> <20040908174506.GE928@green.homeunix.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-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: Wed, 08 Sep 2004 20:59:21 -0000 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. Warner