Timeouts during initial Mode Sense commands

[Hans Petter Selasky]

On 2019-12-19 01:11, Denver Hull wrote:
> Hello,
> 
> I have several different microcontroller boards that are supposed to 
> appear as storage devices when plugged in.  They work fine on Linux 
> systems, but on FreeBSD 11.3 and 12.1 they don't show up at all. Here's 
> what dmesg shows for one of them:
> 
> ugen1.3: <Adafruit Industries LLC PyPortal> at usbus1
> umodem0 on uhub1
> umodem0: <CircuitPython CDC control> on usbus1
> umodem0: data interface 1, has no CM over data, has no break
> umass3 on uhub1
> umass3: <CircuitPython Mass Storage> on usbus1
> umass3:  SCSI over Bulk-Only; quirks = 0x0000
> umass3:5:3: Attached to scbus5
> uaudio0 on uhub1
> uaudio0: <CircuitPython Audio> on usbus1
> uaudio0: No playback.
> uaudio0: No recording.
> uaudio0: MIDI sequencer.
> uaudio0: No HID volume keys found.
> ums2 on uhub1
> ums2: <CircuitPython HID> on usbus1
> ums2: 16 buttons and [XYZ] coordinates ID=2
> (da3:umass-sim3:3:0:0): got CAM status 0x44
> (da3:umass-sim3:3:0:0): fatal error, failed to attach to device
> g_access(944): provider da3 has error 6 set
> g_access(944): provider da3 has error 6 set
> g_access(944): provider da3 has error 6 set
> g_access(944): provider da3 has error 6 set
> g_access(944): provider da3 has error 6 set
> 
> There's a definite delay after the last ums message.  I used camcontrol 
> debug in single user mode on a bare 12.1 system to get a little more 
> information about what was happening.  It looks like the initial Inquiry 
> and Test Unit Ready commands succeed, but the next Mode Sense command 
> times out, as well as all subsequent commands. There are several seconds 
> of inactivity between retries, and there's no sense data, so I'm 
> assuming that indicates timeout.
> 
> At this point I'm not sure how best to proceed to get these devices to 
> work, so any help will be appreciated.
> 

Did you try setting one or more quirks for these devices using usbconfig?

UQ_MSC_NO_TEST_UNIT_READY
UQ_MSC_NO_RS_CLEAR_UA
UQ_MSC_NO_START_STOP
UQ_MSC_NO_GETMAXLUN
UQ_MSC_NO_INQUIRY
UQ_MSC_NO_INQUIRY_EVPD
UQ_MSC_NO_PREVENT_ALLOW
UQ_MSC_NO_SYNC_CACHE
UQ_MSC_SHUTTLE_INIT
UQ_MSC_ALT_IFACE_1
UQ_MSC_FLOPPY_SPEED
UQ_MSC_IGNORE_RESIDUE
UQ_MSC_WRONG_CSWSIG
UQ_MSC_RBC_PAD_TO_12
UQ_MSC_READ_CAP_OFFBY1
UQ_MSC_FORCE_SHORT_INQ

If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might see the last 
failing SCSI command. X.Y are numbers after ugen for your device.

Likely your device has a software bug in its USB/SCSI implementation, 
which is quite common unfortunately.

--HPS