On 15 Nov, Hans Petter Selasky wrote:
> On 11/15/13 00:37, Don Lewis wrote:
>> My first question is how does U3GINIT_SCSIEJECT manage to ever work? It
>> seems like there would be chicken vs. egg issue here. The quirk is on
>> the u3g device, so how would it get activated until the u3g device is
>> attached? The u3g device doesn't appear until the umass device is
> Check the VID and PID of your USB device using usbconfig. Maybe it is
> not the same value in both cases?
> U3G patch looks OK.
Ok, I've committed the u3g patch.
> The SCSI quirk is not needed. This should be fixed in the SCSI stack!
I'm holding off committing the SCSI quirk.
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
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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"