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

[Aditya Garg <aditya.garg@linux.dev>]

On 06-10-2026 08:26 am, Lukas Wunner wrote:
> 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.

T2 device is visible on Windows as well as "System Device"

PS C:\Users\Aditya> Get-PnpDevice -Class 'System' -PresentOnly | Where-Object {$_.InstanceId -like "*PCI*"} | Format-Table -AutoSize FriendlyName, InstanceId

FriendlyName                                                                              InstanceId
------------                                                                              ----------
Intel(R) Xeon(R) E3 - 1200/1500 v5/6th Gen Intel(R) Core(TM) PCIe Controller (x4) - 1909  PCI\VEN_8086&DEV_1909&SUBSYS_72708086&REV_07\3&11583659&0&0A
Intel(R) PCI Express Root Port #1 - A338                                                  PCI\VEN_8086&DEV_A338&SUBSYS_72708086&REV_F0\3&11583659&0&E0
Intel(R) Serial IO UART Host Controller - A328                                            PCI\VEN_8086&DEV_A328&SUBSYS_72708086&REV_10\3&11583659&0&F0
AMD PCI Express Upstream Switch Port                                                      PCI\VEN_1002&DEV_1478&SUBSYS_00000000&REV_43\4&D48CA2C&0&0008
Intel(R) PCI Express Root Port #17 - A340                                                 PCI\VEN_8086&DEV_A340&SUBSYS_72708086&REV_F0\3&11583659&0&D8
Intel(R) Xeon(R) E3 - 1200/1500 v5/6th Gen Intel(R) Core(TM) PCIe Controller (x8) - 1905  PCI\VEN_8086&DEV_1905&SUBSYS_72708086&REV_07\3&11583659&0&09
Intel(R) LPC Controller/eSPI Controller - A313                                            PCI\VEN_8086&DEV_A313&SUBSYS_72708086&REV_10\3&11583659&0&F8
High Definition Audio Bus                                                                 PCI\VEN_1002&DEV_AB38&SUBSYS_AB381002&REV_00\6&16883A51&0&01000008
Intel(R) SPI (flash) Controller - A324                                                    PCI\VEN_8086&DEV_A324&SUBSYS_72708086&REV_10\3&11583659&0&FD
System Device                                                                             PCI\VEN_106B&DEV_1802&SUBSYS_1802106B&REV_01\4&3AC8FC3&0&02D8
Intel(R) Host Bridge/DRAM Registers - 3EC4                                                PCI\VEN_8086&DEV_3EC4&SUBSYS_72708086&REV_07\3&11583659&0&00
Intel(R) Management Engine Interface #1                                                   PCI\VEN_8086&DEV_A360&SUBSYS_72708086&REV_10\3&11583659&0&B0
AMD PCI Express Downstream Switch Port                                                    PCI\VEN_1002&DEV_1479&SUBSYS_14791002&REV_00\5&130BE3BB&0&000008
Intel(R) Thermal Subsystem - A379                                                         PCI\VEN_8086&DEV_A379&SUBSYS_72708086&REV_10\3&11583659&0&90
Apple USB Virtual Host Controller                                                         PCI\VEN_106B&DEV_1801&SUBSYS_1801106B&REV_01\4&3AC8FC3&0&01D8
PCI standard RAM Controller                                                               PCI\VEN_8086&DEV_A36F&SUBSYS_00000000&REV_10\3&11583659&0&A2
Intel(R) SMBus - A323                                                                     PCI\VEN_8086&DEV_A323&SUBSYS_72708086&REV_10\3&11583659&0&FC
Intel(R) Xeon(R) E3 - 1200/1500 v5/6th Gen Intel(R) Core(TM) PCIe Controller (x16) - 1901 PCI\VEN_8086&DEV_1901&SUBSYS_72708086&REV_07\3&11583659&0&08

> 
>> 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