From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (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 BB4E94CA274 for ; Fri, 21 Aug 2026 14:46:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787323622; cv=none; b=Uq5Gjd6hlb38yVWfepNuL8a9KghVbvDxTF9gweBOlw+XcVSfnR4KwxRuMowbLncMQ9yi/CDLt88ObEWu41iNZrRU9KZpt/1VifngmmRubC2M+DhChcDKJIPtA87nOVQe9C4g2qk13+LUB29gdypFHgPfIcCoGjrkkLyowj+ljV4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787323622; c=relaxed/simple; bh=GZyHcculU0gOJlIxF7dSpQxZvPDAWhhb+BKxeeo1dYg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=vFAUfMohpaid10iBwHs18ZL5VwvZZ/Nglwzs2SlqCCAkOGcBm14WfsxLTlDRSkKfmU+5LyGk97bHRV5qma43l48YQaxiGakZea56ePHHnqZgWHLvH60plMrdmZpHUnGgFUtp825csO+idUUTchLLId50XJTyT0jzwwcoaH1np5w= 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=b6kHvkEc; arc=none smtp.client-ip=209.85.208.43 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="b6kHvkEc" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-6a20319d030so1852067a12.2 for ; Fri, 21 Aug 2026 07:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787323611; x=1787928411; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=UkCD9ip6gAVSYyBIpgV04TliVlZ8DLGdKefhjITe5Cs=; b=b6kHvkEcu3dGi+qjWIYBsyB+29AyWZ/9olX77Af3gtC2UgOsp4MUfdfaFQ9gR+2Mod WPGPMPGf+mCkhhsQU5FKinOJFvRd2ZY2t4+9Uj5htzZHD8TItBbmeTC7CstcTgv0qagj Qb0meCjxdsyWaRahWYvmfbq88aCKC63tB70sIcBj7ETltOAD4KqyF3cP0vfQMFDCjntN 4xLUMrxmlpzaeenhkyh0eJq36o1S0F3h3hnpzyIpTALFJyX2ZVnSApQcxjzFxk4IvvBD cytoe9VwfP3mZErXTmTXTNWarKPcTqVt0/xobJTZd72g8KDyffDwaCCeajSX1kzgsGpp M0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787323611; x=1787928411; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to: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=UkCD9ip6gAVSYyBIpgV04TliVlZ8DLGdKefhjITe5Cs=; b=BzORYCw/r/UcQ+ZIieFT+ksN8Og0R1W5700zfmjpYvIJIaGNCTsQTdI0dz5O/Fc4Lx taTHmnJwuuEPnMoB3xirbaJRfAM+bvp4yyM/Soir+V39RV6XBqjxGG/BFMAU9b3k1BYR KxAABpJoikhlZCIfqPhd1f1YOuV/3q/ugXhY/626WC338IkOcHFDILYiL+yErwWvggzi zwse4I6x4PNRVM2O6NBjCz6vZwf23CoUV1b5m3AG6IUQVXUais/6aKpY6uAz2CgNYq4F ddtExuGumC9tal6mplnNgIn32brK9J9XtgtPrfG5osUmqD+XfB2zMrNO/lNtX2zn4UcD 769A== X-Forwarded-Encrypted: i=1; AHgh+Rpu9ghRPk5bgM/kR8UDjbXKRsVEmq2So8z+6d5kTkbO+fZnbyIDmLvYyepu1OYWhtzMPLDmzFsAxI/uWoA=@vger.kernel.org X-Gm-Message-State: AFuF++mpyDQrSnB+7U2eISQFlqwDTggiC+lKIeDgH8gFhswJywLsXn83 ZU4erIOMTK3jnBOsYWgZDCxdWANGO9eHetDCqnQ/XV+Thgs2u8nEFKmT X-Gm-Gg: AR+sD13t+BYyBLUKwbr1zVFUDZu8dnoIh2KXasRnSpJcq3dbr5I9kC1GNWN1Xse2yHe 0SeJM037KW9loVCvnASCVRtQ7gRQOWP8646YSUWP40vMT5YMNI81xFWez1xlPYFWDBwuRKMU+ju t9RFMVzxW1d00LJdvfPAZgdgwLIFghRzhaJhDoc8TDUnqgctzqI4Lw7H668SFa3I81zes8OfuWX TRh5kgzs5MOw6FCUVmu/bkuoCZ3+OdZvORVinUY/gc1/5LaDPzSnjYyWsk6RxGFhd8DUFSrP/2H tYaA75h2qSUt/XhQdapDojad1wj+I2BFHjwO9hPbAlNshaplJZsckdxbcvj+B3rGrAIdqIWkSrx 427JJXp6SNM8EQSS9wWDaRnnRQ4oA/anvDquwCButmJeG0U/NO2cbngg+ys1n6EMeQRw9BiBnmP mT0lxq4Guri9etjGkWc65u3zfjQ5wunN8AR4XF+DNFa3NcS//FUdT7wyJurst+miRk+nA= X-Received: by 2002:a17:907:1b09:b0:c24:670b:7750 with SMTP id a640c23a62f3a-c246a60ca8cmr632531266b.14.1787323611301; Fri, 21 Aug 2026 07:46:51 -0700 (PDT) Received: from foxbook (bfg7.neoplus.adsl.tpnet.pl. [83.28.44.7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c245931812esm582462866b.60.2026.08.21.07.46.50 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 21 Aug 2026 07:46:51 -0700 (PDT) Date: Fri, 21 Aug 2026 16:46:45 +0200 From: Michal Pecio To: Mathias Nyman Cc: Mathias Nyman , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: xhci: Fix isochronous scheduling regression Message-ID: <20260821164645.047c9020.michal.pecio@gmail.com> In-Reply-To: <6804ed57-8405-4310-a64f-20c400bffde0@linux.intel.com> References: <20260821114706.34b095b1.michal.pecio@gmail.com> <6804ed57-8405-4310-a64f-20c400bffde0@linux.intel.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 On Fri, 21 Aug 2026 15:05:53 +0300, Mathias Nyman wrote: > On 8/21/26 12:47, Michal Pecio wrote: > > 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 > > I would still prefer: > if (list_empty(&ep_ring->td_list) && GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING) > to detect the start of a new isoch stream. > > It has zero false positives mid stream, and fixes the "stopped" state > race case. > > I can't figure out when the false negatives it introduces is an issue. > > If you can show me a usecase where a driver or specification is > designed to let an isoch endpoint intentionally run dry, leaving it > in running/idle, and then continue queuing URBs expecting ASAP > scheduling, then we can change it. Well, snd-usb-audio does. In snd_complete_urb(), in the usb_pipeout(ep->pipe) case and ep->lowlatency_playback, which is the default (controlled by 'lowlatency' module parameter). It adds the completed URB to a queue of "ready" URBs and then tries to submit as many URBs from that queue as possible, which may be zero if there is no data to send. Then pending URB count is checked for zero, which triggers xrun recovery in ALSA core. I haven't dug into ALSA, but the observable outcome is: snd_usb_endpoint_stop() is called on both IN and OUT, which unlinks IN URBs and does nothing to OUT (zero URBs left). snd_usb_endpoint_start() is called on both endpoints to submit URBs. See dynamic debug below. Notably, "Setting usb interface" does appear, but only at the end, when I killed jackd. And it seems suboptimal to demand that drivers spend time on control requests in such cases. [146029.539992] xhci_hcd 0000:06:00.0: Stopped on Transfer TRB for slot 1 ep 2 [146029.540031] xhci_hcd 0000:06:00.0: Underrun event on slot 1 ep 1 [146029.542857] usb 6-2: Starting data EP 0x81 (running 0) [146029.542949] usb 6-2: 12 URBs submitted for EP 0x81 [146029.542958] usb 6-2: 2:2 Start Capture PCM [146029.542962] usb 6-2: Starting data EP 0x1 (running 0) [146029.542991] usb 6-2: 2 URBs submitted for EP 0x1 [146029.542996] usb 6-2: 1:3 Start Playback PCM [146029.543799] usb 6-2: notify_xrun ep 01 from line 579 <-- my patch [146029.543816] usb 6-2: Stopping data EP 0x81 (running 1) [146029.543861] usb 6-2: 2:2 Stop Capture PCM [146029.543863] usb 6-2: Stopping data EP 0x1 (running 1) [146029.543865] usb 6-2: 1:3 Stop Playback PCM [146029.543882] xhci_hcd 0000:06:00.0: Stopped on Transfer TRB for slot 1 ep 2 [146029.543886] xhci_hcd 0000:06:00.0: Underrun event on slot 1 ep 1 [146029.545849] usb 6-2: Starting data EP 0x81 (running 0) [146029.545962] usb 6-2: 12 URBs submitted for EP 0x81 [146029.545969] usb 6-2: 2:2 Start Capture PCM [146029.545972] usb 6-2: Starting data EP 0x1 (running 0) [146029.545998] usb 6-2: 2 URBs submitted for EP 0x1 [146029.546001] usb 6-2: 1:3 Start Playback PCM [146029.546793] usb 6-2: notify_xrun ep 01 from line 579 [146029.546814] usb 6-2: Stopping data EP 0x81 (running 1) [146029.546876] usb 6-2: 2:2 Stop Capture PCM [146029.546881] usb 6-2: Stopping data EP 0x1 (running 1) [146029.546885] usb 6-2: 1:3 Stop Playback PCM [146029.546903] xhci_hcd 0000:06:00.0: Underrun event on slot 1 ep 1 [146029.546909] xhci_hcd 0000:06:00.0: Stopped on Transfer TRB for slot 1 ep 2 [146029.557837] usb 6-2: Closing EP 0x81 (count 1) [146029.557845] usb 6-2: Setting usb interface 2:0 for EP 0x81 [146029.558636] usb 6-2: EP 0x81 closed [146029.558664] usb 6-2: Closing EP 0x1 (count 1) [146029.558666] usb 6-2: Setting usb interface 1:0 for EP 0x1 [146029.559505] usb 6-2: EP 0x1 closed 0000:06:00.0 is ASM1042, USB 3.0, no CFC. Hence no Missed Service before the Underrun. OUT URBs seem to complete successfully, but ALSA apparently doesn't feed playback data until the IN endpoint starts moving, which is scheduled to happen later, so OUT underruns again and the whole mess repeats. On CFC, all OUT URBs complete 1 uframe after submisison with MSE, so it's pretty much guaranteed to happen before any IN is scheduled. Up to v7.2, such xrun is only a brief audible glitch. On usb-next it loops like that for seconds to minutes before recovering by some lucky miracle (IDK why that happens, but sometimes it panics and begins unlinking OUT URBs before the last one completes). Hence the idea to not rock the boat too much and stay with zero false negatives and only the unavoidable false postives which have been here in HCD_BH drivers for ages. The whole thing is madness. It nobody has issues with wasting 4 bytes per endpoint, I think it could be fixed by counting all pending URBs from submit to complete. Changes to ehci/xhci-hcd will be minimal. Or add a flag which overrides this guesswork. But too late for v7.3. > At least we should add a debug message so audio/video developers can > find the reason for the glitches: > > if (list_empty(&ep_ring->td_list) && > !hcd_periodic_completion_in_progress(xhci_to_hcd(xhci), urb->ep)) { > if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING) > xhci_dbg(xhci, "Starting new isoc stream on running endpoint at uframe %d, killing sync.. > xep->next_uframe = -1; > } That seems harmless, although the same information can be obtained by checking urb->start_frame after submission. Fun fact, I found only two in-tree drivers which do anything meaningful with it. Particularly, if snd-usb-audio submits IN and OUT across frame boundary, it can only recover by xruning and trying again, meh. Regards, Michal