This is close to How Things Should Be. Each umass target having its own SIM and bus is indeed wrong, but I'm not sure if it's correct for all USB controllers and buses to be under a single SIM. What would be the most correct is for each physical USB controller/bus instance to have its own SIM instance. I don't know if it's better to do the attachment in ehci/ohci/uhci controller drivers or in usb bus driver; up in the controller drivers is probably more correct. I don't like this hack of attaching stuff in a SYSINIT. Scott Hans Petter Selasky wrote: > 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_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"Received on Thu Sep 11 2008 - 20:45:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC