From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E94932192E0 for ; Tue, 11 Nov 2025 06:51:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762843890; cv=none; b=LfRnL+5hS6cTbw9f0ygVlV7SMLqYIF3+uHpSSZ6+GayIwu+U8m0Hucx7JaaKbLhoMlWVCnVkcUC85QBv3uXzUyVoSR+3qtwbWIpyHph5WXURoNPfweRsgpNUQEGkYj5gD3sBiBI28VGuNiGUWlt2xzc2Y7tPeYzn0/lV4lOYGNM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762843890; c=relaxed/simple; bh=DErlls/0jBulJQGwlawMmjE7HKgq5cfvhi20S+9iayo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jGJfGEj2pbJS2GEyJpAz7gT/6kvodiEoLL5dVmr/B/XIAHC67GdN3kx8glYOtTfEzz21/5Z7YXibiHIk9Fsf4vWPEKgmHHm44p3U6yYbgytpYLxza/kZ8qH7lw+f/Sy6P8uo3AaAVPd05c3pbmrdRT9ftREDTOws04DzCmszAbE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=uI8/Mzpq; arc=none smtp.client-ip=95.215.58.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="uI8/Mzpq" Message-ID: <36f05566-8c7a-485b-96e7-9792ab355374@packett.cool> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1762843876; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=smhud6T4SqC4w36gRlyhLwg16tK5nMSudVt7tZE829s=; b=uI8/Mzpq9VCfvnfBdweD6Xzbo4CduDY6TixZiIKkPHALYiUZuKTVy7E4EOmNgqZ/JzjBRN 2bsBIzHdNMhKZPPeQcVgEvz+XWC8mWleRX3e1OmOc301gPPkC4VOBwW+iaXF5y5CwbsiIU 29xEXNssEZT/HA4zGr6dU5pdPpsF/kLFi5sl0x4kRomirNLaRW1JUI/iFHeOqB8ZUArUCf kEhAYvuPVeSZZWz+wsGwOAVGOWISlU2KkE9TrpYrQ0pkODkLbfKuK2KOIvvo2ycpLSOSQo UKFtPZfHa23wiFMd0hA1s9qjNivOX/K8wXRp8Fs3CWeKv4cYW0oys54BQePW6g== Date: Tue, 11 Nov 2025 03:51:03 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 0/2] PCI/ASPM: Enable ASPM and Clock PM by default on devicetree platforms To: Dmitry Baryshkov , manivannan.sadhasivam@oss.qualcomm.com, Rob Clark , Vignesh Raman , Valentine Burley Cc: Bjorn Helgaas , Manivannan Sadhasivam , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Rob Herring , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, "David E. Box" , Kai-Heng Feng , "Rafael J. Wysocki" , Heiner Kallweit , Chia-Lin Kao , Bjorn Helgaas References: <20250922-pci-dt-aspm-v2-0-2a65cf84e326@oss.qualcomm.com> <4cp5pzmlkkht2ni7us6p3edidnk25l45xrp6w3fxguqcvhq2id@wjqqrdpkypkf> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: <4cp5pzmlkkht2ni7us6p3edidnk25l45xrp6w3fxguqcvhq2id@wjqqrdpkypkf> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 11/8/25 1:18 PM, Dmitry Baryshkov wrote: > On Mon, Sep 22, 2025 at 09:46:43PM +0530, Manivannan Sadhasivam via B4 Relay wrote: >> Hi, >> >> This series is one of the 'let's bite the bullet' kind, where we have decided to >> enable all ASPM and Clock PM states by default on devicetree platforms [1]. The >> reason why devicetree platforms were chosen because, it will be of minimal >> impact compared to the ACPI platforms. So seemed ideal to test the waters. >> >> This series is tested on Lenovo Thinkpad T14s based on Snapdragon X1 SoC. All >> supported ASPM states are getting enabled for both the NVMe and WLAN devices by >> default. >> [..] > The series breaks the DRM CI on DB820C board (apq8096, PCIe network > card, NFS root). The board resets randomly after some time ([1]). Is that reset.. due to the watchdog resetting a hard-frozen system? Me and a bunch of other people in the #aarch64-laptops irc/matrix room have been experiencing these random hard freezes with ASPM enabled for the NVMe SSD, on Hamoa (and Purwa too I think) devices. Totally unpredictable, could be after 4 minutes or 4 days of uptime. Panic-indicator LED not blinking, no reaction to magic SysRq, display image frozen, just a complete hang until the watchdog does the reset. I have confirmed with a modified (to accept args) enable-aspm.sh script[1] that disabling ASPM *only* for the SSD, while keeping it *on* for the WiFi adapter, is enough to keep the system stable (got to about a month of uptime in that state). If you have reproduced the same issue on an entirely different SoC, it's probably a general driver issue. Please, please help us debug this using your internal secret debug equipment :) [1]: https://gist.github.com/valpackett/8a6207b44364de6b32652f4041fe680f Thanks, ~val