Date: Thu, 20 Feb 2020 17:48:41 -0600 From: Denver Hull <denverh@comcast.net> To: Warner Losh <imp@bsdimp.com> 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: <e9f80b34-34f7-a476-8a6b-7142fbbf913e@comcast.net> In-Reply-To: <CANCZdfpCKvRQx4-h61zEVeSUV3fu2n1hoCiM=VySgGCqEgQiJA@mail.gmail.com> 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> <CANCZdfpCKvRQx4-h61zEVeSUV3fu2n1hoCiM=VySgGCqEgQiJA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
>
> On Sun, Feb 2, 2020 at 12:32 PM Denver Hull <denverh@comcast.net
> <mailto: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
>
Sorry about the long delay. This sounded promising and I had high hopes
for it, but it didn't help. The difficulty begins before the da device
is created. It looks like once the initial 10 byte Mode Sense is issued
the device becomes unresponsive and everything goes downhill from
there. That's clearly a problem with the device, but I'm pretty sure
that on Linux it recovers if I send it a 10 byte Mode Sense. When I get
a chance I'll see if I can capture what Linux is doing to recover from that.
I've started looking at the boot code for these boards, which appears to
be derived from Atmel's SAM-BA. Two of the boards I have work fine, but
they have a very old version of the bootloader. I updated all the other
boards with the latest version, but that didn't change anything. At
this point I'm still setting up something to be able to build that code.
Thanks,
Denver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e9f80b34-34f7-a476-8a6b-7142fbbf913e>