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 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. _______________________________________________ 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"
