Messages in this thread | | | Date | Fri, 20 Oct 2023 08:59:13 +0200 | Subject | Re: X86 parallel bring up regression | From | "Linux regression tracking #adding (Thorsten Leemhuis)" <> |
| |
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.]
On 19.10.23 22:26, Mario Limonciello wrote: > > 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 for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot:
#regzbot ^introduced 0c7ffa32dbd6 #regzbot title x86: resume from suspend-to-ram broken on some AMD platforms #regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
| |