Timeouts during initial Mode Sense commands
Denver Hull
denverh at comcast.net
Fri Dec 20 23:46:18 UTC 2019
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
>
>
I checked on a Linux system, and the negotiation follows a slightly
different pattern, but as far as I can see, the biggest difference is
that Linux uses 6 byte Mode Sense commands instead of 10 byte. I wonder
if that's all that's making the device choke? How hard would it be to
change things to use 0x1a instead of 0x5a temporarily? Alternatively, I
could see if I can figure out how to issue arbitrary SCSI commands on
Linux. I used to have something for that purpose that worked on a
variety of platforms, but it's been ages since I needed it. In any
case, I'll attach the Linux wireshark trace. The negotiation seems to
begin at frame 2331.
Thanks,
Denver
More information about the freebsd-usb
mailing list