From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 465E33563CD for ; Sun, 23 Aug 2026 17:05:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787504732; cv=none; b=AuV9914LyuD5O5fJKOTuvElZmGnhUilU6ssQYeIPNjrrlHfLxOogVSKhV1YUzaQ+fms6mVv8SU6xck9E2/Em5P7iD7Xm63eh/jn0iuM6oSi8DjWKjl81e26kOQE9X6k+9oAnKgELKEFIvLWGXTX/6amU2Pb5nls8p8QMySRVIXg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787504732; c=relaxed/simple; bh=tZ3kOiXAkP3ZajzR9DGtBNJIg33EF2ByFAZEw7fsQVU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DT1iPqkJGVEw6Iz5sPD4ihyGeVqNas/yqzbS7C+x3B1VlvF8KcpRLk3yBilPu6JqfdkZSaiWIRH3tPa3yAHgzjBRpoOSXz2qTSTMoyOMTxh7aUU32MerFKguRFhF0+qWQWDRbNbEbNO7RmVBl2JTklDJiCaS71p1aUUfriylXfA= 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=IMBzUQdt; arc=none smtp.client-ip=209.85.214.172 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="IMBzUQdt" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2caced6038eso27150125ad.0 for ; Sun, 23 Aug 2026 10:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787504729; x=1788109529; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=pYrUZlO7IqIkRYhROYYB/AOAuFYaRX4X5UCYzj5mFMc=; b=IMBzUQdtLJ+6V/GO1zZOcwtv+iGs3xmZT8AZUqYbjDExUonMHcjuWfklNcJecR2BCg Jd1KnLrhRjGmE+PslLtYNI9i/yra8VGUFzc31aF2fSJjqm1Jj+Si3ZK8EGf5PNuPFfWM MGsw2hRPyLol20NDBQXIN8SvBl//QMbW0eoBmB+DuuS91oQk9iqgQ/o6ys3D2a+6NMUz 1lqtYjVpW17z5oWqM+F+EIS1ofXj1n6fPH4HnZcha8MApRnVavJ9G7YroDQfL1Q3WD/G Xfs+Wo1E4fE3vaZsQ/ng3CLyqZeSDuiqHyTBSZ1aeJrZNvIpGZPHcz46V6jT8i71BXUH e1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787504729; x=1788109529; h=in-reply-to:content-disposition:content-type:mime-version :references: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=pYrUZlO7IqIkRYhROYYB/AOAuFYaRX4X5UCYzj5mFMc=; b=c4mE5HpKUCzcj0UdpfI5YK7snxSItPjgPWy9CFP2pS2ouQ1JJehUTaCljNJ55GrG3v Zi4hH+In6R8QiWqhjd8rTkhy5Axk5YhJHjhLFSVAliR+N6CrH0ONCh6hi50g0BFCDX0A h0uVQ69S68vIhi8iqPO080xUyvPLMaMQeORq+oYLlaWqlFqev3BfD1BroJL+fmv3IPau bouJ3mIeKM0Gzb4cMOgeTOcATsqT+Tx9s2b/cmcn6XQ3pFF5Q3MJusDEsljSZvdHQ7Eq zKRvXkx/jiXRfhSoJ0a20Zfdpi3kRsL9oiMotjic5sTei4btsCpCnQLjFapim0chkdJw uRdQ== X-Forwarded-Encrypted: i=1; AHgh+RoNavPeJbKAq9Py7cyoQ5mn5T+gYg2plk8S8OKzjj9EiwZW3qEBe05NyYdhh71lK5JEvAi5byh7pK12pps=@vger.kernel.org X-Gm-Message-State: AFuF++kEsUlFuUXbayAjaJFFqE7lvXgT3a2uiNBq9QGTMLvBMp3Yrya8 gOjUGRrD73xSZ8tnvaSUmMIsV6U4idLO1LMid9V3nLNXrl1W/HEn6H42 X-Gm-Gg: AR+sD13zA3LWv6tWa4gNUooIAFpC/hjQfXV/C9ocAlyFmkMBR+OLVVxDldQE8D66MUV P3QcFdYweQQ5gSwigmc7tZLjKWF3L0TkL06Qh0dyau2czeCec4CxyBrPJsX5Ad1YXcfP+gWRdDC RHcJQ27fVHHnQv7QfBjp+CvOEkTZvrElsO1H0ijsSu/HK1mljoSwcGs1KLl8IRhajvtM0R8In6F 2jMGVWPt1QCwdfSf7NBNUsoiDuOFHtj17SqBPkmenh6VbWpfVCsmu1v6C++AyNs3Uh55/WNAF4s LiXRrTk0EnIWD91Rcz/vWeHHVwN7I1iww+ynAfU3xXBD4znJ7GnQ5KX8vexqvHtwDQV/RMYYl2b QZZ9esMzv2mda5wW1zhP6gYFDZh49BzsNtu8+mE2QsanOgBFF6m4U1oAqEku+++sWYNhNGy80nT 9ghATMc5jjTZGI7qWVzYdHOxaVlUqRyJnA8aK9lSJlM7CN73176CSV5N+kpD8Hcn/ylVkYixicW 8F0lEVSaw4fBrbN22IpFuO4/4jL X-Received: by 2002:a17:903:b45:b0:2ce:a6a4:451b with SMTP id d9443c01a7336-2d61a183641mr202719365ad.11.1787504729357; Sun, 23 Aug 2026 10:05:29 -0700 (PDT) Received: from localhost ([2409:40c4:35d:a0d7:1d3:cd30:d9bc:b5a9]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-327f91d36f9sm26172029eec.16.2026.08.23.10.05.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 10:05:28 -0700 (PDT) Date: Sun, 23 Aug 2026 22:35:24 +0530 From: Lovekesh Solanki To: Michal Pecio Cc: Thorsten Leemhuis , Mathias Nyman , linux-usb@vger.kernel.org, regressions@lists.linux.dev, stable@vger.kernel.org, linux-kernel@vger.kernel.org, Mario Limonciello , Forest , Slavik Dev , Mathieu Fluhr Subject: Re: [REGRESSION] 6.12.36+: usb: hub: post-resume delayed work triggers > uncorrected MCE / data fabric sync flood on Threadripper 7970X > (bisected to aec11e5f9c45) Message-ID: References: <07435e6b-ee30-4c85-8c8b-0ce3a4ead1d9@leemhuis.info> <20260823174059.46fec036.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-Disposition: inline In-Reply-To: <20260823174059.46fec036.michal.pecio@gmail.com> On Sun, Aug 23, 2026 at 05:40:59PM +0200, Michal Pecio wrote: > But I'm not sure what you mean by "1Hz stress loop" and why is slowing > down the suspend/resume cycles or moving suspend from close() call into > a work supposed to create problems? > > I would naively think that doing things *too fast* is more likely to > trigger races and break the HW. The whole issue smells like a HW bug, USB2 roothubs still do 30 ms cycles and are harmless, only stretched SS ones kill the box. So if speed were the issue the faster ones would be dying first and pre regression kernels ran fine. About 1Hz, adb scans the bus once a second, every open resumes the root hub and host controller out of D3 and close puts it back this existed before regression too but with 30 ms of close() and slept for rest of the second and now it keeps it in D0 well after close(), the suspend itself happening later from the delayed work, so this d3 - d0 - d3 trip of ~230ms repeats on each scan. That's the loop I meant. > Can it not become a problem for external hubs, under other workloads? Possibly yes, but nobody reported that so I'd rather scope where the harm is proven. > Also, what if we connect a downstream SS hub to the root hub? Will this > not cause the root hub to stay awake for 200ms again? Problem is back? The root hub itself skips the hold since the check is on its own parent, but it will be kept awake anyway while the downstream hub or devices are in use which is normal activity based PM. If heavy polling behind a real hub ever causes trouble that's probably a xhci/platform level fix anyways since real hubs can't really just drop the hold. Regards, Lovekesh