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:

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
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to