Date: Sun, 2 Feb 2020 14:13:40 +0100 From: Warner Losh <imp@bsdimp.com> To: denverh@comcast.net Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: Timeouts during initial Mode Sense commands Message-ID: <CANCZdfpCKvRQx4-h61zEVeSUV3fu2n1hoCiM=VySgGCqEgQiJA@mail.gmail.com> In-Reply-To: <079c989a-5d45-df1f-ed48-15cdd8c8f194@comcast.net> 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> <079c989a-5d45-df1f-ed48-15cdd8c8f194@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 2, 2020 at 12:32 PM Denver Hull <denverh@comcast.net> wrote:
> 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.
>
There's a DA_Q_NO_6_BYTE quirk, but that does rather the opposite of what I
think is needed here.
and we use it here:
* RBC devices don't have to support READ(6), only READ(10).
*/
if (softc->quirks & DA_Q_NO_6_BYTE || SID_TYPE(&cgd->inq_data) ==
T_RBC)
softc->minimum_cmd_size = 10;
else
softc->minimum_cmd_size = 6;
but there's a way to override:
* Load the user's default, if any.
*/
snprintf(tmpstr, sizeof(tmpstr), "kern.cam.da.%d.minimum_cmd_size",
periph->unit_number);
TUNABLE_INT_FETCH(tmpstr, &softc->minimum_cmd_size);
so you could try setting the tunable kern.cam.da.X.minimum_cmd_size="6" in
/boot/loader.conf (where X is the drive the system assigns) and see if that
changes the wireshark output to be closer to Linux or not...
I'm unsure if we have a direct way to ask if it's RBC or not...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpCKvRQx4-h61zEVeSUV3fu2n1hoCiM=VySgGCqEgQiJA>