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.
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
