Re: [REGRESSION] PCI/AER: MacBookPro16,1 powers off ~20 s after boot

[Lukas Wunner <lukas@wunner.de>]

On Mon, Oct 05, 2026 at 08:17:12PM -0400, Perlow, Jason wrote:
> > > My guess, and it is
> > > only a guess: treating a possible Advisory Non-Fatal Error as
> > > non-Advisory and recovering through the uncorrectable path resets or
> > > disturbs a T2 function, and the T2 then powers the machine down.

Advisory Non-Fatal Errors aren't handled through the Uncorrectable
Error code path.  The kernel just reports and clears the errors.

And if the device has a driver and that driver implements the
->cor_error_detected callback() in struct pci_error_handlers,
that callback is invoked.  (Currently only the CXL driver
implements the callback.)

>   masked only on 04:00.2 (Apple T2 Secure Enclave, 106b:1802):
>       stays up (120 s)
[...]
> So here the trigger is unmasking Advisory Non-Fatal Errors on that
> one function.

That's quite unexpected.  Maybe there's a bug in the PCIe IP which
Apple used for the T2 Secure Enclave device (which I believe is a
fully-fledged arm64 CPU with a PCIe port in Endpoint mode).

Another explanation might be that there's a watchdog on the T2 device
which monitors its Config Space and triggers a poweroff whenever
some suspicious register mutation is detected.  I'm just guessing
here because this is really weird.

macOS likely never unmasks the bit and so they never saw this during
validation testing.  Is the T2 device visible on Windows?  If it is,
it seems Windows doesn't support and unmask Advisory Non-Fatal Errors
either.

> Would you accept a quirk that keeps the bit masked on Apple
> 106b:1802?
[...]
> I am happy to write and test that, or any other patch you
> would like tried on this machine, and I can send lspci -vvv and the
> journals.

A quirk does sound like the only possible solution.  However I'd
really like to see lspci and dmesg output with the bit unmasked
shortly before poweroff to get a full understanding.

Thanks!

Lukas