From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: FPS <mista.tapas@gmx.net>, "Michał Pecio" <michal.pecio@gmail.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: Misbehaving Alder Lake-N PCH USB 3.2 xHCI Host Controller
Date: Tue, 27 Aug 2024 15:38:17 +0300 [thread overview]
Message-ID: <ca65e086-b5eb-424b-9757-7df581cd8fb4@linux.intel.com> (raw)
In-Reply-To: <2b81ac60-32f5-4b71-98de-d336b7282cfb@gmx.net>
On 23.8.2024 14.43, FPS wrote:
> On Wed, Aug 21, 2024 at 05:15:00PM +0300, Mathias Nyman wrote:
> > My best guess is that these are caused by a full xhci event ring.
> >
> > If event ring is full it would stop transfer rings, and we would see
> > missed service events. This matches the logs.
> >
> > The events get handled and cleared in the interrupt handler, but
> > not every event generates an interrupt. for isoc transfers we
> intentionally
> > block a lot of event triggered interrupts.
>
> This has piqued my interest. Can you point me to the code in the kernel
> source where this filtering happens?
When a transfer completes the xHC hw will add an event on the event ring pointing
to this completed transfer block (TRB), and trigger an interrupt.
We can prevent xHC from generating the interrupt by setting a BEI (Block Event Interrupt)
flag in the Transfer Block (TRB)
To make sure every event triggers an interrupt just comment out:
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 4ea2c3e072a9..de61a1018155 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -4108,8 +4108,8 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
td->last_trb = ep_ring->enqueue;
td->last_trb_seg = ep_ring->enq_seg;
field |= TRB_IOC;
- if (trb_block_event_intr(xhci, num_tds, i, ir))
- field |= TRB_BEI;
+// if (trb_block_event_intr(xhci, num_tds, i, ir))
+// field |= TRB_BEI;
But I don't think this is the issue after looking at the traces.
Thanks
Mathias
next prev parent reply other threads:[~2024-08-27 12:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-18 20:56 Misbehaving Alder Lake-N PCH USB 3.2 xHCI Host Controller FPS
2024-08-19 13:38 ` Mathias Nyman
2024-08-19 20:12 ` FPS
2024-08-20 11:01 ` Michał Pecio
2024-08-20 21:04 ` FPS
2024-08-21 13:02 ` Michał Pecio
2024-08-21 13:46 ` fps
2024-08-21 14:15 ` Mathias Nyman
2024-08-21 16:49 ` Michał Pecio
2024-08-23 11:43 ` FPS
2024-08-24 21:22 ` FPS
2024-08-25 4:58 ` Michał Pecio
2024-08-25 7:46 ` fps
2024-08-25 15:15 ` Michał Pecio
2024-08-25 20:38 ` FPS
2024-08-27 10:30 ` FPS
2024-08-27 11:31 ` Mathias Nyman
2024-08-27 12:18 ` FPS
2024-08-27 13:49 ` Mathias Nyman
2024-08-27 12:37 ` Mathias Nyman
2024-08-28 9:15 ` FPS
2024-08-27 12:38 ` Mathias Nyman [this message]
2024-08-27 20:49 ` FPS
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=ca65e086-b5eb-424b-9757-7df581cd8fb4@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=michal.pecio@gmail.com \
--cc=mista.tapas@gmx.net \
/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;
as well as URLs for NNTP newsgroup(s).