On Thursday 11 September 2008 02:44:42 pm Hans Petter Selasky wrote: > Hi, > > Would anyone object if I make one non-Giant locked CAM bus for all USB2 > devices? Something like: Ask scottl_at_, I think he had mentioned having one bus for all USB devices before. > 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_at_rink.nu> > > > > Rink Springer <rink_at_freebsd.org> 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 > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > -- John BaldwinReceived on Thu Sep 11 2008 - 19:43:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC