Bjorn, Lukas,
Follow-up to my October 10 report. I have now tested the quirk on v7.3-rc7,
which already contains 79c168e2aa95 ("PCI/AER: Skip error recovery on false
alarms").
Kernel: v7.3-rc7 (24a19b953e2a) with the Apple T2 patch stack and the SEP ANFE
quirk. The quirk is an EARLY fixup on Apple [106b:1802] that sets a per-device
flag, so pci_aer_init() leaves ANFE masked on that one function. ANFE handling
is unchanged everywhere else. There is no global revert of eddba19b8b5f in
this kernel.
Systems: two MacBookPro16,1 (Core i7-9750H and Core i9-9980HK), freshly
installed on this kernel.
Results, both machines:
- Boots to the graphical session, confirmed on the panel (not only by
service state).
- Suspend and resume complete with the session intact.
- Cold boot from power off works (both machines).
- 2 hour idle soak: no AER, GHES or MCE report, oops, BUG or call trace in
the journal.
- Read-only config space check of the correctable error mask:
04:00.2 [106b:1802] 0x00006000 (ANFE, bit 13, masked)
04:00.0 / .1 / .3 0x00004000 (ANFE unmasked)
Controls: an ASUS GU502LV and an Intel Arrow Lake desktop boot the same kernel
with no SEP device present. The quirk does nothing there and nothing regresses.
Limits: two units of one model. No AER error injection, kexec or other T2
models. The test kernel was built with gcc 16.2; the release kernel I compared
against used gcc 14. The quirk matches on vendor/device ID, which the T2 team
says is the same on all T2 models, not on DMI. I still do not know why
unmasking ANFE on this function powers the machine off; the quirk is a
targeted workaround, not an explanation.
On Fri, Oct 9, 2026 at 11:49 PM Perlow, Jason <[email protected]> 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.
> I also have a zip file with all logs/evidence if needed.
>
> Thanks,
> Jason
--
Jason Perlow | Argonaut Media Communications
Voice/Text (954) 242-3484 | [email protected] | Blog: techbroiler.net
Read my Tech and Food Industry articles: https://linktr.ee/jperlow
Bluesky: https://bsky.app/profile/jperlow.bsky.social
Need to schedule a meeting with me? https://bit.ly/3y8P3Gp
