From: Rik van Riel <riel@surriel.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb <linux-usb@vger.kernel.org>,
alsa-devel@alsa-project.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>
Subject: Re: XHCI vs PCM2903B/PCM2904 part 2
Date: Wed, 20 May 2020 23:45:13 -0400 [thread overview]
Message-ID: <d75c3a3cda51149a054838652243de2b8ac20854.camel@surriel.com> (raw)
In-Reply-To: <20200520203417.GA23602@rowland.harvard.edu>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
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:
> >
> > Interesting. That makes me really curious why things are
> > getting stuck, now...
>
> This could be a bug in xhci-hcd. Perhaps the controller's endpoint
> state needs to be updated after one of these errors occurs. Mathias
> will know all about that.
I am seeing something potentially interesting in the
giant trace. First the final enqueue/dequeue before
the babble error:
<idle>-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:
<idle>-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
<idle>-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:
<idle>-0 [005] d.h. 776367.639196: xhci_inc_deq: ISOC 0000000033a6879e: enq 0x0000001014070420(0x0000001014070000) deq 0x0000001014070370(0x0000001014070000) segs 2 stream 0 free_trbs 498 bounce 196 cycle 1
<idle>-0 [005] d.h. 776367.639197: xhci_urb_giveback: ep4in-isoc: urb 0000000072126553 pipe 135040 slot 15 length 196/196 sgs 0/0 stream 0 flags 00000206
<idle>-0 [005] d.h. 776367.639197: xhci_inc_deq: EVENT 0000000097f84b16: enq 0x00000010170b5000(0x00000010170b5000) deq 0x00000010170b5670(0x00000010170b5000) segs 1 stream 0 free_trbs 254 bounce 0 cycle 1
<idle>-0 [005] ..s. 776367.639212: xhci_urb_enqueue: ep4in-isoc: urb 0000000072126553 pipe 135040 slot 15 length 0/196 sgs 0/0 stream 0 flags 00000206
<idle>-0 [005] d.s. 776367.639214: xhci_queue_trb: ISOC: Buffer 0000000e2676f400 length 196 TD size 0 intr 0 type 'Isoch' flags b:i:I:c:s:I:e:c
<idle>-0 [005] d.s. 776367.639214: xhci_inc_enq: ISOC 0000000033a6879e: enq 0x0000001014070430(0x0000001014070000) deq 0x0000001014070370(0x0000001014070000) segs 2 stream 0 free_trbs 497 bounce 196 cycle 1
<idle>-0 [005] d.s. 776367.639215: xhci_ring_ep_doorbell: Ring 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:
https://drive.google.com/open?id=1S2Qc8lroqA5-RMukuLBLWFGx10vEjG-i
usb trace, as requested by Mathias:
https://drive.google.com/open?id=1cbLcOnAtQRW0Chgak6PNC0l4yJv__4uO
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-05-21 3:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 11:26 Rik van Riel
2020-05-20 11:41 ` Takashi Iwai
2020-05-20 13:50 ` Mathias Nyman
2020-05-20 19:53 ` Rik van Riel
2020-05-20 16:38 ` Alan Stern
2020-05-20 19:21 ` Rik van Riel
2020-05-20 20:34 ` Alan Stern
2020-05-21 3:45 ` Rik van Riel [this message]
2020-05-25 9:37 ` Mathias Nyman
2020-06-30 3:21 ` Rik van Riel
2020-06-30 3:55 ` Rik van Riel
[not found] ` <90D456E4-328F-49F7-99C4-D729E38FA04E@surriel.com>
2020-06-30 14:27 ` Mathias Nyman
2020-06-30 18:52 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d75c3a3cda51149a054838652243de2b8ac20854.camel@surriel.com \
--to=riel@surriel.com \
--cc=alsa-devel@alsa-project.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=perex@perex.cz \
--cc=stern@rowland.harvard.edu \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®