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

[Perlow, Jason]

Hi Lukas,

On Tue, Oct 6, 2026, Lukas Wunner wrote:
> Advisory Non-Fatal Errors aren't handled through the Uncorrectable
> Error code path. The kernel just reports and clears the errors.

Thanks, that corrects my guess. My first mail and my follow-up
("a second, separate way for eddba19b8b5f to hurt a platform")
assumed the uncorrectable recovery path. Please disregard that
reasoning. What my tests show is only this: with the bit unmasked on
04:00.2 (106b:1802) the machine powers off at 14 to 24 s, and with it
masked there only, it stays up (120 s). I do not know which action
causes it.

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

Understood. I am preparing a capture that survives the power cut:

 - kernel messages streamed over the network, as before;
 - a loop on a second machine over ssh that reads, every 200 ms or
   so, the Correctable Error Status and Mask and the Uncorrectable
   Error Status of 04:00.2 (and of the root port 00:1b.0) with
   setpci, and logs them until the connection drops;
 - lspci -vvv of the whole tree taken right before the bit is
   unmasked.

The ssh session was still answering at about 16 s in my earlier
runs, so I expect to get several samples before the cut.

I would also like to split two possible causes with the diagnostic
kernel, if you agree they are worth separating:

 1. the config write that clears the mask bit on that function;
 2. the report-and-clear that follows when an ERR_COR message
    arrives (the status write on that function).

Case 1 can be tested by unmasking but never touching the status
register on 04:00.2, case 2 by leaving it masked and clearing the
status once at boot. Tell me if you would rather have a different
split.

Aditya: thank you for the Windows listing. It shows 106b:1802 as a
"System Device" there, which tells us it is enumerated but not
whether Windows touches the mask.

One small point, Lukas, in case it matters for the Windows check:
the Advisory Non-Fatal Error mask bit (bit 13) is in the
Correctable Error Mask register (offset 0x14 in the AER capability),
not the Uncorrectable Error Mask register. The status bit is in
Correctable Error Status (offset 0x10).

On the form of the quirk: I will go with whichever you prefer, a
flag in the PCI core that pci_aer_init() honors, or a
device-specific DECLARE_PCI_FIXUP_EARLY for 106b:1802 only. The AMD
switch port 01:00.0 is not involved in my tests, so I would keep it
out. I will not send a patch before the capture above.

Thanks,
Jason


On Tue, Oct 6, 2026 at 5:44 AM Lukas Wunner <lukas@xxxxxxxxx> wrote:
>
> On Tue, Oct 06, 2026 at 02:01:52PM +0530, Aditya Garg wrote:
> > On 06-10-2026 08:26 am, Lukas Wunner wrote:
> > > On Mon, Oct 05, 2026 at 08:17:12PM -0400, Perlow, Jason wrote:
> > > >   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).
> [...]
> > > 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"
>
> It looks like lspci is also available as a Windows binary:
>
> https://github.com/pciutils/pciutils/releases/tag/v3.15.0
> https://eternallybored.org/misc/pciutils/
>
> Could you double-check whether it unmasks Advisory Non-Fatal Errors
> in the Uncorrectable Error Mask Register, on the T2 or any other device?
>
> Thanks!
>
> Lukas



-- 
Jason Perlow | Argonaut Media Communications

Voice/Text  (954) 242-3484 | jperlow@xxxxxxxxx | 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