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
>> ejected.
> Hi,
> 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
USB devices.

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to