Date: Fri, 20 Dec 2019 14:23:40 +0100 From: Hans Petter Selasky <hps@selasky.org> To: denverh@comcast.net, freebsd-usb@freebsd.org Subject: Re: Timeouts during initial Mode Sense commands Message-ID: <b8915704-fb28-662f-197c-923bd632f35e@selasky.org> In-Reply-To: <98b6599e-5027-48c9-4230-47bc0f087180@comcast.net> References: <d842e49b-8f40-f5af-b8c3-3e23349be7ab@comcast.net> <be235eb1-d78f-0fb7-a3b9-23e82f9096a1@selasky.org> <98b6599e-5027-48c9-4230-47bc0f087180@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b8915704-fb28-662f-197c-923bd632f35e>