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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.