Re: [PROBLEM] c5.metal on AWS fails to kexec after "PCI: Explicitly put devices into D0 when initializing"
From: Mario Limonciello
Date: Fri Sep 19 2025 - 01:02:26 EST
On 9/18/2025 10:52 PM, Matthew Ruffell wrote:
Hi Mario, Bjorn,
I am debugging a kexec regression, and I could use some help please.
The AWS "c5.metal" instance type fails to kexec into another kernel, and gets
stuck during boot trying to mount the rootfs from the NVME drive, and then moves
at a glacier pace and never actually boots:
[ 79.172085] EXT4-fs (nvme0n1p1): orphan cleanup on readonly fs
[ 79.193407] EXT4-fs (nvme0n1p1): mounted filesystem
a4f7c460-5723-4ed1-9e86-04496bd66119 ro with ordered data mode. Quota
mode: none.
[ 109.606598] systemd[1]: Inserted module 'autofs4'
[ 139.786021] systemd[1]: systemd 257.9-0ubuntu1 running in system
mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT
-GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC
+KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2
+PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD
+BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE)
[ 139.943485] systemd[1]: Detected architecture x86-64.
[ 169.994695] systemd[1]: Hostname set to <ip-172-31-48-167>.
[ 170.102479] systemd[1]: bpf-restrict-fs: BPF LSM hook not enabled
in the kernel, BPF LSM not supported.
[ 200.503000] systemd[1]: Queued start job for default target graphical.target.
[ 200.550056] systemd[1]: Created slice system-modprobe.slice - Slice
/system/modprobe.
[ 230.922947] systemd[1]: Created slice system-serial\x2dgetty.slice
- Slice /system/serial-getty.
[ 261.131318] systemd[1]: Created slice system-systemd\x2dfsck.slice
- Slice /system/systemd-fsck.
[ 291.338906] systemd[1]: Created slice user.slice - User and Session Slice.
[ 321.546200] systemd[1]: Started systemd-ask-password-wall.path -
Forward Password Requests to Wall Directory Watch.
I bisected the issue, and the behaviour starts with:
commit 4d4c10f763d7808fbade28d83d237411603bca05
Author: Mario Limonciello <mario.limonciello@xxxxxxx>
Date: Wed Apr 23 23:31:32 2025 -0500
Subject: PCI: Explicitly put devices into D0 when initializing
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d4c10f763d7808fbade28d83d237411603bca05
I also tried the follow up commit:
commit 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
Author: Mario Limonciello <mario.limonciello@xxxxxxx>
Date: Wed Jun 11 18:31:16 2025 -0500
Subject: PCI/PM: Set up runtime PM even for devices without PCI PM
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
and the behaviour still exists.
If I revert both from 6.17-rc3, as well as the downstream Ubuntu stable kernels,
the system kexec's successfully as normal.
lspci -vvv as root (nvme device)
https://paste.ubuntu.com/p/x7Zyjp8Brr/
lscpi -vvv as root (full output)
https://paste.ubuntu.com/p/NTdbByTqjR/
Strangely, the behaviour works like this:
Kernel without 4d4c10f76 -> kernel without 4d4c10f76 = success
Kernel without 4d4c10f76 -> kernel with 4d4c10f76 = success
Kernel with 4d4c10f76 -> kernel without 4d4c10f76 = failure
Kernel with 4d4c10f76 -> kernel with 4d4c10f76 = failure
Steps to reproduce:
1) On AWS, Launch a c5.metal instance type
2) Install a kernel with 4d4c10f76, note it might need AWS specific patches,
perhaps try a recent downstream distro kernel such as 6.17.0-1001-aws in Ubuntu
Questing with AMI ami-069b93def587ece0f
(ubuntu/images-testing/hvm-ssd-gp3/ubuntu-questing-daily-amd64-server-20250822)
with a full apt update && apt upgrade
3) sudo reboot, to get a fresh full boot. Note, this takes approx 17 minutes.
4) sudo apt install kexec-tools
5) kernel=6.17.0-1001-aws
kexec -l -t bzImage /boot/vmlinuz-$kernel
--initrd=/boot/initrd.img-$kernel --reuse-cmdline
kexec -e
6) On EC2 console, Actions > Monitor and troubleshoot > EC2 serial console,
and watch progress.
I am more than happy to try any patches / debug printk's etc.
Thanks,
Matthew
When you say AWS specific patches, can you be more specific? What is missing from a mainline kernel to use this hardware? IE; how do I know there aren't Ubuntu specific patches *causing* this issue.
I just glanced through a Ubuntu kernel tree log and there are a ton of "UBUNTU: SAUCE: PCI" patches. I didn't investigate any of these anymore than a cursory look of the subsystem though, so I have no idea if that has any bearing on this issue.
I remember a while back there was a patch carried by Ubuntu that could break a regular shutdown that never made it upstream. Don't know what happened with that either.
So I don't doubt you when you say 4d4c10f763d7808fbade28d83d237411603bca05 and 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 caused an issue, but I just want to rule out a bad interaction from other patches. If it would be possible to reproduce this issue on a mainline kernel (say 6.17-rc6) it might be easier for Bjorn or I to look at.
Now I've never used AWS - do you have an opportunity to do "regular" reboots, or only kexec reboots?
This issue only happens with a kexec reboot, right?
The first thing that jumps out at me is the code in pci_device_shutdown() that clears bus mastering for a kexec reboot.
If you comment that out what happens?
The next thing I would wonder if if you're compiling with CONFIG_KEXEC_JUMP and if that has an impact to your issue. When this is defined there is a device suspend sequence in kernel_kexec() that is run which will run various suspend related callbacks. Maybe the issue is actually in one of those callbacks.
A possible way to determine this would be to run rtcwake to suspend and resume and see if the drive survives. If it doesn't, it's a hint that there is something going on with power management in this drive or the bridge it's connected to. Maybe one of them isn't handling D3 very well.
If there is a power management problem with the disk (or the bridge) you can try adding PCI_DEV_FLAGS_NO_D3 to the NVME disk.