Re: PCI/AER: MacBookPro16,1 test results with Apple SEP ANFE quirk

On Fri, Oct 09, 2026 at 11:38:50PM -0400, Perlow, Jason wrote:

Bjorn, Lukas,

I have tested the Apple SEP ANFE quirk together with Lukas's false-alarm
recovery fix on two MacBookPro16,1 systems. Both stayed up for over two
hours after booting the candidate kernel. The patch is being prepared
against pci/for-linus at 79c168e2aa957ed0054c93db17caba653b95e377.

The candidate retains eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal
Errors"), adds 79c168e2aa95 ("PCI/AER: Skip error recovery on false
alarms"), and leaves the ANFE mask unchanged only on the Apple T2 Secure
Enclave Processor [106b:1802]. The global ANFE revert is absent from the
test kernel. The per-device flag approach follows Aditya's earlier
proposal, with an EARLY fixup so the flag is set before pci_aer_init().

The test systems are:

  MEDUSA:  MacBookPro16,1, Core i7-9750H
  CHIMERA: MacBookPro16,1, Core i9-9980HK

Both ran 7.3.0-rc6-6-t2-edge-apple-sep-anfe-test, confirmed by uname and
the kernel banner in each current boot journal. At the 23:24 EDT check
on October 9, MEDUSA had 2 hours 22 minutes uptime and Chimera had
2 hours 21 minutes. Their boot IDs were unchanged from the initial
successful candidate boots. graphical.target and the display manager
were active on both, and neither had failed systemd units.

Read-only config-space checks gave the same results on both systems:

  Function                    Correctable error mask
  Apple SEP, 04:00.2           0x00006000
  Apple function, 04:00.0      0x00004000
  Apple function, 04:00.1      0x00004000
  AMD GPU, 03:00.0             0x00000000

ANFE bit 13 is therefore masked on the SEP and unmasked on the other
observed functions. No config-register writes were used in these checks.
The implementation matches vendor/device ID, not these bus addresses.

Neither candidate boot journal contains an AER/GHES report, kernel
panic, oops, BUG or call trace. Neither recorded additional kernel
messages after the initial 21:04 checks through the 23:24 check.

The earlier Wunner-only candidate booted on MEDUSA but then powered off,
as I reported on October 8. Its retained journal ended before that event;
there was no recorded shutdown sequence or panic. The cause of the power
loss is still unknown, and this quirk does not establish a firmware
mechanism. The combined candidate has not reproduced that symptom within
the observed interval.

There are remaining boot warnings unrelated to the reported AER symptom:
ACPI duplicate-table/method errors, AMD SDMA fence fallback warnings,
HID rotation probe failures, and Broadcom P2P failures. Chimera also logs
CPU 0 machine-check records in banks 12 and 13. These warning categories,
including the same machine-check status/address records, appear in the
previous boot logs. I am retaining them as separate follow-up issues.

This was a v7.3-rc6 test build with the existing T2 driver/patch stack,
using Debian Forky GCC 16.2 and binutils 2.47. It was not a vanilla
upstream kernel or an identical-toolchain comparison to the older GCC 14
release image. Artifact checksums, exact source/provenance, config checks,
t2gmux/t2smc builds and imported-symbol CRC checks passed. A generic
KVM/OVMF boot also passed; the hardware observations above come from the
two physical systems, not KVM.

The T2 team reports that [106b:1802] identifies the SEP across T2 models,
but this report covers only these two MacBookPro16,1 machines. I have not
tested other T2 models, power-off/cold-start, suspend/resume, reset, kexec
or deliberate AER error injection. Physical confirmation of the rendered
GUI is not included in this report; desktop service state was checked
remotely. The existing release/rescue boot files were preserved.

The patch (enclosed) leaves other ANFE handling enabled and is idempotent
across
repeated fixup/AER initialization. Please review it as a targeted workaround
for the MacBookPro16,1 regression, with the testing limits above.

Thanks for this!  Since you posted this before Aditya's essentially
identical patch
(https://lore.kernel.org/all/20261010172301.12764-1-aditya.garg@linux.dev/ (local)),
I used this one instead.  It's on pci/for-linus for v7.3.