Correctable PCIe AER RxErr on Minisforum M1 Pro 285H / Kingston NVMe with 7.0.14-24 and -25-pve

[vaamdlt]

Hello,

I would appreciate advice on diagnosing occasional correctable PCIe errors on a Minisforum M1 Pro 285H running Proxmox VE.

Hardware:
- Intel Core Ultra 9 285H; ARBSC motherboard, revision 1.0.
- AMI BIOS 1.01, dated 2025-06-19.
- Kingston OM8TAP41024K1-A00 NVMe, firmware P4ER3B31.
- NVMe endpoint 0000:55:00.0 behind root port 0000:00:1c.0; observed link 16 GT/s x4.
- Active CPU microcode 0x11a.

The issue occurs with both 7.0.14-24-pve and 7.0.14-25-pve. Representative log excerpt:

nvme 0000:55:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)
nvme 0000:55:00.0:    [ 0] RxErr                  (First)

A log extraction found 35 events from October 16 to 20, 2026 (1, 5, 6, 19 and 4 respectively). These are partial days with reboots, so the counts are not directly comparable rates. The latest event in that extraction occurred on October 20 at 15:57 CEST, after booting -25 that morning.

Checks so far:
- Targeted log searches found no I/O errors, NVMe timeouts, resets or aborts.
- SMART showed 1 Media/Data Integrity Error and 5 Unsafe Shutdowns, unchanged across the checks. Their dates are unknown; no link to the PCIe events has been established. The NVMe error log was empty and short/extended self-tests passed.
- Errors predate GPU passthrough experiments.
- A temporary test disabled only ASPM L1.2, leaving L1 and PCI-PM L1.2 enabled. No new RxErr appeared during approximately three hours, but that is too short to establish a fix. Reboot restored L1.2; no permanent change has been made.
- I could not find BIOS controls for ASPM/L1.2 or PCIe link speed.

I have read the existing "NVME correctable errors?" thread, but have not established whether the same cause applies here.

Has anyone seen this combination of hardware and kernel? Is there a known ASPM/L1-substate or -pve kernel issue worth checking? What controlled tests and diagnostic output would best distinguish power-management behavior from an SSD/slot/link problem?

I want to diagnose the cause rather than hide AER messages. I can provide sanitized pveversion -v, kernel command line and lspci output if useful.

Thank you.

 

[kcastner_de]

Hi @vaamdlt,

I'm having similar issues with my Epic servers and some WD NVMe SSDs… My Samsung NVMe drives, on the other hand, work without any problems.

The only solution that worked for me was to disable the watchdog and inventory in the BIOS. I don’t know the exact cause, but this solution works for me.
As some publicly available documents indicate, firmware support for certain devices is incomplete.

Do you have any additional information or logs I could take a look at?

 

[vaamdlt]

Thanks @kcastner_de. Sanitized details from my system:
- Proxmox VE 9.2, kernel 7.0.14-25-pve; BIOS AMI 1.01 (2025-06-19), ARBSC 1.0.
- Link 16 GT/s x4 on both ends; firmware leaves ASPM L1 and L1.2 enabled (lspci LnkCtl/L1SubCtl).
- Disabling only ASPM L1.2 at runtime did not stop the errors (3 more RxErr in about 12 hours).
- The manufacturer suggested pcie_aspm=off pcie_port_pm=off nvme_core.default_ps_max_latency_us=0; I am testing it now, though lspci still shows L1 enabled afterwards.
I did not find "watchdog" or "inventory" options in my BIOS menus. Could you tell me their exact names, your platform/BIOS version and the affected WD model? Does the problem also occur with the SSD in a different slot?

Thanks, that clarifies the intended test: use pcie_aspm.policy=performance without pcie_aspm=off, and verify the actual link state rather than relying on the boot parameters alone.

I am currently testing the configuration recommended by Minisforum:

pcie_aspm=off pcie_port_pm=off nvme_core.default_ps_max_latency_us=0

With that configuration, lspci still reports ASPM L1 and L1.2 enabled at both link endpoints.

If I proceed with the performance-policy test, I will post the four values you requested before and after, plus the link configuration at the upstream root port (00:1c.0). I would keep the other two parameters unchanged to isolate the ASPM policy change. I would test any CPU C-state restriction separately, rather than changing both settings at once.

The drive is a Kingston OM8TAP41024K1-A00, firmware P4ER3B31. By "improper firmware", do you mean the SSD firmware or the motherboard BIOS? Did a firmware update resolve the issue on your WD or Lexar drives, or are you avoiding it through power-management settings?

 

[kcastner_de]

Hi @vaamdlt!

On server motherboards, these settings are located in various places. In most versions, they have the names we've already mentioned. I'm not sure if they're available on Minisforum.

At least at them, the error should be gone:

pcie_aspm=off pcie_port_pm=off

If the problem persists, you could try to set the policy to performance.

pcie_aspm.policy=performance

I personally can confirm these bugs with WD_BLACK SN770 series aswell with Lexar SSD NM620 series. Mostly caused by an inproper firmware.

EDIT:
Can you post these values befor/after change to performance please?

cat /proc/cmdline                              # pcie_aspm=off shouldn't be there
cat /sys/module/pcie_aspm/parameters/policy    # should be: default [performance] powersave powersupersave
lspci -vvv -s 55:00.0 | grep LnkCtl:           # should be: ASPM Disabled
grep RxErr /sys/bus/pci/devices/0000:55:00.0/aer_dev_correctable

EDIT 2:
If you can set the C-states, please set them to C3 at most - this could also cause link errors.

 

[kcastner_de]

Hi,

you edited your answer - please add a new one to ensure notifications.

I would keep the other two parameters unchanged to isolate the ASPM policy change. I would test any CPU C-state restriction separately, rather than changing both settings at once.

Keeping your dir Parameters unchanged, it will skip the policy rule. You should delete/disable them instead.
By test them separately, you'll get the root cause - I'm fine with.

By "improper firmware", do you mean the SSD firmware or the motherboard BIOS? Did a firmware update resolve the issue on your WD or Lexar drives, or are you avoiding it through power-management settings?

Can't tell it for sure. Mostly the BIOS tells the SSD to sleep, but the SSD wont respond at time. After ReTx, it'll work.
Due to my watchdog disable settings, I cant enter C-States above 3. I assume, it's the power saving feature.