|Summary:||2.6.35.*: horrible (exponential? >linear) slowdown to unusability (ACPI idle?)|
|Product:||Platform Specific/Hardware||Reporter:||Maciej Rutecki (maciej.rutecki)|
|Severity:||normal||CC:||maciej.rutecki, nix, rjw, tglx|
|Bug Depends on:|
Description Maciej Rutecki 2010-09-11 19:59:36 UTC
Subject : 2.6.35.*: horrible (exponential? >linear) slowdown to unusability (ACPI idle?) Submitter : Nix <email@example.com> Date : 2010-09-05 0:51 Message-ID : firstname.lastname@example.org References : http://marc.info/?l=linux-kernel&m=128364994602942&w=2 This entry is being used for tracking a regression from 2.6.34. Please don't close it until the problem is fixed in the mainline. Caused by: commit 30a564be9d9554c168a654eddc2165869cc0d7bf Author: Thomas Gleixner <email@example.com> Date: Tue Apr 13 15:31:36 2010 +0200 x86, hpet: Restrict read back to affected ATI chipsets After programming the HPET, we do a readback as a workaround for ATI/SBx00 chipsets as a synchronization. Unfortunately this triggers an erratum in newer ICH chipsets (ICH9+) where reading the comparator immediately after the write returns the old value. Furthermore, as always, I/O reads are bad for performance. Therefore, restrict the readback to the chipsets that need it, or, for debugging purposes, when we are running with hpet=verbose. Signed-off-by: Thomas Gleixner <firstname.lastname@example.org> Acked-by: Venkatesh Pallipadi <email@example.com> LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com> Signed-off-by: H. Peter Anvin <firstname.lastname@example.org> First-Bad-Commit : 30a564be9d9554c168a654eddc2165869cc0d7bf
Comment 1 Rafael J. Wysocki 2010-09-20 20:41:58 UTC
On Monday, September 20, 2010, Nix wrote: > On 20 Sep 2010, Rafael J. Wysocki said: > > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.34 and 2.6.35. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.34 and 2.6.35. Please verify if it still should > > be listed and let the tracking team know (either way). > > Resolved by 54ff7e595d763d894104d421b103a89f7becf47c in master, > which is landing in 18.104.22.168 imminently.