Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1072323ybk; Wed, 20 May 2020 20:49:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQhcnbkHxN5mmdWUmCaTqHkXZm2HTExL2/6JH2fBE1msOuOJc7v+R67IWI5VGmDi78oTZX X-Received: by 2002:a17:906:2b4f:: with SMTP id b15mr1786228ejg.64.1590032965735; Wed, 20 May 2020 20:49:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590032965; cv=none; d=google.com; s=arc-20160816; b=iBMHvwNLVegMvXhhOLnYm8Nx1VjbtdIfk0agiGEM/7xAHEqPao/kyXALspTPvyZy4n rsBG2o4yTF9X0lIodE5HOHqk1mOzvkWmdLGjKcDVct9NSHtWllnzILA+6p7M14dRuOLm GrleDFrjPhIFr3zZFYhEsbHvib7hCdk6Yd3d96vtOXvo5IUalk9iN88KBEEIPjgF53w5 TVjIEHFIs5id930hHQp4i6xbL9Xoqr7En/N3cus8JokdDJvjZ/655FZeMxCoJvUvLxLf wVg/7XUwn4XmJJdIr/HZuaOLZaK6fqMjI9AfvF8bGcVsTaenJM0XtWbNEJ9QstJ86GG9 v9LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id; bh=+7kmtrItst0vUfBxkjGoeIDsxf6uXSRtxtHjzRwIKxg=; b=bwRwd2HlqomwsqtG3ZL9TR46wFII1of5+b8uFVT/vB4E83E6ePuX2XaY57CbvDMj1w SIbARO5iWf+VMlcDeSIGVIBZly4P/TDvZPHp0wFIzcm4VqRk9vTK7mDUs2cBlljrhQOP kv+hc8NKuoloSgu1f7nAGFHrwGULn/fxamWpeMYpCWNWc+qHSzjQDP6Ml789MVwoQxOk sBhGKJFPMfDDB9f4IOlobTsuh5VofPIXPTFMb5s001IPd5JELcaDb2taIJPR2S21bMJ9 C0ukxd4P0BJJFScaURWPg6PSrIbgUUV358+f1ZxY1c2XwK+u2wN4KsInLtDFbwmOw7ji 8Clw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si2781726edl.11.2020.05.20.20.49.02; Wed, 20 May 2020 20:49:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728181AbgEUDpX (ORCPT + 99 others); Wed, 20 May 2020 23:45:23 -0400 Received: from shelob.surriel.com ([96.67.55.147]:56678 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728054AbgEUDpW (ORCPT ); Wed, 20 May 2020 23:45:22 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jbc8w-0006nk-50; Wed, 20 May 2020 23:45:14 -0400 Message-ID: Subject: Re: XHCI vs PCM2903B/PCM2904 part 2 From: Rik van Riel To: Alan Stern Cc: linux-usb , alsa-devel@alsa-project.org, "linux-kernel@vger.kernel.org" , Mathias Nyman , Greg Kroah-Hartman , Jaroslav Kysela , Takashi Iwai Date: Wed, 20 May 2020 23:45:13 -0400 In-Reply-To: <20200520203417.GA23602@rowland.harvard.edu> References: <273cc1c074cc4a4058f31afe487fb233f5cf0351.camel@surriel.com> <20200520163840.GA11084@rowland.harvard.edu> <667d8d156fa5d8420ef1c3b1d08b94a10d2398cc.camel@surriel.com> <20200520203417.GA23602@rowland.harvard.edu> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-SzGJaqzGbl8x/tsVgjRx" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-SzGJaqzGbl8x/tsVgjRx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2020-05-20 at 16:34 -0400, Alan Stern wrote: > On Wed, May 20, 2020 at 03:21:44PM -0400, Rik van Riel wrote: > >=20 > > Interesting. That makes me really curious why things are > > getting stuck, now... >=20 > This could be a bug in xhci-hcd. Perhaps the controller's endpoint=20 > state needs to be updated after one of these errors occurs. Mathias=20 > will know all about that. I am seeing something potentially interesting in the giant trace. First the final enqueue/dequeue before the babble error: -0 [005] d.s. 776367.638233: xhci_inc_enq: ISOC 0000000033a6879e: enq 0x0000001014070420(0x0000001014070000) deq 0x0000001014070360(0x0000001014070000) segs 2 stream 0 free_trbs 497 bounce 196 cycle 1 The next reference to 0x0000001014070360 is the babble error, and some info on the ISOC buffer itself: -0 [005] d.h. 776367.639187: xhci_handle_event: EVENT: TRB 0000001014070360 status 'Babble Detected' len 196 slot 15 ep 9 type 'Transfer Event' flags e:C -0 [005] d.h. 776367.639195: xhci_handle_transfer: ISOC: Buffer 0000000e2676f400 length 196 TD size 0 intr 0 type 'Isoch' flags b:i:I:c:s:I:e:C Immediately after the babble error, the next request is enqueued, and the doorbell is rung: -0 [005] d.h. 776367.639196: xhci_inc_deq: ISOC 0000000= 033a6879e: enq 0x0000001014070420(0x0000001014070000) deq 0x000000101407037= 0(0x0000001014070000) segs 2 stream 0 free_trbs 498 bounce 196 cycle 1 -0 [005] d.h. 776367.639197: xhci_urb_giveback: ep4in-i= soc: urb 0000000072126553 pipe 135040 slot 15 length 196/196 sgs 0/0 stream= 0 flags 00000206 -0 [005] d.h. 776367.639197: xhci_inc_deq: EVENT 000000= 0097f84b16: enq 0x00000010170b5000(0x00000010170b5000) deq 0x00000010170b56= 70(0x00000010170b5000) segs 1 stream 0 free_trbs 254 bounce 0 cycle 1 -0 [005] ..s. 776367.639212: xhci_urb_enqueue: ep4in-is= oc: urb 0000000072126553 pipe 135040 slot 15 length 0/196 sgs 0/0 stream 0 = flags 00000206 -0 [005] d.s. 776367.639214: xhci_queue_trb: ISOC: Buff= er 0000000e2676f400 length 196 TD size 0 intr 0 type 'Isoch' flags b:i:I:c:= s:I:e:c -0 [005] d.s. 776367.639214: xhci_inc_enq: ISOC 0000000= 033a6879e: enq 0x0000001014070430(0x0000001014070000) deq 0x000000101407037= 0(0x0000001014070000) segs 2 stream 0 free_trbs 497 bounce 196 cycle 1 -0 [005] d.s. 776367.639215: xhci_ring_ep_doorbell: Rin= g doorbell for Slot 15 ep4in However, after that point, no more xhci_handle_transfer: ISOC lines ar seen in the log. The doorbell line above is the last line in the log for ep4in. Is this some area where USB3 and USB2 behave differently? dmesg:=20 https://drive.google.com/open?id=3D1S2Qc8lroqA5-RMukuLBLWFGx10vEjG-i usb trace, as requested by Mathias:=20 https://drive.google.com/open?id=3D1cbLcOnAtQRW0Chgak6PNC0l4yJv__4uO --=20 All Rights Reversed. --=-SzGJaqzGbl8x/tsVgjRx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl7F+UkACgkQznnekoTE 3oO+PAf+KRwyLSAqD1QWNerMZF5VpLDf1fe9DWc+r8YG2W1H5mx/vtB/k0tMt/vA skoIIv/i/UsjmcZJDxuEKk56fZSGoV8plHYzgSk13xoast8OcZAdaC3lXFWtFq1V x62IKORBC4pJmgtaITWLTsqgHNfrgOfKClnQJmxZPmSm6CHbD8cyONTjb7IAy9Mf 7EUE6oJBWLqtzELXHXIf3YKMWYu5sePAKziLd+Tow5cF2SCqSDQHrizk72xM5rBY QQmZNdQWTA83Gvbeh5I9oMLCMp0bChxi4+hx7IYc6A+jfyV51yTBsqU2q4FWbBpO kZ2fKMyazQtvULM3lj1nNoNP0s8Esg== =+/sv -----END PGP SIGNATURE----- --=-SzGJaqzGbl8x/tsVgjRx--