Re: U3GINIT_SCSIEJECT quirk

2013-11-20 Thread Don Lewis 
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:
u3g_load="YES"

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
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: U3GINIT_SCSIEJECT quirk

2013-11-19 Thread Don Lewis 
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"

Re: U3GINIT_SCSIEJECT quirk

2013-11-19 Thread Don Lewis 
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?

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
UICLASS_MASS.

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.

___
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"

Re: U3GINIT_SCSIEJECT quirk

2013-11-18 Thread Don Lewis 
On 15 Nov, Hans Petter Selasky wrote:

> The SCSI quirk is not needed. This should be fixed in the SCSI stack!

The SCSI quirk does seem to be needed, at least to make the umass device
readable.  With the UQ_MSC_NO_PREVENT_ALLOW quirk, I am able to mount
the umass device (before it goes way) and read its contents.  This quirk
is not implemented in 8.4-STABLE, and on my 8.4-STABLE machine I am not
able to read the umass device.  It looks like PREVENT REMOVAL causes the
device to become unreadable.

If I do a verbose boot on my 8.4-STABLE machine, I can see more of what
is going on when I plug in the device:

ugen1.2:  at usbus1
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:2:0:-1: Attached to scbus2
(probe0:umass-sim0:0:0:0): SCSI status error
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
pass1 at umass-sim0 bus 0 scbus2 target 0 lun 0
pass1:  Removable CD-ROM SCSI-2 device 
pass1: Serial Number 09116664373
pass1: 1.000MB/s transfers
GEOM: new disk cd1
(cd1:umass-sim0:0:0:0): SCSI status error
(cd1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 
(cd1:umass-sim0:0:0:0): CAM status: SCSI Status Error
(cd1:umass-sim0:0:0:0): SCSI status: Check Condition
(cd1:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(cd1:umass-sim0:0:0:0): Error 6, Unretryable error
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1:  Removable CD-ROM SCSI-2 device 
cd1: Serial Number 09116664373
cd1: 1.000MB/s transfers
cd1: Attempt to query device size failed: NOT READY, Medium not present
cd1: quirks=0x10<10_BYTE_ONLY>
(cd1:umass-sim0:0:0:0): SCSI status error
(cd1:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 
(cd1:umass-sim0:0:0:0): CAM status: SCSI Status Error
(cd1:umass-sim0:0:0:0): SCSI status: Check Condition
(cd1:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(cd1:umass-sim0:0:0:0): Error 6, Unretryable error
(cd1:umass-sim0:0:0:0): SCSI status error
(cd1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 
(cd1:umass-sim0:0:0:0): CAM status: SCSI Status Error
(cd1:umass-sim0:0:0:0): SCSI status: Check Condition
(cd1:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(cd1:umass-sim0:0:0:0): Error 6, Unretryable error
(cd1:umass-sim0:0:0:0): SCSI status error
(cd1:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 
(cd1:umass-sim0:0:0:0): CAM status: SCSI Status Error
(cd1:umass-sim0:0:0:0): SCSI status: Check Condition
(cd1:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(cd1:umass-sim0:0:0:0): Error 6, Unretryable error
(cd1:umass-sim0:0:0:0): SCSI status error
(cd1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 00 00 00 00 00 00 00 00 00 
(cd1:umass-sim0:0:0:0): CAM status: SCSI Status Error
(cd1:umass-sim0:0:0:0): SCSI status: Check Condition
(cd1:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(cd1:umass-sim0:0:0:0): Error 6, Unretryable error


I played around a bit with camcontrol debug on my 11.0-CURRENT box.
Unfortunately it isn't possible to turn on debug for a specific device
before it is plugged in, and if I enable debugging for all devices, I
have to be pretty selective about the debug flags to keep hard drive I/O
from being logged (which causes a feedback loop via syslog).

Here's 11.0-CURRENT without the quirk:

(noperiph:xpt0:0:-1:): debugging flags now 61
ugen2.2:  at usbus2
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:9:0: Attached to scbus9
(noperiph:umass-sim0:0:-1:): xpt_async(AC_PATH_REGISTERED)
(probe0:umass-sim0:0:0:0): Periph created
(probe0:umass-sim0:0:0:0): Probe started
(probe0:umass-sim0:0:0:0): Probe PROBE_INVALID to PROBE_INQUIRY
(probe0:umass-sim0:0:0:0): Probe PROBE_INQUIRY to PROBE_FULL_INQUIRY
(probe0:umass-sim0:0:0:0): Probe PROBE_FULL_INQUIRY to PROBE_SUPPORTED_VPD_LIST
(probe0:umass-sim0:0:0:0): Probe PROBE_SUPPORTED_VPD_LIST to PROBE_DEVICE_ID
(probe0:umass-sim0:0:0:0): Probe PROBE_DEVICE_ID to PROBE_SERIAL_NUM
(probe0:umass-sim0:0:0:0): Probe PROBE_SERIAL_NUM to PROBE_TUR_FOR_NEGOTIATION
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
(probe0:umass-sim0:0:0:0): Probe PROBE_TUR_FOR_NEGOTIATION to PROBE_DONE
(probe0:umass-sim0:0:0:0): Probe completed
(probe0:umass-sim0:0:0:0): Periph invalidated
(probe0:umass-sim0:0:0:0): Periph destroyed
(noperiph:umass-sim0:0:0:0): xpt_async(AC_FOUND_DEVICE)
(cd0:um

Re: U3GINIT_SCSIEJECT quirk

2013-11-15 Thread Don Lewis 
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?

I don't know how the device would know if it's being the first time
after a reboot, but anyway:

reboot

ugen2.2:  at usbus2, cfg=0 md=HOST 
spd=FULL (12Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x 
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1410 
  idProduct = 0x5020 
  bcdDevice = 0x 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0004  <09116664373>
  bNumConfigurations = 0x0001 

camcontrol eject

ugen2.2:  at usbus2, cfg=0 md=HOST 
spd=FULL (12Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x 
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1410 
  idProduct = 0x5020 
  bcdDevice = 0x 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0004  <09116664373>
  bNumConfigurations = 0x0001 

unplug, power off, replug

ugen2.2:  at usbus2, cfg=0 md=HOST 
spd=FULL (12Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x 
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1410 
  idProduct = 0x6000 
  bcdDevice = 0x 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0004  <091166643731000>
  bNumConfigurations = 0x0001 

Hmn, interesting ... idProduct is now 0x6000.   Even stranger is that it
worked with the quirk I added for 0x5020!!!

> U3G patch looks OK.
> 
> The SCSI quirk is not needed. This should be fixed in the SCSI stack!

I don't have any problems on my unpatched 8.4-STABLE laptop, but I do on
11-CURRENT.  It seems sort of odd that the device would be getting a
PREVENT/ALLOW MEDIUM REMOVAL command right after it is attached (maybe
from geom tasting it?), but without the UQ_MSC_NO_PREVENT_ALLOW quirk, I
get a bunch of SCSI read errors as mentioned here:
.
That seems to but CAM into a bad state that causes a use after free
issue the triggers a panic when the umass device goes away.  That seems
like a definite bug.  I suspect that it might be related to the recent
batch of CAM changes.  In any case, the quirk also seems to prevent the
panic.



___
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"

Re: U3GINIT_SCSIEJECT quirk

2013-11-14 Thread Hans Petter Selasky 

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.

The SCSI quirk is not needed. This should be fixed in the SCSI stack!

--HPS
___
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"

U3GINIT_SCSIEJECT quirk

2013-11-14 Thread Don Lewis 
I've got a Virgin Mobile version of the Novatel MiFi 2200.  I've added
the following quirks CAM from spewing a bunch of errors when it attaches
the umass (cd) device and then panicing about ten minutes later when the
umass device decides to disconnect.  I've also added the
U3GINIT_SCSIEJECT quirk in an attempt to get the umass device to eject
and bring up the u3g device.

Index: dev/usb/quirk/usb_quirk.c
===
--- dev/usb/quirk/usb_quirk.c   (revision 258079)
+++ dev/usb/quirk/usb_quirk.c   (working copy)
@@ -288,6 +288,7 @@
UQ_MSC_NO_INQUIRY),
USB_QUIRK(NIKON, D300, 0x, 0x, UQ_MSC_FORCE_WIRE_BBB,
UQ_MSC_FORCE_PROTO_SCSI),
+   USB_QUIRK(NOVATEL, MIFI2200V, 0x, 0x, UQ_MSC_NO_PREVENT_ALLOW),
USB_QUIRK(OLYMPUS, C1, 0x, 0x, UQ_MSC_FORCE_WIRE_BBB,
UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_WRONG_CSWSIG),
USB_QUIRK(OLYMPUS, C700, 0x, 0x, UQ_MSC_NO_GETMAXLUN),
Index: dev/usb/serial/u3g.c
===
--- dev/usb/serial/u3g.c(revision 258079)
+++ dev/usb/serial/u3g.c(working copy)
@@ -345,6 +345,7 @@
U3G_DEV(NOVATEL, MC547, 0),
U3G_DEV(NOVATEL, MC950D, 0),
U3G_DEV(NOVATEL, MIFI2200, U3GINIT_SCSIEJECT),
+   U3G_DEV(NOVATEL, MIFI2200V, U3GINIT_SCSIEJECT),
U3G_DEV(NOVATEL, U720, 0),
U3G_DEV(NOVATEL, U727, 0),
U3G_DEV(NOVATEL, U727_2, 0),
Index: dev/usb/usbdevs
===
--- dev/usb/usbdevs (revision 258079)
+++ dev/usb/usbdevs (working copy)
@@ -3174,6 +3174,7 @@
 product NOVATEL U727   0x4100  Merlin U727 CDMA
 product NOVATEL MC950D 0x4400  Novatel MC950D HSUPA
 product NOVATEL ZEROCD 0x5010  Novatel ZeroCD
+product NOVATEL MIFI2200V  0x5020  Novatel MiFi 2200 CDMA Virgin Mobile
 product NOVATEL ZEROCD20x5030  Novatel ZeroCD
 product NOVATEL MIFI2200   0x5041  Novatel MiFi 2200 CDMA
 product NOVATEL U727_2 0x5100  Merlin U727 CDMA


What is strange is that after rebooting the system, when I first plug in
the device, the eject doesn't seem to be happening.  I see the
following:

ugen2.2:  at usbus2
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:9:0: Attached to scbus9
cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0
cd0:  Removable CD-ROM SCSI-2 device 
cd0: Serial Number 09116664373
cd0: 1.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
cd0: quirks=0x10<10_BYTE_ONLY>
[run "camcontrol eject cd0" or wait about 10 minutes]
ugen2.2:  at usbus2 (disconnected)
umass0: at uhub0, port 1, addr 2 (disconnected)
cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0
cd0:  s/n 09116664373 detached
(cd0:umass-sim0:0:0:0): Periph destroyed
ugen2.2:  at usbus2
u3g0:  on usbus2
u3g0: Found 3 ports.
[unplug device]
ugen2.2:  at usbus2 (disconnected)
u3g0: at uhub0, port 1, addr 2 (disconnected)

If I then turn off the device and plug it back in, then the eject seems
to happen automatically like I would expect:

ugen2.2:  at usbus2
ugen2.2:  at usbus2 (disconnected)
ugen2.2:  at usbus2
u3g0:  on usbus2
u3g0: Found 3 ports.


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.

My second question is why does it work the second time the device is
plugged in, but not the first time after a reboot?

Is there a way to make it happen automatically the
first time the device is plugged in?

___
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"