Re: [BUG] Xen BUG at mce_amd.c:100 (mc_ec2type) on Zen 3; host left wedged, no reboot

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.10.2026 14:44, Peter Deggendorfer wrote:
> We now have some data points:
> 
> (XEN) [2026-10-27 13:42:10.588] MCE: CPU2 bank 23 status 0x830824448b48ffff
> (XEN) [2026-10-27 18:19:55.593] MCE: CPU2 bank 23 status 0xffffffffffffffff
> (XEN) [2026-10-27 22:11:10.596] MCE: CPU2 bank 17 status 0xffff832036a40048
> (XEN) [2026-10-27 22:11:10.596] MCE: unknown AMD error code 0x48
> (XEN) [2026-10-28 00:33:55.597] MCE: CPU2 bank 10 status 0xffff82d04022a8af
> (XEN) [2026-10-28 05:26:40.599] MCE: CPU2 bank 17 status 0xffff82d0402408e3
> (XEN) [2026-10-29 23:17:25.618] MCE: CPU2 bank 17 status 0xffff82d04022a8af
> (XEN) [2026-10-30 03:25:10.622] MCE: CPU2 bank 23 status 0xffffffffffffffff
> (XEN) [2026-10-30 10:05:55.625] MCE: CPU2 bank 10 status 0xffffffffffffffff
> (XEN) [2026-10-31 00:58:10.625] MCE: CPU2 bank 17 status 0xffff888100b872e8
> (XEN) [2026-10-31 00:58:10.625] MCE: unknown AMD error code 0x72e8
> (XEN) [2026-10-31 04:17:55.632] MCE: CPU2 bank 23 status 0xffff831f00006000
> (XEN) [2026-10-31 04:17:55.632] MCE: unknown AMD error code 0x6000
> 
> Only 3 of these would have hit the BUG(); the others have UC clear or
> an error code that happens to contain a type bit.
> 
> The values look like pointers rather than status registers:
> 
>    ffff82d040......  Xen text/data -- the prefix of every RIP in my
>                      earlier panic dumps
>    ffff831f........ / ffff8320........  same range as rsp in those
>                      dumps (e.g. ffff831fe6b3fc38, ffff832036a87c38)
>    ffff888100b872e8  dom0 Linux range?
>    ffffffffffffffff  looks like a failed read?
> 
> Two things that make me doubt these are real status values at all:
> 0xffff82d04022a8af appears twice, 47 hours apart, for two different
> banks (10 and 17). And all timestamps are congruent mod 15 seconds,
> i.e. this is the poller hitting it on a small fraction of passes.
> 
> I don't know where the read goes wrong.
> 
> /dev/mcelog records match the log lines one-to-one (same banks,
> same order, all CPU 2), but carry status zero in every case. The record's
> status comes from the second read in mca_init_bank(), before
> mcabank_clear(), so that second read returned 0.

Following this observation of yours I've created a patch to fold those
two reads. I've Cc-ed you on the submission, as I think it may be
worthwhile for you to include that patch for further debugging of the
underlying issue.

Jan