Date: Wed, 20 Nov 2013 15:59:21 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: hps@bitfrost.no Cc: freebsd-usb@FreeBSD.org Subject: Re: U3GINIT_SCSIEJECT quirk Message-ID: <201311202359.rAKNxLcW005292@gw.catspoiler.org>
next in thread | raw e-mail | index | archive | help
On 19 Nov, Don Lewis wrote: > I did figure out why the eject isn't happening the first time that the > device is plugged in. The problem is that u3g_driver_loaded() isn't > getting called (to register the event handler) until the u3g device > appears. This device first shows up as a umass device, and the u3g > device doesn't appear until I do "camcontrol eject". > > It works the next time the device is plugged in because the event > handler is already registered. > > I've got u3g built into my kernel. I don't know if it might work better > if I was using u3g as a module, but I think it would be racy. Plugging > in the device would cause devd to kldload the module, which would then > register the event handler. I don't know if that would happen before > usb_probe_and_attach() called EVENT_HANDLER_INVOKE(), but that sounds > unlikely. > > If u3g is built in, I think the best fix would be to somehow register > the event handler during the boot sequence before we start attaching the > USB devices. Mystery solved! I had assumed that u3g was built into my kernel because I had assumed that it was included in the GENERIC kernel config file, which I include in my kernel config. That turns out to be incorrect. The u3g driver was getting kldloaded by devd after I did the "camcontrol eject". It turns out that was happening even before I added the new PID because the device changes its PID to a value that was already compiled into the driver when it switches from umass to u3g mode. If the driver is compiled into the kernel, there is a SYSINIT that should register the event handler during boot. In the case of a module, adding this to /boot/loader.conf makes all the right things happen, even on the first insertion of the device: u3g_load="YES" The SCSI quirk is still an open issue, but it's sort of academic because the eject happens before the cd device even appears, so the problem that I think are occurring during geom tasting don't get triggered. There is also the hard to trigger CAM panic that I stumbled across, but the fast automatic eject should avoid that problem as well. It's something that should be tracked down and fixed though.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311202359.rAKNxLcW005292>