From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 29132386576 for ; Mon, 1 Jun 2026 07:38:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780299510; cv=none; b=t3QVEHgarcU1E8g5eHEgOkUT9KTHqxfJ/rDZ3aRX56F9gc/El204XdyUWZLfH2Az5886YwvuPucWZzVxdb3fSnr0O6JJl70TyjK7F95LjX8eo+ApyvOIDgBL301nxO8Fv2eDV6Ox/IJbfGonMtQqkqXf5NrFhihX5juHL3kbWHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780299510; c=relaxed/simple; bh=HQtzW+AzPTHtktemBwgJ1/AqdLD9KikDHuB6vjDahhE=; h=MIME-Version:From:To:Cc:Subject:Message-ID:Date:Content-Type; b=P+dk2e7/wUr2RPmXSizUCkMSzWN8DEmeNPEK971qhCFoRgsCmSj6aFj1ZS4BzUxSUwzWsbBaoa7g/z21fm2/1EMZeHqEkGzBlkLu+yhvJ67uHVjZ6IzMgSzFExaW1sDjBzCrnNxpEKx13GD+LdK/MdrVpl2GTMvFj0dWwyxSN3k= 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=tC4NdUGg; arc=none smtp.client-ip=209.85.214.177 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="tC4NdUGg" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2bf125989f2so23856825ad.3 for ; Mon, 01 Jun 2026 00:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780299508; x=1780904308; darn=vger.kernel.org; h=content-transfer-encoding:date:message-id:subject:cc:to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Li7NM+/Fc50bd4rV+8seyueGkphlIKWlChj7iNY/Qss=; b=tC4NdUGgN1r8l/jTCwambRe1lYG0KaKVrgIg4sqX5prwmN4wdvISm10mfNXLRGihz0 9XM2+ilICi59opwXEpasePihheWYyGiXb5hRexjp5Il0BJHCNvCcvjLxAyF8TBjP28We rUmXDbJfnxsVp0Bphe+0HOqT4wzkBRlLYuxSvsFkbiTrFRNOgF4tR9svKaIPXxWOf6xF 8o6UTtbeQ/mhG+1TnxnAVtZY6NgqZn4lJ7FLiIvFl3gu+WF7Bf03yJS34CdiP+CU4BQZ U0P2agrOlfx96s5BhizSF/B+FMSmfDZVinhLKXCuMrhZLdaxo2B7otegX3jBMVQX9k7B qZkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780299508; x=1780904308; h=content-transfer-encoding:date:message-id:subject:cc:to:from :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Li7NM+/Fc50bd4rV+8seyueGkphlIKWlChj7iNY/Qss=; b=F/qHzV1BjA++MFi1cI2If2UBh28MhxF4rCyBT6JCu25AY+cc8rOsoT8zvlGaBn/RwU GdbAmKagiuN2YCWOC4F5bnXRT1Ysi7sTiIVlEbxpHibo7jG2KnndGKqcxLdelsavJZkT cSwdEJB9RYdU6CCUwKSMeOcJBAalVweo75JthxWfEJ6rg2LvVaBMacExedV78awMTfu5 cU61Dq0o2oWD29rK4ldCmX3TCFuw1luwMSXw12KFSSRjkKUfaL9CkxF9qfR1KNevithD 7+lSLl5jR3Fga3dx2CF3wibDZdJZbBnrnrTjNmRWodds1wT0EST00Sm03cS1yZ9vNzlg kf8g== X-Forwarded-Encrypted: i=1; AFNElJ//NbBFRlGNSc3dVymXgNZ6PB8hX3rTdjrgOAAG9EI82x9N6YX466yWU+BpTBhrVfWCenZU1uWzZ7dVcio=@vger.kernel.org X-Gm-Message-State: AOJu0YxbZ4oYda2+kmGxqiuB6dzNQmWGHhX4DOwLSNX+7e1K09YYKi2q jhNrmai+eXmJ2RBPye2INVv9osDf5at7R9/HOnOJYqqGYxinVQk9R9sO X-Gm-Gg: Acq92OGUKLey0T7vsVI54YQXCZfeieNVYaljtTSQsFPnZW8gpNXs/j+gZyd6Ckwksi/ nHDK8x30RUGbSWFhEhsCL30MF/qmG/mgQ8F8F8g83F5m+J9tx8zq0TWb9O9mHdGDqCHeDTQay3z 25yP5d1g69TfAdBQxPZGRhrms4n2ZqgwiYxZDycR7zhlf5vUisKqcWH6xbs83e5Hp05FePQzc6U UikGukJnNEJdhfKa12SFyObglKGAklBktdx+Z8irJlhTjwEZY/tPO0afQ0o3VYhqqe+01m1FTxT 4Hqq4TuF5KZs1G1oroaMizXWpraxqyO98obX+Zzv+MYeJb/wpBebWiwTQKKlpoJZjAnXAZE34SM 7QFVimOjmszWlRzBNS1vxWfTEzDuYBwzMJUTexHm1HCzbBjZL4SYYE62tQIoDoqPFM4UW7tvhaE AL4H1NkKUngOnIelurqhxPQBl/fR5GYnJZkV/LTIPrVRAODmY= X-Received: by 2002:a17:903:2441:b0:2bf:7b62:a038 with SMTP id d9443c01a7336-2bf7b62a302mr102041225ad.9.1780299508211; Mon, 01 Jun 2026 00:38:28 -0700 (PDT) Received: from GordonMsi ([240e:39e:4b6:6d00:7d23:c974:a73d:af3c]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bf23a21f0bsm90285415ad.34.2026.06.01.00.38.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2026 00:38:27 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "Gordon Chen" To: "Mario Limonciello" , "Shyam Sundar S K" , "Mathias Nyman" Cc: , , , Subject: USB-audio isochronous Missed Service Errors on AMD Zen5 client (Fire Range) -- Data Fabric idle C-state? No OS-level knob found Message-ID: <18b4e4f7089aa4f1.da8dbe994ae3bb77.445e21b98b0b205b@GordonMsi> Date: Mon, 1 Jun 2026 07:38:22 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Mario, Shyam, Mathias, I'm reporting what looks like an interaction between AMD client SoC idle power management (Data Fabric / SOCCLK) and low-latency isochronous USB DMA, on a Ryzen 9 9955HX3D (Fire Range, Zen5) laptop. It reproduces on any AMD Zen4/5 client I or others have tried, with any USB audio interface; there is an open community bug with several different-vendor devices [1]. I have a strong differential pointing below the OS, but no way to read DF C-state residency on this platform to confirm -- hence this mail. Questions are at the end. Symptom ------- USB audio playback has frequent audible clicks, and after ~10-30 min of continuous playback an occasional full stall. Each click maps 1:1 (time- aligned) to a short isochronous OUT URB; at the packet level these are iso_frame_desc[i].status = -EXDEV (COMP_MISSED_SERVICE_ERROR) -- the xHCI controller missed servicing a 125 us microframe. urb->error_count stays 0 and nothing reaches dmesg; you have to look at per-packet status or count short OUT URBs. The stall is the same fault at its extreme: on an implicit- feedback device, a whole errored capture URB starves the OUT ring until re-plug. What I tried (all ineffective except the last) ---------------------------------------------- cpu_dma_latency = 0 (PM QoS, verified locked) no change cpuidle: all C-states disabled no change cpufreq governor = performance no change amdgpu power_dpm_force_performance_level = high no change stress-ng --cpu 16 (pure compute, little mem traffic) no change stress-ng --stream (sustained memory bandwidth) misses -> 0 So CPU residency/frequency is not the lever; sustained memory-controller traffic is. Reading SoC clock DPM (amdgpu pp_dpm_socclk / pp_dpm_mclk): idle and under --cpu it sits at socclk 400 MHz / mclk 1600 MHz; under --stream it jumps to socclk 1200 / mclk 2800. This points away from clock frequency as the lever: a single --stream worker already pins socclk=1200 / mclk=2800, yet the misses persist; it takes several workers of continuous traffic before they drop to zero. So what tracks the fix is not the clock the SoC reaches, but the amount of sustained memory-controller traffic. My working hypothesis is that the Data Fabric idles into a low-power state between the sparse isochronous transactions, and that the wake/traversal latency on the next microframe can then exceed the 125 us deadline -- with only traffic dense enough to keep the fabric out of that state avoiding it. I cannot confirm that from the OS (I have no way to read DF C-state residency here), so I would welcome a sanity check on the mechanism; the measurements above are what I am confident of. I could not reach this from the OS: profile_peak / force=high do not raise socclk (ignored for an otherwise-idle iGPU), and a manual pp_dpm_socclk / pp_dpm_mclk write is rejected with -EINVAL. The BIOS on this laptop exposes no "DF C-States" / "Power Supply Idle Control" option. Reproducer ---------- Any AMD Zen4/5 client + any USB audio interface, playing continuously: # count short OUT URBs (= missed-service events); nominal is the device's # full OUT packet size (768 bytes for the Flow 8 at 48 kHz / 4 ch) bpftrace -e 'kprobe:snd_complete_urb { $u = (struct urb *)arg0; if ((($u->pipe >> 7) & 1) == 0 && $u->actual_length < 768) { @miss++; } }' # while watching: cat /sys/class/drm/cardN/device/pp_dpm_socclk # baseline: misses > 0, socclk pinned at 400 MHz # with stress-ng --stream 4 running: misses 0, socclk 1200 MHz Questions --------- 1. Is this a known interaction between DF idle power state (DF C-states / SOCCLK gating) and latency-sensitive isochronous DMA on client SoCs -- an erratum or documented behaviour? 2. Is there a supported way to hold the Data Fabric out of its deep idle state (or set a fabric-active floor) while a latency-sensitive iso USB endpoint is streaming -- a kernel interface (amd_pmc / amd_node?), or a firmware/PMFW setting -- short of burning memory bandwidth? 3. If not, what telemetry would help characterize this (amd_pmc STB dump? specific SMN / DF P-state or C-state registers? a debugfs)? I'm happy to build an instrumented kernel and test patches. Related: the extreme stall case (whole-URB error on the implicitly-fed OUT ring) is separately handled in snd-usb-audio by a Flow 8 quirk that emits silence instead of hanging (commit a23812004228). That only papers over the hang and does nothing about the clicks, which are the subject here. System: Ryzen 9 9955HX3D (Fire Range, Zen5, 16C/32T), AMD xHCI, iGPU smu_v13_0_0 (0x13c0); kernel 7.0.10 (CachyOS, close to mainline for usb / xhci / amd power-management). Thanks, Gordon Chen [1] https://github.com/CachyOS/linux-cachyos/issues/665