From owner-freebsd-usb@FreeBSD.ORG Thu Sep 11 14:24:22 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194811065671; Thu, 11 Sep 2008 14:24:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AEC4E8FC28; Thu, 11 Sep 2008 14:24:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m8BENaX2060103; Thu, 11 Sep 2008 08:23:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 11 Sep 2008 08:24:18 -0600 (MDT) Message-Id: <20080911.082418.775964060.imp@bsdimp.com> To: rink@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080911103343.GH1413@rink.nu> References: <48B3299F.5080101@vwsoft.com> <200809111013.23994.hselasky@c2i.net> <20080911103343.GH1413@rink.nu> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: volker@vwsoft.com, fbsd-current@mawer.org, current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 14:24:22 -0000 In message: <20080911103343.GH1413@rink.nu> Rink Springer writes: : On Thu, Sep 11, 2008 at 10:13:22AM +0200, Hans Petter Selasky wrote: : > I also see crashes with my new stuff and the umass driver when the USB device : > is un-plugged too early. The backtraces I've got so far does not indicate a : > USB problem, though .... : : That is correct, this is a bug in CAM. More specifically, CAM does not : handle the removal of busses well. There are two possible options: : : 1) Obviously, fix CAM to handle this scenarion : DragonflyBSD seems to have a lot of fixes in this area, which I : intend to take a look at 'some day' (no thanks to $reallife...) This is the better option. : 2) Create a CAM bus per USB bus : I think this is reasonable, and it makes a lot more sense than the : one-bus-per-device approach that we have now. The idea is that : every USB controller hub creates a CAM bus, and umass(4) attaches to : this bus instead of creating its own. Of course, until CAM is fixed, : detaching PCMCIA or equivalent USB cards will still cause panics, but : it would be a lot better than it is now... This would mitigate the problem, but there's a lot of people that use CardBus USB cards, and they complain to me from time to time of the problem. Fortunately, the wireless broadband cards that are a usb host controller plus usb device in CardBus format aren't affected... : Personally, I'd like to see option 2 implemented in the USB2 stack, as : it avoids the issue and makes a lot more sense from user perspective : (I'm probably onot the only one who gets scared by 'camcontrol devlist' : if you have a single MP3 player which advertises 2 disks :-)) It may make good sense for other reasons as well. Firewire does something similar, and also umass used to do exactly this. There's also problems right now with huge bus load leading to devices disconnecting and reconnecting for some suck-ass, but common, chipsets. If things were implemented this way, then there'd be options to silently reconnect the device when it goes away and comes back a few hundred milliseconds later... Firewire handles this case too, at the expense of never disconnecting the disk, which isn't so good for a thumb drive... Warner