From owner-freebsd-usb@freebsd.org Sun Feb 2 13:13:53 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F46C22E298 for ; Sun, 2 Feb 2020 13:13:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 489Wcc4BNBz47pg for ; Sun, 2 Feb 2020 13:13:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id l19so9305085qtq.8 for ; Sun, 02 Feb 2020 05:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MOBOACE8iTk2+OG7wzd37/V4iw5Jz6sqrRUnm9JrAI4=; b=Euw3LVX5LHWQsSYBS3/0GcUIhKJ/20jI58/GPdr/MTS/d9VC6QwcVepMCQkKfrE+aw 0oKFidJjRbY5X42UhrVdJ7/tIrMgiBEsHHM6yUefhIUsGugtHuaFKETW5blj4hfCJLB7 UtcWwL1s1oqvU8r0PWPDfloLpQYD8IyTY57eGIpJ9/FmeznmtuLH77rCio2Xdd1nb40i 3jD8fSDE68reSOLoPqBRqvYHTTKEx3RYukKm5O/ZSJH8+RrnJG/CQ7CRSip0A7N5BieB SoXqlIj0KMU3mT6snCu30TCOKL+RefFQizTjm8qkisaLsdjB5s7r6h+oLDgr4z+SyscC h31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MOBOACE8iTk2+OG7wzd37/V4iw5Jz6sqrRUnm9JrAI4=; b=kqY29w+v0YkwsS044+mjcifGBjWs9wP1eF53pDj2e4YdUED1DCVYVzzyJDfGPAW2Fr mmXagLcp9NuHWN9bdKLlIJnB0sIrs1UpsiDvQYNxGlghe8hFxwX4S+vnoSdRQC9oDx1V t7eAnta4kRJNyDfaMqrr8o1gl4T5PaeaxXc9g4QY8/PG2GVrTux5yzCVppC0hGAkfVHf cWGmViJW42l2L61vJruI/BnUgRKyJMpSMANN/XId5mPXcLFZYvjSDvTQ5MFK8dxMBJeY amA4bL/AsR0k8BuMquMJODS0+z4aXfJpMEkplBEu3RBx2gnbl0DkWSSlzWTIYjM9hbsc 8wXw== X-Gm-Message-State: APjAAAWVS9BIKP0sap/VHoy40FFzwrVBSeXbddSvb8RriXUrmDGPRQGW svsGCVY8344FN/Wl7dRsZR16StN2gqLF+wKhBbNJTU0VWgP9TA== X-Google-Smtp-Source: APXvYqwlNBfU3vAJ8ZyrTHc8DEpusP2JYVJXlLkl+c/RhGfnL7tYrGkCA7P3ukTsShVwKWbC9ZFRQSGVRdzjlf4L9zw= X-Received: by 2002:ac8:1e08:: with SMTP id n8mr19335738qtl.175.1580649231606; Sun, 02 Feb 2020 05:13:51 -0800 (PST) MIME-Version: 1.0 References: <98b6599e-5027-48c9-4230-47bc0f087180@comcast.net> <079c989a-5d45-df1f-ed48-15cdd8c8f194@comcast.net> In-Reply-To: <079c989a-5d45-df1f-ed48-15cdd8c8f194@comcast.net> From: Warner Losh Date: Sun, 2 Feb 2020 14:13:40 +0100 Message-ID: Subject: Re: Timeouts during initial Mode Sense commands To: denverh@comcast.net Cc: Hans Petter Selasky , "freebsd-usb@FreeBSD.org" X-Rspamd-Queue-Id: 489Wcc4BNBz47pg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Euw3LVX5; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::844) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.31 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.977,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-usb@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[comcast.net]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.34)[ip: (2.12), ipnet: 2607:f8b0::/32(-2.00), asn: 15169(-1.76), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 13:13:53 -0000 On Sun, Feb 2, 2020 at 12:32 PM Denver Hull 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: at usbus1 > >>>> umodem0 on uhub1 > >>>> umodem0: on usbus1 > >>>> umodem0: data interface 1, has no CM over data, has no break > >>>> umass3 on uhub1 > >>>> umass3: on usbus1 > >>>> umass3: SCSI over Bulk-Only; quirks = 0x0000 > >>>> umass3:5:3: Attached to scbus5 > >>>> uaudio0 on uhub1 > >>>> uaudio0: on usbus1 > >>>> uaudio0: No playback. > >>>> uaudio0: No recording. > >>>> uaudio0: MIDI sequencer. > >>>> uaudio0: No HID volume keys found. > >>>> ums2 on uhub1 > >>>> ums2: 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