Re: "legacy" usb stack fixes

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