Timeouts during initial Mode Sense commands

[Hans Petter Selasky]

On 2019-12-20 13:54, Denver Hull wrote:
> Hans Petter Selasky wrote:
>> 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
>>
> After I sent the previous message I did try UQ_MSC_NO_TEST_UNIT_READY. 
> Although the system reports "quirks = 0001", the initial TUR is still 
> being issued during the probe sequence.  I tried the usbdump command you 
> suggested, and I can clearly see where the timeouts are, and frames that 
> begin with "USBC" seem to contain a SCSI CDB.  But there's a lot of 
> other stuff in between that I haven't been able to figure out, so I've 
> attached a sample.  Hopefully it will help.
> 

Hi,

All the USBC's are raw SCSI commands, which use the following layout:

> /* Command Block Wrapper */
> typedef struct {
>         uDWord  dCBWSignature;
> #define CBWSIGNATURE    0x43425355
>         uDWord  dCBWTag;
>         uDWord  dCBWDataTransferLength;
>         uByte   bCBWFlags;
> #define CBWFLAGS_OUT    0x00
> #define CBWFLAGS_IN     0x80
>         uByte   bCBWLUN;
>         uByte   bCDBLength;
> #define CBWCDBLENGTH    16
>         uByte   CBWCDB[CBWCDBLENGTH];
> } __packed umass_bbb_cbw_t;

We had a SoC to add support for the usbdump format to wireshark:

https://wiki.freebsd.org/SummerOfCode2017/usbdump-wireshark

You might find that useful.

My first suspicion is that your device is not fully USB class compliant, 
and that's why it is STALLING and failing to recover.

--HPS