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?
I sprinkled some calls to printf() inside u3g_test_autoinst(). It looks
like it is never getting called the first time the device is plugged in.
Strangely, it seems to be called twice after I do
camcontrol eject cd0
but it just returns both times because bInterfaceClass is 255 and not
When I unplug the device and then plug it in again, u3g_test_autoinst()
gets called when the device first appears. It ejects the umass device,
and then gets called again (doing nothing) when the u3g device appears.
> U3G patch looks OK.
> The SCSI quirk is not needed. This should be fixed in the SCSI stack!
I did some more debug and the umass device does seem to be readable even
without the quirk, even though there were READ(10) failures earlier.
I'm also unable to reproduce the panic. I think it's probably a hard to
trigger race condition in CAM.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"