From: Val Packett <val@packett.cool>
To: Manivannan Sadhasivam <mani@kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Alexey Bogoslavsky <Alexey.Bogoslavsky@sandisk.com>,
Jeffrey Lien <Jeff.Lien@sandisk.com>,
Avinash M N <Avinash.M.N@sandisk.com>
Subject: Re: [PATCH v2] PCI: Add quirk to disable ASPM L1 for Sandisk SN740 NVMe SSDs
Date: Mon, 1 Dec 2025 03:48:13 -0300 [thread overview]
Message-ID: <9a9280e7-d29a-475a-83fa-671acfab9d92@packett.cool> (raw)
In-Reply-To: <tiadpmogdxom5h2bquct2ch6hoc6ozh6bgnzdmnj3mia22vtue@c5yjxbx65lsm>
On 11/25/25 2:21 AM, Manivannan Sadhasivam wrote:
> [..]
> There are a couple of points that made me convince myself:
>
> * Other X1E laptops are working fine with ASPM L1.
> * This laptop has WCN785x WiFi/BT combo card connected to the other controller
> instance and L1 is working fine for it.
> * There is no known issue with ASPM L1 in X1E chipsets.
>
> Because of these, I was so certain that the NVMe is the fault here.
There is *a* known issue with ASPM L1 on X1E, reported by maaaany users
on #aarch64-laptops, that we discussed in another thread..
But it is a full system freeze, **not** a correctable AER message, and
it definitely happens with a bunch of various SSDs on various laptops. I
personally have had it happen both with the SN740 and an SK Hynix drive,
on a Latitude 7455. It's an SSD-only issue (disabling ASPM just for the
drive, but keeping it on for the WiFi, was enough to get to month-long
uptime) but not specific to any SSD model.
One bit of news I have about it is that I recently started using EL2
(slbounce), and I did see something that looked like that hang.. but
unlike in EL1, right before the reboot the panic LED did start blinking.
So if that was indeed from the same issue, I should now be able to catch
it into pstore (if pstore works.. trying blk with sdhc instead of efi
now 0.o) Maybe QHEE was eating the fault and itself crashing, since it
"owns" the PCIe IOMMU when it's running.. (???)
~val
next prev parent reply other threads:[~2025-12-01 6:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 16:12 Manivannan Sadhasivam
2025-11-24 11:42 ` Konrad Dybcio
2025-11-24 23:53 ` Bjorn Helgaas
2025-11-25 5:21 ` Manivannan Sadhasivam
2025-11-25 15:30 ` Alexey Bogoslavsky
2025-11-27 18:41 ` Konrad Dybcio
2025-11-27 18:40 ` Konrad Dybcio
2025-12-01 6:48 ` Val Packett [this message]
2025-12-01 10:37 ` Manivannan Sadhasivam
2025-12-04 12:51 ` Konrad Dybcio
2025-12-04 21:28 ` Val Packett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a9280e7-d29a-475a-83fa-671acfab9d92@packett.cool \
--to=val@packett.cool \
--cc=Alexey.Bogoslavsky@sandisk.com \
--cc=Avinash.M.N@sandisk.com \
--cc=Jeff.Lien@sandisk.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®