On 22-09-2022 01:21 am, Borislav Petkov wrote:
On Wed, Sep 21, 2022 at 07:15:07AM -0700, Dave Hansen wrote:
In the end, the delay is because of buggy, circa 2006 chipsets? So, we use a CPU vendor specific check to approximate that the chipset is recent and not affected by the bug? If so, is there no better way to check for a newer chipset than this?
So I did some git archeology but that particular addition is in some conglomerate, glued-together patch from 2007 which added the cpuidle tree:
commit 4f86d3a8e297205780cca027e974fd5f81064780 Author: Len Brown len.brown@intel.com Date: Wed Oct 3 18:58:00 2007 -0400
cpuidle: consolidate 2.6.22 cpuidle branch into one patch
In fact, the code has moved around a fair bit and the check in its initial form goes as far back as ACPI's posting for inclusion in the kernel in March 2002 [1]. We could not find any way of digging further back, yet.
Prior to that, I think the ACPI enablement code was being released independent of the kernel per https://kernel.org/doc/ols/2004/ols2004v1-pages-121-132.pdf and was included in Andrew's mm tree for a while.
From https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git the first tag that contains code with the dummy read is v2.5.7 AFAICS.
Ananth
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/co...