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