From owner-freebsd-usb@FreeBSD.ORG Thu Sep 11 18:42:53 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 C40ED106566B; Thu, 11 Sep 2008 18:42:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id CB3568FC22; Thu, 11 Sep 2008 18:42:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ZtwMFzhc6XSROYQlMkMA/A==:17 a=Oy1DYfew5nZeFjP_vPEA:9 a=FqOpp-xSOPsjGo8MRkMA:7 a=pSd-cDr9dDQpHpamyPJ9oN1o94AA:4 a=SV7veod9ZcQA:10 a=50e4U0PicR4A:10 Received: from [62.113.133.218] (account mc467741@c2i.net [62.113.133.218] verified) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 331725583; Thu, 11 Sep 2008 20:42:51 +0200 From: Hans Petter Selasky To: "M. Warner Losh" Date: Thu, 11 Sep 2008 20:44:42 +0200 User-Agent: KMail/1.9.7 References: <48B3299F.5080101@vwsoft.com> <20080911103343.GH1413@rink.nu> <20080911.082418.775964060.imp@bsdimp.com> In-Reply-To: <20080911.082418.775964060.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809112044.43749.hselasky@c2i.net> Cc: volker@vwsoft.com, current@freebsd.org, freebsd-usb@freebsd.org, fbsd-current@mawer.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 18:42:53 -0000 Hi, Would anyone object if I make one non-Giant locked CAM bus for all USB2 devices? Something like: static void umass_create_cam_bus_sysinit() { devq = cam_simq_alloc(1 /* maximum openings */ ); if (devq == NULL) { return (ENOMEM); } umass_global_sim = cam_sim_alloc (&umass_cam_action, &umass_cam_poll, DEVNAME_SIM, NULL /* priv */ , 0 /* unit number */ , #if (__FreeBSD_version >= 700037) &umass_global_mtx /* mutex */ , #endif 1 /* maximum device openings */ , 0 /* maximum tagged device openings */ , devq); return; } static void umass_destroy_cam_bus_sysuninit() { .... } SYSINIT(&umass_create_cam_bus_sysinit); SYSUNINIT(&umass_destroy_cam_bus_sysuninit); --HPS On Thursday 11 September 2008, M. Warner Losh wrote: > 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