Date: Thu, 11 Sep 2008 08:24:18 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: rink@freebsd.org Cc: volker@vwsoft.com, fbsd-current@mawer.org, current@freebsd.org, freebsd-usb@freebsd.org, hselasky@c2i.net Subject: Re: "legacy" usb stack fixes Message-ID: <20080911.082418.775964060.imp@bsdimp.com> In-Reply-To: <20080911103343.GH1413@rink.nu> References: <48B3299F.5080101@vwsoft.com> <200809111013.23994.hselasky@c2i.net> <20080911103343.GH1413@rink.nu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20080911103343.GH1413@rink.nu>
Rink Springer <rink@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080911.082418.775964060.imp>