From: "Michał Pecio" <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [RTF PATCH v3] xhci: process isoc TD properly when there was an error mid TD.
Date: Mon, 22 Jan 2024 10:03:32 +0100 [thread overview]
Message-ID: <20240122100332.6341ef1d@foxbook> (raw)
In-Reply-To: <20240119225432.78c2d35d@foxbook>
> Apparently a babble error, and it seems to have generated a "success"
> which the event handler tried to match with the next TD. So a mid TD
> babble may need the same treatment, which is not surprising.
This is now confirmed and fixed here. The change is obvious enough:
case COMP_ISOCH_BUFFER_OVERRUN:
case COMP_BABBLE_DETECTED_ERROR:
+ error_mid_td = true;
frame->status = -EOVERFLOW;
break;
I don't know yet what COMP_ISOCH_BUFFER_OVERRUN means, but I guess it's
the same story. BTW, error_mid_td is a local variable now and I use the
urb_length_set flag instead, as explained before.
I found that it can be reproduced on the VIA host, with enough tries it
can happen even on a chained TD. NEC doesn't signal these babble errors
but new mid TD event handling should cope with either host.
Debug trace ("interesting" is other than "success" or "short packet"):
[ 4113.376349] xhci_hcd 0000:03:00.0: handle_tx_event interesting ep_trb_dma 132961000 comp_code 3 slot 2 ep 2
[ 4113.376361] xhci_hcd 0000:03:00.0: handle_tx_event first_trb 132961000 last_trb 132961010
[ 4113.376364] xhci_hcd 0000:03:00.0: Error mid isoc TD, wait for final completion event
[ 4113.376366] xhci_hcd 0000:03:00.0: handle_tx_event uninteresting ep_trb_dma 132961010 comp_code 1 slot 2 ep 2
[ 4113.376369] xhci_hcd 0000:03:00.0: handle_tx_event first_trb 132961000 last_trb 132961010
[ 4113.376371] xhci_hcd 0000:03:00.0: Got SUCCESS after mid TD error
[ 4113.376373] xhci_hcd 0000:03:00.0: finish_td comp_code 1 status -75
Thanks,
Michal
next prev parent reply other threads:[~2024-01-22 9:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 22:52 "Transfer event TRB DMA ptr not part of current TD" spam after USB disconnection Michał Pecio
2024-01-13 20:47 ` Michał Pecio
2024-01-14 14:06 ` Michał Pecio
2024-01-15 13:58 ` Mathias Nyman
2024-01-15 16:27 ` Michał Pecio
2024-01-16 15:36 ` [RFT PATCH] xhci: process isoc TD properly when there was an error mid TD Mathias Nyman
2024-01-16 22:20 ` Michał Pecio
2024-01-17 10:46 ` Mathias Nyman
2024-01-17 17:49 ` Michał Pecio
2024-01-18 11:00 ` Isochronous error handling bug on VIA VL805 Michał Pecio
2024-01-18 11:10 ` Michał Pecio
2024-01-18 13:54 ` Mathias Nyman
2024-01-18 13:56 ` [RFT PATCH v2] xhci: process isoc TD properly when there was an error mid TD Mathias Nyman
2024-01-18 22:16 ` Michał Pecio
2024-01-19 10:49 ` Mathias Nyman
2024-01-19 10:58 ` [RTF PATCH v3] " Mathias Nyman
2024-01-19 21:54 ` Michał Pecio
2024-01-22 9:03 ` Michał Pecio [this message]
2024-01-22 13:37 ` Mathias Nyman
2024-01-22 17:10 ` Michał Pecio
2024-01-22 11:47 ` Mathias Nyman
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=20240122100332.6341ef1d@foxbook \
--to=michal.pecio@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.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