Messages in this thread | | | Date | Mon, 23 Oct 2023 11:04:31 -0500 | Subject | Re: X86 parallel bring up regression | From | Mario Limonciello <> |
| |
On 10/19/2023 15:26, Mario Limonciello wrote: > Hi, > > We've recently found that there was a regression from 6.5 that broke > resume from suspend-to-ram on some AMD platforms. > > We bisected it and confirmed it's introduced by 0c7ffa32dbd6 > ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and > enable it"). > > Furthermore; we confirmed that on 6.6-rc6 adding cpuhp.parallel=0 to the > kernel command line avoids the issue. > > Here are bootup kernel logs from an affected system at 7e75178 (doesn't > reproduce) and 0c7ffa32 (does reproduce). > https://gist.github.com/superm1/c251c0849956b8389309f03871fba091 > > Is it possible that this is caused by the system entering S3 with x2apic > enabled but leaving with it disabled? > > I notice in the resume path on a boot with cpuhp.parallel=0 that x2apic > "explicitly" gets turned on again. > > <snip> > smpboot: CPU 127 is now offline > ACPI: PM: Low-level resume complete > ACPI: PM: Restoring platform NVS memory > x2apic enabled > AMD-Vi: Virtual APIC enabled > AMD-Vi: Virtual APIC enabled > LVT offset 0 assigned for vector 0x400 > Enabling non-boot CPUs ... > smpboot: Booting Node 0 Processor 1 APIC 0x2 > masked ExtINT on CPU#1 > ACPI: \_SB_.PLTF.C002: Found 2 idle states > CPU1 is up > smpboot: Booting Node 0 Processor 2 APIC 0x4 > </snip> > > I hypothesize this could be caused by .Lread_apicid finding x2apic > disabled but then trying to read from apic_mmio_base which isn't > initialized because x2apic was used (AFAICT apic_set_fixmap() never gets > called in this case). > > Thanks,
AFAICT the issue is indeed that x2apic isn't re-enabled during s3 resume.
I've posted a series that I confirmed resolves the issue here:
https://lore.kernel.org/all/20231023160018.164054-1-mario.limonciello@amd.com/T/#t
| |