Kim, I'm going to target this just to Bionic for now... I realize that you said "all LTS" but Xenial and Trusty are comparatively ancient and are no longer receiving non-security updates.
** Description changed: + IMPACT: + Old, circa 2002 chipsets have a bug: they don't go idle when they are + supposed to. So, a workaround was added to slow the CPU down and + ensure that the CPU waits a bit for the chipset to actually go idle. + This workaround is ancient and has been in place in some form since + the original kernel ACPI implementation. + + But, this workaround is very painful on modern systems. The "inl()" + can take thousands of cycles (see Link: for some more detailed + numbers and some fun kernel archaeology). + + First and foremost, modern systems should not be using this code. + Typical Intel systems have not used it in over a decade because it is + horribly inferior to MWAIT-based idle. + + Despite this, people do seem to be tripping over this workaround on + AMD system today. + + Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD + systems from tripping over the workaround. Remotely modern Intel + systems use intel_idle instead of this code and will, in practice, + remain unaffected by the dummy wait. + + Reported-by: K Prateek Nayak <kprateek.na...@amd.com> + Suggested-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> + Signed-off-by: Dave Hansen <dave.han...@linux.intel.com> + Reviewed-by: Mario Limonciello <mario.limoncie...@amd.com> + Tested-by: K Prateek Nayak <kprateek.na...@amd.com> + Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.na...@amd.com/ + Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.han...@intel.com + + FIX: + This issue pertains to all Zen based processors starting with Naples(Zen1). All LTS releases will need this fix: https://github.com/torvalds/linux/commit/e400ad8b7e6a1b9102123c6240289a811501f7d9 + + TESTCASE: ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) Importance: Undecided Status: Confirmed ** Changed in: linux (Ubuntu Kinetic) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Kinetic) Assignee: (unassigned) => Jeff Lane (bladernr) ** Changed in: linux (Ubuntu Jammy) Status: New => In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Changed in: linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Jeff Lane (bladernr) ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Jeff Lane (bladernr) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Jeff Lane (bladernr) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1990985 Title: ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Kinetic: In Progress Bug description: IMPACT: Old, circa 2002 chipsets have a bug: they don't go idle when they are supposed to. So, a workaround was added to slow the CPU down and ensure that the CPU waits a bit for the chipset to actually go idle. This workaround is ancient and has been in place in some form since the original kernel ACPI implementation. But, this workaround is very painful on modern systems. The "inl()" can take thousands of cycles (see Link: for some more detailed numbers and some fun kernel archaeology). First and foremost, modern systems should not be using this code. Typical Intel systems have not used it in over a decade because it is horribly inferior to MWAIT-based idle. Despite this, people do seem to be tripping over this workaround on AMD system today. Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD systems from tripping over the workaround. Remotely modern Intel systems use intel_idle instead of this code and will, in practice, remain unaffected by the dummy wait. Reported-by: K Prateek Nayak <kprateek.na...@amd.com> Suggested-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Signed-off-by: Dave Hansen <dave.han...@linux.intel.com> Reviewed-by: Mario Limonciello <mario.limoncie...@amd.com> Tested-by: K Prateek Nayak <kprateek.na...@amd.com> Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.na...@amd.com/ Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.han...@intel.com FIX: This issue pertains to all Zen based processors starting with Naples(Zen1). All LTS releases will need this fix: https://github.com/torvalds/linux/commit/e400ad8b7e6a1b9102123c6240289a811501f7d9 TESTCASE: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1990985/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
