From owner-freebsd-usb@freebsd.org Fri Dec 20 23:46:18 2019 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 939011E6D56 for ; Fri, 20 Dec 2019 23:46:18 +0000 (UTC) (envelope-from denverh@comcast.net) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47flkc5Kf6z4ZM7 for ; Fri, 20 Dec 2019 23:46:16 +0000 (UTC) (envelope-from denverh@comcast.net) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with ESMTP id iRXSiUsde6kCOiRyHiF97d; Fri, 20 Dec 2019 23:46:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1576885573; bh=dxwvrDBCsdLOnmLugFn9WDfKibsQp4S/VtxqudTzXIU=; h=Received:Received:Reply-To:Subject:To:From:Message-ID:Date: MIME-Version:Content-Type; b=s99OY01CjepkcqjlENhv/AnnEbUrT2jA1iEIgozJ5claQqGDQAJjtYSncZ1m7Bio0 K5WSS6Xw0vdJEKUTnQfENcpzVHLosy4+T5sDIYobIjAwYyKU3Mjcb7LeM27FTkR3sn zuoy5ME2C7qc8y8utrXiKwSt/IF1HEhUlzby2cybEooz3k6wvy17MoeXhHLAVARQQL cXscbe3cdFDIF8n/9KGPMjo7ZOVNd9bfgfopLh2ybHqTT/qoQDG5E+V9V8A7iWikO1 GU8i/5+3jb76G89k2qC3PhGX0k04xEgAoP/5+4/pLEeRwsA9OJHtFK4+OJyJqGzkyt N9gXIBadQ4gvw== Received: from dhbsd.dhull.home ([104.129.31.27]) by resomta-po-06v.sys.comcast.net with ESMTPA id iRy6iGEhcEbhMiRy7iw2T2; Fri, 20 Dec 2019 23:46:11 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedufedrvddugedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhkffffgggjggtsehmtderredtfeejnecuhfhrohhmpeffvghnvhgvrhcujfhulhhluceouggvnhhvvghrhhestghomhgtrghsthdrnhgvtheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecukfhppedutdegrdduvdelrdefuddrvdejnecurfgrrhgrmhephhgvlhhopeguhhgsshgurdguhhhulhhlrdhhohhmvgdpihhnvghtpedutdegrdduvdelrdefuddrvdejpdhmrghilhhfrhhomhepuggvnhhvvghrhhestghomhgtrghsthdrnhgvthdprhgtphhtthhopehfrhgvvggsshguqdhushgssehfrhgvvggsshgurdhorhhgpdhrtghpthhtohephhhpshesshgvlhgrshhkhidrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=0.00;st=legit Reply-To: denverh@comcast.net Subject: Re: Timeouts during initial Mode Sense commands To: Hans Petter Selasky , freebsd-usb@freebsd.org References: <98b6599e-5027-48c9-4230-47bc0f087180@comcast.net> From: Denver Hull Message-ID: <079c989a-5d45-df1f-ed48-15cdd8c8f194@comcast.net> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: X-Rspamd-Queue-Id: 47flkc5Kf6z4ZM7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=s99OY01C; dmarc=pass (policy=none) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of denverh@comcast.net designates 2001:558:fe16:19:96:114:154:162 as permitted sender) smtp.mailfrom=denverh@comcast.net X-Spamd-Result: default: False [-0.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[denverh@comcast.net]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fe16:19:96:114:154:160/123]; FREEMAIL_FROM(0.00)[comcast.net]; HAS_ATTACHMENT(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[comcast.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,none]; HFILTER_HELO_5(3.00)[resqmta-po-03v.sys.comcast.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2.6.1.0.4.5.1.0.4.1.1.0.6.9.0.0.9.1.0.0.6.1.e.f.8.5.5.0.1.0.0.2.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[comcast.net.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[comcast.net]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; FREEMAIL_REPLYTO(0.00)[comcast.net]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ipnet: 2001:558::/29(-0.39), asn: 7922(-0.46), country: US(-0.05)] X-Mailman-Approved-At: Sun, 02 Feb 2020 11:32:50 +0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , Date: Fri, 20 Dec 2019 23:46:18 -0000 X-Original-Date: Fri, 20 Dec 2019 17:46:01 -0600 X-List-Received-Date: Fri, 20 Dec 2019 23:46:18 -0000 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. Thanks, Denver