Timeouts during initial Mode Sense commands

[Denver Hull]

Hans Petter Selasky wrote:
> 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
>
>
Wireshark: I was wondering if that might not work.  I'll look into it, 
thanks.

I saw that stall, but with everything else that's going on in there, I 
couldn't tell if it was significant or not.  I'll see if I can find out 
how Linux is negotiating with this device and post the results.  I don't 
know if that will help or not, but it's worth trying.

Thanks,

Denver