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

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

[Bjorn Helgaas]

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/),
I used this one instead.  It's on pci/for-linus for v7.3.

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

[Perlow, Jason]

[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]

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

[-- Attachment #2: apple-sep-anfe-quirk-clean.patch --]
[-- Type: application/octet-stream, Size: 1977 bytes --]

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 922a726a52a5..732f75a31760 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -428,7 +428,8 @@ void pci_aer_init(struct pci_dev *dev)
 	 * Advisory Non-Fatal Errors are masked by default (PCIe r7.0, sec
 	 * 7.8.4.6).
 	 */
-	if (pcie_aer_is_native(dev) && dev->devcap & PCI_EXP_DEVCAP_RBER)
+	if (pcie_aer_is_native(dev) && dev->devcap & PCI_EXP_DEVCAP_RBER &&
+	    !dev->no_aer_anfe)
 		pci_clear_and_set_config_dword(dev,
 					       dev->aer_cap + PCI_ERR_COR_MASK,
 					       PCI_ERR_COR_ADV_NFAT, 0);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index de9bbccda21f..677cd8797d19 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2574,6 +2574,17 @@ static void quirk_p64h2_1k_io(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1460, quirk_p64h2_1k_io);
 
+/*
+ * Unmasking Advisory Non-Fatal Errors on the Apple T2 Secure Enclave
+ * causes a MacBookPro16,1 to lose power.  Set this before pci_aer_init()
+ * so that it leaves the ANFE mask bit unchanged.
+ */
+static void quirk_no_aer_anfe(struct pci_dev *dev)
+{
+	dev->no_aer_anfe = 1;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_APPLE, 0x1802, quirk_no_aer_anfe);
+
 /*
  * Under some circumstances, AER is not linked with extended capabilities.
  * Force it to be linked by setting the corresponding control bit in the
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d31a8d107b1e..5ffcf5ce8c96 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -467,6 +467,7 @@ struct pci_dev {
 
 	unsigned int	is_busmaster:1;		/* Is busmaster */
 	unsigned int	no_msi:1;		/* May not use MSI */
+	unsigned int	no_aer_anfe:1;		/* Do not unmask ANFE */
 	unsigned int	block_cfg_access:1;	/* Config space access blocked */
 	unsigned int	broken_parity_status:1;	/* Generates false positive parity */
 	unsigned int	irq_reroute_variant:2;	/* Needs IRQ rerouting variant */

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

[Perlow, Jason]

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 <jperlow@gmail.com> 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 | jperlow@gmail.com | 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