Hello,
Thanks, this patch solves the issue, as one would expect.
However I'm under the impression that the underlying problem is only in
the Event TRBs that arrive after the Event TRB of COMP_SHORT_PACKET
type. In other words, the quirky behavior is only when the xHC flushes
the Data TRBs that are left after the short packet has arrived, and
sends faulty Event TRBs on their behalf.
So maybe ignore any Event TRB on behalf of a TD for which a
COMP_SHORT_PACKET has been received? I mean, what information could it
possibly contain?
This would also have solved the "Event TRB with no TDs queued" issue,
just in a more generalized manner.
Regards,
Eli
On 12/11/19 11:36, Mathias Nyman wrote:
On 12.11.2019 6.25, Eli Billauer wrote:
Hello,
Connecting a custom designed (on FPGA) USB 3.0 device to a Renesas
uPD720202 (1912:0015) and kernel v5.3.0, I get a lot of messages in
the kernel log, while transmitting data at a high bandwidth through a
BULK IN endpoint:
handle_tx_event: 36590 callbacks suppressed
xhci_hcd 0000:03:00.0: WARN Successful completion on short TX for
slot 1 ep 18: needs XHCI_TRUST_TX_LENGTH quirk?
(last message repeated several times)
The driver in charge, as reported by lspci, is xhci_hcd.
Probably relevant details:
* The buffer size of the USB transactions is 32 kiB and up (with
libusb). With e.g. 16 kiB buffers these log messages don't appear.
* The device produces short packets occasionally. When only
full-length packets are sent, these log messages don't appear.
* Other than these log messages, everything works fine. In
particular, there are no errors in the data exchange in either
situation.
* This problem doesn't happen when running the same test on an Intel
B150 chipset’s USB 3.0 xHCI controller (8086:a12f).
I don't really know what this warning means, but this whole thing
kind-of reminds the "WARN Event TRB for slot x ep y with no TDs
queued" issue that was solved recently. Just a wild guess.
It just means that we got an event from the xHC host saying the
transfer was
completed with completion code "Success" even if we didn't get as many
bytes as was requested.
Driver is expecting a completion code of Short Packet.
Any idea how this can be fixed?
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1e0236e90687..687182afc59b 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -228,6 +228,7 @@ static void xhci_pci_quirks(struct device *dev,
struct xhci_hcd *xhci)
}
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
pdev->device == 0x0015) {
+ xhci->quirks |= XHCI_TRUST_TX_LENGTH;
xhci->quirks |= XHCI_RESET_ON_RESUME;
xhci->quirks |= XHCI_ZERO_64B_REGS;
}
You could give it a try and see if everything works normally.
But this quirk is now quite common.
Could make sense to get rid of it completely and just handle this case
as default driver behavior.
-Mathias
