From owner-cvs-all@FreeBSD.ORG Wed Sep 8 17:45:10 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 72ACE16A4CE; Wed, 8 Sep 2004 17:45:10 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF29343D55; Wed, 8 Sep 2004 17:45:09 +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 i88Hj7n7078069; Wed, 8 Sep 2004 13:45:07 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i88Hj7LS078068; Wed, 8 Sep 2004 13:45:07 -0400 (EDT) (envelope-from green) Date: Wed, 8 Sep 2004 13:45:06 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20040908174506.GE928@green.homeunix.org> References: <20040908130741.GC928@green.homeunix.org> <20040908.083215.102654981.imp@bsdimp.com> <20040908152956.GD928@green.homeunix.org> <20040908.112100.102577181.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908.112100.102577181.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 17:45:10 -0000 On Wed, Sep 08, 2004 at 11:21:00AM -0600, M. Warner Losh wrote: > In message: <20040908152956.GD928@green.homeunix.org> > Brian Fundakowski Feldman writes: > : On Wed, Sep 08, 2004 at 08:32:15AM -0600, M. Warner Losh wrote: > : > In message: <20040908130741.GC928@green.homeunix.org> > : > Brian Fundakowski Feldman writes: > : > : On Wed, Sep 08, 2004 at 01:20:31AM -0600, M. Warner Losh wrote: > : > : > In message: <200409080713.i887Dd54058789@repoman.freebsd.org> > : > : > Warner Losh writes: > : > : > : imp 2004-09-08 07:13:39 UTC > : > : > : > : > : > : FreeBSD src repository > : > : > : > : > : > : Modified files: > : > : > : sys/dev/usb ugen.c > : > : > : Log: > : > : > : Back out 1.88. > : > : > 1.87 I mean. > : > : > : The reference counts are there to block detach until the sleepers in > : > : > : read/write/ioctl have gotten out, not to prevent the open device from > : > : > : going away. Restore the old behavior so that we have a chance to wake > : > : > : up sleepers when the usb device goes away, so they can properly return > : > : > : EIO back to the caller when this happens. > : > : > : > : > : > : Otherwise, we have a guarnateed panic waiting to happen when a device > : > : > : detaches with an active read channel. > : > : > : > : > : > : This should be merged to 5 asap. > : > : > : > : Now I'll get guaranteed panics using both my Palm and any CardBus hardware. > : > > : > Can you send me a traceback for that problem then? The 'reference > : > count' here is very much supposed to be a 'how many sleepers do you > : > have' sort of thing and is present in nearly all of the usb drivers. > : > : No, I'd prefer not to have to crash my machine more. It already does that > : (or hangs, or whatever) in -CURRENT often enough. > : > : (Holding breath for open sourced Solaris.) > > Brian, > > Since I backed out your fix, that puts me on the hook to fix > the problem that you made the change for. If you provide me with some > information about how to reproduce it, I'll be happy to look into the > problem. The above is only enough to let me guess at what might be > going on. > > I'm sorry I committed without talking to you first, but the above > change cost myself and my boss a couple of days of debugging time on > one of our products that keeps ugen open to monitor it until it goes > away. I was understandably grumpy at having my time wasted like this > when I discovered why things broke :-(. Why would you get a panic at detach if the refcount is held for every open channel? Whether or not a read is in progress, the reference held for the entirety of the channel being open should help. I don't see how you would _not_ get the EIO in any place you would have gotten it before. If you destroy the device before the device is closed then subsequent d_close() calls are going to crash when the freed softc is referenced. If I had to name every bug or misfeature I had to spend countless hours trying to find and fix, I would be sitting here unhappy for a very long time, too. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\