From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F38402C08BB for ; Fri, 21 Aug 2026 09:47:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787305636; cv=none; b=NFvdIwU4wGIPqB3iCKBYg3mj/j9b/WG0do7AqKpt1VYfiXBIQtcRXOxSILnoNeyYvjkpEEF6SmPRAb+BWrX5pjirwCvDYM7pptYBDPZRljKCNnVs/yNyfxNkaDXBKnGCPBg9vD2V4G4UhbWR1SkhjzBRu9khe+hcsQOv1n8p024= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787305636; c=relaxed/simple; bh=+i8zcfv9G7jMIdJJ3y0jvnysGQTVTauR7LX5aufUXuo=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=McIkw4zmDxPdUAFT5BgSrV9PzWGdgIzPZTSwpZO+svaP5mo3ZWMG0f2HA9Pv2DRkOyZH9q/0PpPO6/SeQ0Q4WT0UvOs8vB5nncdApRSzBg/Buh6KhLVtOqF0NxVkSnNgUSrZesqCQ+IPs/BDrM8+B8xyH42IqtdR9LT8jsgCejU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hHU043Ss; arc=none smtp.client-ip=209.85.218.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hHU043Ss" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c2020421077so137579566b.3 for ; Fri, 21 Aug 2026 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787305630; x=1787910430; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UOWTr+15MOM7A+CsDbkp55jjN+CwEJBKz9AocimZBr0=; b=hHU043Ss97llaKM0acRdsvhQ4f+EzkDYrQaNF3UW9oFC3ENm1gpWJ+qaoYmu+5HsQ2 BqTKVjEda34CGQh5f5NGEPUtnDDeydVQvu/dl/ju5kxwHBjIbgG9vzzoFsNhsPrtkC3c 5Y8Vb+i6Mz3jisjO3LEqC1HJQXwudVdtFiK4VRMhLkQlw6jk/m1/GwqhB1Lz8asJp44G fg32lVIhp2bAosjQYlXEjCfJ6ysjLJ+WJxX+Nqt29AUJzs4mvhxP0sCDEIPZK9Zw63u8 /kqOTvzpH+EWrixxEH9oODuzlih+7Ho+ymwNdbLEOaTStjrUwEgGKb8dzcHq8UWKrz8f GtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787305630; x=1787910430; h=content-transfer-encoding:content-type:mime-version:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=UOWTr+15MOM7A+CsDbkp55jjN+CwEJBKz9AocimZBr0=; b=aHrFwhI4p1A6Kaa67LAXQ6iuIuxjHAlmFhaI1e1rxzGrx6nFWr2mLNreDctZKKdUVe eYFepqy6AI2AgP3OpeOfYa41K4E771miRVwv3IBqbDBxZ5PF+1M9RqK+6DP3RNUoUUDo AIKIc5cEJdD30W2/Zn/A2xF16GTEs6f1m2Rl09Bz2lZi/VzgEr9C8qw83bhh/S1B44Mh J9pgljFnbQfvcYximvl6HK7lwkJYE6LoqUCY2PKVuNlHe1UGj8SldebUfaG4CCzNBmqo arJA34q27fId3Tg3GU9JvRMkCBMmj3fG7C7br7YOeSxROc2CDWX5/szJeoKRMSJ/bxmG 5CrA== X-Forwarded-Encrypted: i=1; AHgh+Rqe1T51wQcGVuz1jXyWqvGvfw36NFIm3pVP5FytwPVhXbZz4wF15AMLR4OvyYu5DwuS6Y4vjNDtVYPJl2w=@vger.kernel.org X-Gm-Message-State: AFuF++mJVW6MvCVxePYZ0CN6i2UBxvFEDz4rnWsp5aE+M1Eat3UnS2sX sAvLolapzDb1haJSqf6TA0zsL6Z0YqsGJrOelnyLlTaCUGQ0JplR+F0X X-Gm-Gg: AR+sD10xzKxas40QkBTxLOIHUFPbkFFRjqc3P0f3xG9E7YMKJACwEL+BiS4ctchCVI+ Sn81SGvb0JIQvadZjdwspIf+zbnPy5lJFYuyYcaJtoLiPIrmYoOOq82tIWzyGApSQbsKFo2cyWH QCb/34skNA8XiUS1Xg+d9z+dNvFEyhIIBqREQjX8cuaOZID9Kn8MNwcDeTq2MfpobPJOw8MZ+nq QmNs40axF3FkABgjwBoWOi4hA8bzIUHMqLd/UYeMdrquSx9Jn3Kee4aJAbXytU2yqEotjS81OIR VjJf9Hw1EHnzXMT99lYkGUMeA8I1Yc51k6eDeKp689XTFVN1Az9yyKbytoCIBc+ypIkUL7vZUIz aVye4eAoQDGXPYVPvkDCSUtVgcApZsLj5/WRmA1rS1ji8ZJsnOsvLZaLH9KFmRqMxPNIXvqPpTb fgG7LqWpyAoTiqHmkRz3R7SMwqmkhoFcn85z98tbcUf2raagAglp+kpwBS8YDOpHJMYixWxhmkZ /IZGw== X-Received: by 2002:a17:907:e1c9:20b0:c20:768:af62 with SMTP id a640c23a62f3a-c246b4bd167mr386763066b.22.1787305629809; Fri, 21 Aug 2026 02:47:09 -0700 (PDT) Received: from foxbook (bfg7.neoplus.adsl.tpnet.pl. [83.28.44.7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c245921e4f5sm398756466b.55.2026.08.21.02.47.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 21 Aug 2026 02:47:09 -0700 (PDT) Date: Fri, 21 Aug 2026 11:47:06 +0200 From: Michal Pecio To: Mathias Nyman , Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] usb: xhci: Fix isochronous scheduling regression Message-ID: <20260821114706.34b095b1.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit An isoc URB without URB_ISO_ASAP should be scheduled immediately after the previous one, unless it's the first submission or prior URBs have completed without resubmitting and the endpoint became idle. An HCD_BH driver must consider URBs pending completion in the BH queue in addition to its own queue. Regrettably, core doesn't provide much information, we can only know if we are being called by completion now. This issue is as old as HCD_BH, affects ehci-hcd too and has no known reproducible impact, as drivers generally resubmit from completion. A recent patch tried to address it by looking at xHCI HW state instead. Obviously, HW has no knowledge of the BH giveback queue either, and the whole solution amounts to testing whether prior URBs have been unlinked instead of completing normally - then a new stream is assumed. This leads to false negatives when a driver simply allows the endpoint to empty out and begins a new stream. New URBs are scheduled into the past and promptly fail with -EXDEV status, causing data loss and worse, because drivers get confused by premature completion, particularly when multiple endpoints are started at once and required to stay in sync. snd-usb-audio underruns the OUT endpoint when userspace fails to supply playback data in time. If this is detected in duplex mode, IN URBs are unlinked and both streams restarted. OUT underruns again before IN even begins, another recovery is attempted and the cycle repeats. Fix this by using the best criteria we can muster, taken from ehci-hcd. This brings false negative rate back to zero and false positive rate to less than ever before in xhci-hcd. Traditional logic was equivalent to: if (list_empty(&ep_ring->td_list) || GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING) // consider this URB a new stream While free of false negatives, it had easily avoidable false positives: * no check for completion in progress when the list is empty * the ep_ctx check doesn't make up for it at all, but it adds a race - EP state can remain "stopped" for a while after the first submission Link: https://lore.kernel.org/linux-usb/20260813005635.34750f8c.michal.pecio@gmail.com/ Fixes: add8469b3e00 ("xhci: fix frame id calculation and checks for isoc URBs") Signed-off-by: Michal Pecio --- drivers/usb/host/xhci-ring.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f27bc132d0e9..8b0c27d6f12d 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -4311,10 +4311,11 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags, check_interval(urb, ep_ctx); /* - * Check if this starts the isoc data flow. Relies on hw setting ep ctx - * state after doorbell ring. Consider adding list_empty(td_list) check + * Schedule the URB discontiguously if all previous URBs have completed. + * XXX core can't tell if completions are pending but not running yet. */ - if (GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING) + if (list_empty(&ep_ring->td_list) && + !hcd_periodic_completion_in_progress(xhci_to_hcd(xhci), urb->ep)) xep->next_uframe = -1; return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index); -- 2.48.1