CAN/402 shows 7f? Check the kernel fix first.

1. Confirm the application note applies to your hardware

Read the product list and revision information in esd electronics AN0001 revision 1.7: CAN/402 interoperability (PDF). Match the complete card model and bridge arrangement, not just “CAN” in a device description. Record the card revision, host motherboard, operating system and kernel.

The note’s Linux failure example has an all-ones configuration read and a 7f header warning. The documented cause is a specific bridge erratum during PCIe ASPM reconfiguration. That gives affected owners a concrete lead; it does not establish the same cause on an unrelated GPU, Wi-Fi card or industrial adapter.

uname -r
cat /proc/cmdline
lspci -Dnn
lspci -t
# Replace this example with your CAN card address.
sudo lspci -s 0000:03:00.0 -vv
sudo journalctl -k -b --no-pager

2. Check the bridge-specific kernel fix first

AN0001 says the equivalent fix reached mainline Linux 5.2 and lists stable backports to 5.1.5, 5.0.19, 4.19.46, 4.9.179 and 3.16.74. These are historical inclusion points, not versions to install today. Check a currently supported distribution kernel and its backport history for your platform. esd electronics AN0001 revision 1.7: CAN/402 interoperability (PDF).

Current upstream Linux includes a Pericom quirk that enables special handling of the retrain-link bit for matching bridge IDs, including 0xe111. The displayed kernel version alone cannot establish a vendor kernel’s patch contents; ask the distributor or esd when uncertain. Linux kernel source: Pericom retrain-link quirk.

If a supported kernel already contains the fix and the fault persists, collect the actual bridge IDs and failed-state evidence. The old erratum is a lead to check, not proof of the present cause. A machine-wide ASPM change should not be the default first remedy.

3. Evaluate the vendor’s workaround if still needed

For the affected setup, esd documents booting Linux with pcie_aspm=off to prevent ASPM reconfiguration. The scope is the whole machine, so this deserves a planned comparison rather than an unexplained permanent boot change. esd electronics AN0001 revision 1.7: CAN/402 interoperability (PDF).

1. Confirm applicability with the application note or esd support, especially for an unlisted revision.
2. Save the current boot configuration and arrange local recovery access.
3. Use your distribution’s documented procedure to test the parameter for a boot. Bootloader instructions differ; do not assume every machine uses GRUB.
4. After boot, inspect /proc/cmdline to confirm the test parameter is active.
5. Check PCIe access and perform the same CAN application test that previously failed.

The vendor note is the authority for this remedy. Keep it with the machine’s maintenance record and verify that no other device or operational requirement regresses.

4. Verify actual CAN operation

Use an isolated or approved CAN test setup and the card vendor’s tools. Record more than the absence of the warning: driver initialization, successful transmit/receive in the intended mode and behavior over the previously failing interval. Do not inject test traffic onto a live control bus without the system owner’s approved procedure.

If the card remains inaccessible, stop stacking unrelated parameters. Give esd support the exact model, bridge topology, baseline log and comparison with the documented workaround. Ask whether a hardware revision, firmware change or another supported resolution applies to your installation.

Common CAN-card questions

Should every unknown-header error use pcie_aspm=off?

No. This article covers a vendor-documented hardware combination. Start with the general diagnostic guide if the card or bridge does not match.

Is recovery proof of a permanent fix?

No. Keep the workaround and its scope documented, then validate the operating and startup conditions your system actually uses. Ask the vendor about longer-term resolution for the exact revision.

What should a reusable solution provide?

A device-specific maintenance record, checked compatibility information and a repeatable acceptance test. Industrial buyers need a supportable outcome with clear limits; a generic list of kernel switches does not provide that.