~3% of all CPU cycles spent in clock_gettime calls on boards with Airmont uarch / kernel 3.18 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue description
Chrome Version: 46-50, stable
Chrome OS Version: various
Chrome OS Platform: cyan, celes, reks
Network info: various
Steps To Reproduce:
(1) On either an idle or busy device, run `sudo perf top`
Expected Result:
[vdso] __vdso_clock_gettime does not appear as a hot function in excess of 0.5% CPU time.
Actual Result:
[vdso] __vdso_clock_gettime consistently takes >1% CPU time, often ~3%.
How frequently does this problem reproduce?
Always
What is the impact to the user, and is there a workaround?
Unnecessary persistent CPU usage. I am unaware of any workaround.
Please provide any additional information below. Attach a screen shot or
log if possible.
Data from ChromeOS-wide-profiling shows __vdso_clock_gettime taking ~3% CPU time, whether idle or busy, on each of the boards {cyan, celes, reks}, on all stable releases from 46 through 50. For comparison, the following shows the average CPU time spent in __vdso_clock_gettime across all samples in the 95%-ile of busyness, broken down by uarch and for R49:
Airmont: 4.4%
Haswell: 0.54%
max(all other x86 uarchs): 0.32%
Note that these boards are all running kernel 3.18, so this may be a kernel issue rather a board-specific or uarch-specific issue.
Showing comments 115 - 214
of 214
Older ›
,
Jul 6 2016
re #113 -- I believe he said that does give the expected result in #106 and he put up a CL here https://chromium-review.googlesource.com/#/c/357731/5
,
Jul 6 2016
re #115. I apparently missed that one. That would fix it because we meet the 'fill entire vma' check in track_pfn_remap().
,
Jul 8 2016
The CL# 357731 looks potentially to have side effect that creats extra entries in PAT; appreciating Aaron's comment of #114, reader shall see bunch of duplicated uncached-minus entries in 'pat_memtype_list' With regard to this concern and combines previous realization of reserve_pfn_range(), I wrote another hack that able to reach same efficacy; that is: https://chromium-review.googlesource.com/#/c/359082/ The patch utilizes track_pfn_remap() to invoke reserve_pfn_range() because it is internal kernel API function. That being said, it is still unable to compromise why it not affects BDW and SKL platforms. Recall we mention about PAT lookup when first vvar remapping, when I traced down to lookup_memtype(), I realized on problematic BSW/BYT (w/ 3.18), the function always returns 2, uncached-minus, rather then 0; as we know the map_vdso implementation will not reserve the pfn range, thus the key point is the identification of pat_pagerange_is_ram() call, my observation shows on lulu (BSW) it returns true while on celes (BSW) it fails, that explains why celes gets 'uncached-minus' page cache mode on vvar page. Dive into pat_pagerange_is_ram() and realies walk_system_ram_range() finds iomem resources in 1st level only, readers could compare the hierarchy though 'cat /proc/iomem' for the indentation of 'System RAM' resource, on my lulu, there is 'System RAM' in 1st level but not in celes and rambi becasue the resources are in child level. As to it I wrote another to force PAT resource scanning down to the deepest level, this could archive same efficacy as reserve_pfn_range() https://chromium-review.googlesource.com/#/q/topic:vdso_debug Next questions, how the iomem resources comes from? I suspect relative to firmware, anyone who has insight could share openly.
,
Jul 8 2016
Harry, can you please provide /proc/iomem and /sys/firmware/log for lulu and celes as well as the following? $ find /sys/firmware/memmap/ -maxdepth 1 -type d | grep [0-9] | while read d; do echo $(basename $d) $(cat $d/start) -- $(cat $d/end) $(cat $d/type); done
,
Jul 8 2016
There you go. celes: $ find /sys/firmware/memmap/ -maxdepth 1 -type d | grep [0-9] | while read d; do echo $(basename $d) $(cat $d/start) -- $(cat $d/end) $(cat $d/type); done 0 0x0 -- 0xfff reserved 1 0x1000 -- 0x9ffff System RAM 2 0xa0000 -- 0xfffff reserved 3 0x100000 -- 0x1fffffff System RAM 4 0x20000000 -- 0x200fffff reserved 5 0x20100000 -- 0x7cc1ffff System RAM 6 0x7cc20000 -- 0x7cffffff reserved 7 0x7d000000 -- 0x7fffffff reserved 8 0xe0000000 -- 0xefffffff reserved 9 0xfea00000 -- 0xfebfffff reserved 10 0xfed01000 -- 0xfed01fff reserved 11 0xfed03000 -- 0xfed03fff reserved 12 0xfed06000 -- 0xfed06fff reserved 13 0xfed08000 -- 0xfed08fff reserved 14 0xfed1c000 -- 0xfed1cfff reserved 15 0xfed40000 -- 0xfed44fff reserved 16 0xfed80000 -- 0xfed83fff reserved lulu: 0 0x0 -- 0xfff reserved 1 0x1000 -- 0x9ffff System RAM 2 0xa0000 -- 0xfffff reserved 3 0x100000 -- 0x7ce3bfff System RAM 4 0x7ce3c000 -- 0x7cffffff reserved 5 0x7d000000 -- 0x7fffffff reserved 6 0xf0000000 -- 0xf3ffffff reserved 7 0xfed10000 -- 0xfed19fff reserved 8 0xfed80000 -- 0xfed84fff reserved 9 0x100000000 -- 0x17effffff System RAM
,
Jul 8 2016
rambi w/ 3.18: 0 0x0 -- 0xfff reserved 1 0x1000 -- 0x9ffff System RAM 2 0xa0000 -- 0xfffff reserved 3 0x100000 -- 0x1fffffff System RAM 4 0x20000000 -- 0x200fffff reserved 5 0x20100000 -- 0x7ae6dfff System RAM 6 0x7ae6e000 -- 0x7affffff reserved 7 0x7b000000 -- 0x7fffffff reserved 8 0xe0000000 -- 0xefffffff reserved 9 0xfeb00000 -- 0xfebfffff reserved 10 0xfed01000 -- 0xfed01fff reserved 11 0xfed03000 -- 0xfed03fff reserved 12 0xfed05000 -- 0xfed05fff reserved 13 0xfed08000 -- 0xfed08fff reserved 14 0xfed0c000 -- 0xfed0ffff reserved 15 0xfed1c000 -- 0xfed1cfff reserved 16 0xfef00000 -- 0xfeffffff reserved
,
Jul 8 2016
I take it rambi has issues as well given the iomem layout? Do you have dmesg on celes? I think the reason for the bizarre iomem is the LPE audio device having horrible constraints. You can see that for rambi looking at resources with this marking: 80860F28:00. The braswell ones (808622A8:00) are worse because it's claiming it owns first 4KiB of memory because of poor ACPI code. Broadwell is using HD audio so there's no constraints there w.r.t. to a random device being claiming memory resources. And skylake doesn't have an ACPI device either. Because those devices are showing up under PCI root bridge the resources are expanded. That said, I think if you convert the PAT code to use walk_iomem_res() and pass "System RAM" and/or provide a variant of walk_system_ram_rage which follows into children you should work. We can also make a firmware change to test things out if you'd like.
,
Jul 12 2016
I am willing to test new firmware, pick up debug firmware patch, or guild me to tinker firmware ACPI table. Also, I implemented another option up on Aaron's thought, hacked x86 PAT code instead of kernel resource one, that is: https://chromium-review.googlesource.com/#/c/359354
,
Jul 18 2016
As waiting for discussion here, I filed bugzilla to consult upstream developers: https://bugzilla.kernel.org/show_bug.cgi?id=135501
,
Jul 18 2016
I'm not sure there's a firmware patch to try that I know will work. On baytrail, the LPE ASL is included within the \_SB scope -- not under the pci bridge scope. I was thinking it was doing the latter. But it's not... see src/soc/intel/baytrail/acpi/southcluster.asl in coreboot. You can try changing things around in there, but it doesn't look promising at the moment.
,
Aug 10 2016
Perhaps incorrect TOLM (debug print showed 0) value leading nested structure of 'System RAM', hardcoded PMIN w/ 2GB value tinkers the table. minicom.cap: <snip> HP: gnvs->tolm=0x0
,
Aug 10 2016
Harry, I forgot to open up this bug. It seems there's some register settings in src/soc/intel/baytrail/cpu.c (see core_msr_script) which turn off access to TOLM register. So when we set tolm in acpi nvs space (src/soc/intel/baytrail/acpi.c) we're getting back a zero.
The following should work on braswell as well (coreboot patches):
diff --git a/src/soc/intel/baytrail/northcluster.c b/src/soc/intel/baytrail/northcluster.c
index 55ace59..c153df4 100644
--- a/src/soc/intel/baytrail/northcluster.c
+++ b/src/soc/intel/baytrail/northcluster.c
@@ -25,6 +25,7 @@
#include <soc/iosf.h>
#include <soc/pci_devs.h>
#include <soc/ramstage.h>
+#include <stddef.h>
/* Host Memory Map:
*
@@ -65,7 +66,14 @@
uint32_t nc_read_top_of_low_memory(void)
{
- return iosf_bunit_read(BUNIT_BMBOUND) & ~((1 << 27) - 1);
+ MAYBE_STATIC uint32_t tolm = 0;
+
+ if (tolm)
+ return tolm;
+
+ tolm = iosf_bunit_read(BUNIT_BMBOUND) & ~((1 << 27) - 1);
+
+
,
Aug 11 2016
https://chromium-review.googlesource.com/#/c/368015 $ grep "HP:" minicom.cap HP: gnvs->tolm=0x80000000 HP: gnvs->tolm=0x80000000 HP: gnvs->tolm=0x80000000 55ns in avg. per clock_gettime(): localhost ~ # time b.out 1000000000 real 0m55.180s user 0m54.954s sys 0m0.023s
,
Aug 12 2016
. firmware-strago-7287.B https://chromium-review.googlesource.com/#/c/368580 └─ firmware-cyan-7287.57.B https://chromium-review.googlesource.com/#/c/368585 └─ firmware-celes-7287.92.B https://chromium-review.googlesource.com/#/c/368015 └─ firmware-ultima-7287.131.B https://chromium-review.googlesource.com/#/c/368581 └─ firmware-reks-7287.133.B https://chromium-review.googlesource.com/#/c/368582 └─ firmware-terra-7287.154.B https://chromium-review.googlesource.com/#/c/368583 └─ firmware-edgar-7287.167.B https://chromium-review.googlesource.com/#/c/368584 Need review and verify, I compiled strago ONLY but no device to test, as to others.
,
Aug 12 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/31a306d844f9218f25114302663e8125e7832d0a commit 31a306d844f9218f25114302663e8125e7832d0a Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-strago-7287.B TEST=rebuild firmware, deploy to remote strago, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368580 Tested-by: Anson Tseng <ansonfcu@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/31a306d844f9218f25114302663e8125e7832d0a/src/soc/intel/braswell/northcluster.c
,
Aug 17 2016
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/8fbe1e77ecbad05fc33651033dad81e0b946b947 commit 8fbe1e77ecbad05fc33651033dad81e0b946b947 Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-cyan-7287.57.B TEST=rebuild firmware, deploy to remote cyan, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368585 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/8fbe1e77ecbad05fc33651033dad81e0b946b947/src/soc/intel/braswell/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/6866f549428f64ae90b27c4a5f9ffb159b6a80c1 commit 6866f549428f64ae90b27c4a5f9ffb159b6a80c1 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Thu Aug 18 03:33:15 2016 Partially backport the MAYBE_STATIC macro from upstream The patch of ACPI table (CL:368516) relies on an upsteam commit of dbe0df199215 ("Add and consistently use wrapper macro for romstage static variables"), lack of MAYBE_STATIC would generate compilation error on top of CL:368516. This patch partially backports the macro of MAYBE_STATIC from the upstream. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-rambi-5216.B TEST=rebuild firmware, deploy to remote rambi w/ 3.18 kernel, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/6866f549428f64ae90b27c4a5f9ffb159b6a80c1/src/include/stddef.h
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/adb6b62b0f4c2c07b3d0948a3e58672d36795a5a commit adb6b62b0f4c2c07b3d0948a3e58672d36795a5a Author: Harry Pan <harry.pan@intel.com> Date: Fri Aug 12 09:00:59 2016 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-rambi-5216.B TEST=rebuild firmware, deploy to remote rambi w/ 3.18 kernel, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/adb6b62b0f4c2c07b3d0948a3e58672d36795a5a/src/soc/intel/baytrail/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/f2aaf73aaed9fa40dd895c151c72992509f8337d commit f2aaf73aaed9fa40dd895c151c72992509f8337d Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-celes-7287.92.B TEST=rebuild firmware, deploy to remote celes, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368015 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/f2aaf73aaed9fa40dd895c151c72992509f8337d/src/soc/intel/braswell/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/01bdac59299101607901479710f1a38b8e549b29 commit 01bdac59299101607901479710f1a38b8e549b29 Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-ultima-7287.131.B TEST=rebuild firmware, deploy to remote ultima, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368581 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/01bdac59299101607901479710f1a38b8e549b29/src/soc/intel/braswell/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/18403a336e5aff4a3c0b4e8ec3c14d40c113f2a9 commit 18403a336e5aff4a3c0b4e8ec3c14d40c113f2a9 Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-edgar-7287.167.B TEST=rebuild firmware, deploy to remote edgar, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368584 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/18403a336e5aff4a3c0b4e8ec3c14d40c113f2a9/src/soc/intel/braswell/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/d1bd5871a1724713f4ca071b04cddbc8b613b608 commit d1bd5871a1724713f4ca071b04cddbc8b613b608 Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-reks-7287.133.B TEST=rebuild firmware, deploy to remote reks, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368582 Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/d1bd5871a1724713f4ca071b04cddbc8b613b608/src/soc/intel/braswell/northcluster.c
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/05ce2f916888156c432f46b19f6b25867a6ecaa5 commit 05ce2f916888156c432f46b19f6b25867a6ecaa5 Author: Harry Pan <harry.pan@intel.com> Date: Thu Aug 11 06:35:04 2016 Braswell: fix ACPI table by recollecting TOLM On Braswell and Baytrail devices, by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BSW (and BYT) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-terra-7287.154.B TEST=rebuild firmware, deploy to remote terra, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: Iad4ffa542b22073cb087100a95169e2d2a52efcd Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368583 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Huki Huang <huki.huang@intel.com> [modify] https://crrev.com/05ce2f916888156c432f46b19f6b25867a6ecaa5/src/soc/intel/braswell/northcluster.c
,
Sep 12 2016
can chromium-os-dev help to proceed verification?
,
Dec 16 2016
Recent CWP data indicates: [cyan] fixed as of M53, [edgar, relm, terra] fixed as of M54, [reks, setzer] fixed (based on preliminary data) as of M55, [banon, celes, ultima, wizpig] not yet fixed. My understanding is that firmware updates are purposefully a "long and drawn-out process" to ensure stability, so it may be that no further action is required. Huge thanks to Harry Pan for pushing this through.
,
Feb 17 2017
,
Mar 18 2017
Activating. Please assign to the right owner and the appropriate priority.
,
Mar 21 2017
,
Apr 12 2017
I'd like to revisit the earlier discussion on why celes is using hpet. Following the terminology of #c59, condition A (the caching issue) has been fixed as of M56. The fraction of all cycles on Celes spent in vdso_ functions went from ~8.5% to ~5.5%. For comparison, the other boards that have had condition A fixed went from ~3.5% to ~0.5%. Thus it seems that fixing condition B (use of hpet instead of tsc) on Celes could save ~5% of its cycles fleet-wide. Regarding the request for dmesg output on Celes in #c122, I get similar results as in #c105, namely: $ dmesg | grep -i tsc [ 0.000000] Initial TSC value: 10618433940 [ 0.000000] tsc: Detected 1600.000 MHz processor [ 0.038998] TSC deadline timer enabled [ 0.076552] TSC synchronization [CPU#0 -> CPU#1]: [ 0.076555] Measured 26219440 cycles TSC warp between CPUs, turning off TSC clock. [ 0.076562] tsc: Marking TSC unstable due to check_tsc_sync_source failed
,
Apr 13 2017
I thought I was the only one reproduced that odd during tinkering then classified as a false alarm because I was unable to reproduce for the unknown reason. I will grab a celes to review this TSC lost. Would you mind to share your testee OS/FW to align w/? Any test method to trigger TSC lost from your ken? (It apparently not like a FW regression as my wrong justification)
,
Apr 13 2017
Turn out I can reproduce it easily using latest FW and R56 OS. Naively append tsc=reliable to kernel command line I could get around this odd: i.e. localhost ~ # dmesg | grep -i tsc [ 0.000000] Kernel command line: cros_secure cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=63421d7f-5b0d-4345-b2fc-dab85001b8fe/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none ro 1,0 3584000 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3584000 alg=sha1 root_hexdigest=e73cac5107bd1c8b0bb66923e99a779331490579 salt=d029894f11cc97136d37621b27f1dffb7210c81780ac70b3476591334fe8b5a3" noinitrd cros_debug vt.global_cursor_default=0 kern_guid=63421d7f-5b0d-4345-b2fc-dab85001b8fe add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic tsc=reliable [ 0.000000] Initial TSC value: 9939867480 [ 0.000000] tsc: Detected 1600.000 MHz processor [ 0.042000] TSC deadline timer enabled [ 0.077570] Skipped synchronization checks as TSC is reliable. [ 1.274630] Switched to clocksource tsc I suspect Andy Lutomirski's work at 2015-06-25 promising. alternately, suspect some OS versions between pop this up.
,
Apr 13 2017
read_hpet accounts for ~3% of all cycles on Celes, starting from R47 stable and continuing through R57 stable. read_hpet is 0% on all other Airmont boards, so we can conclude they are correctly using tsc. The Celes I ran dmesg on is on R59 dev, platform version 9449.0.0. Can you link to the commit mentioned in #c149? The data suggests this was not a regression that occurred after this board became generally available, but perhaps it was a regression during development.
,
Apr 16 2017
I was reading and guessing these series on upstream, derived from the broken story below: https://lkml.org/lkml/2013/12/27/249 I backported them locally in quick and hacky, while it did not work my celes. Initial guess: (not working) linux$ git log --pretty=format:'%h %ad %<(16)%an %d %s' --since=2015-06-25 --date=short --author="Andy Lutomirski" arch/x86/kernel/tsc* 27c6340 2015-06-25 Andy Lutomirski x86/asm/tsc: Use rdtsc_ordered() in read_tsc() instead of get_cycles() eee6946 2015-06-25 Andy Lutomirski x86/asm/tsc/sync: Use rdtsc_ordered() in check_tsc_warp() and drop extra barriers 4ea1636 2015-06-25 Andy Lutomirski x86/asm/tsc: Rename native_read_tsc() to rdtsc() 87be28a 2015-06-25 Andy Lutomirski x86/asm/tsc: Replace rdtscll() with native_read_tsc() c6e5ca3 2015-06-25 Andy Lutomirski x86/asm/tsc: Inline native_read_tsc() and remove __native_read_tsc() Boldly I switched my branch to chromeos-v4.4, despite it did not boot successfully, via VT2 I had short period to examine it did not work as well. Considering your input: > read_hpet is 0% on all other Airmont boards This suggests the odd is on celes only, perhaps on firmware? I originally sensed it on firmware bisecting as well. Therefore, I bisected FW listed below, non of them worked, all falled into hpet. 7287.92.86 7287.92.76 7287.92.60 7287.92.45 <- this is before TOLM fix, still falled into hpet on my handy celes Started over again, this time w/ OS switching, evaluated OS of R47-7520.48.0 stable on FW 7287.92.86, it is not working. Can we have some statistic review in terms of these? - Is this odd only on celes? - In case yes, are all celes affected? Note: I have one celes handy, and it is not same machine when last year I dealt w/ this issue.
,
Apr 16 2017
Addendum: Measured the avg. cost of clock_gettime() w/ hacking of tsc=reliable: 48~50 ns in 10^9 loops And there is another topic equivalent to command line hacking, yet I don't think it is right until realizing the cause. https://chromium-review.googlesource.com/#/q/topic:tsc_reliable
,
Apr 17 2017
Note of my celes cpu, stepping, and microcode; heading to spot other celes. localhost ~ # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 76 Model name: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz Stepping: 3 CPU MHz: 2046.056 CPU max MHz: 2249.1001 CPU min MHz: 499.8000 BogoMIPS: 3200.00 Virtualization: VT-x L1d cache: 24K L1i cache: 32K L2 cache: 1024K Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms localhost ~ # dmesg | grep micro [ 0.259270] microcode: CPU0 sig=0x406c3, pf=0x1, revision=0x35f [ 0.277721] microcode: CPU1 sig=0x406c3, pf=0x1, revision=0x35f [ 0.259382] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
,
Apr 17 2017
Regarding the questions in #c151: > Can we have some statistic review in terms of these? > - Is this odd only on celes? > - In case yes, are all celes affected? Yes to all. Sorry if this was not clear in #c150, but the percentage numbers I have stated are from ChromeOS-wide-profiling, rather than a single test device. That is, the underlying data is aggregated from millions of `perf record` invocations across many users and over many weeks. So to your second question, yes, out of all boards using Airmont micro-architecture, only Celes calls read_hpet with non-negligible frequency. To your third question, since __vdso_clock_gettime and read_hpet consumes ~8% (!) of all sampled CPU cycles on Celes, it cannot be limited to just a few misbehaving machines. We can also look at the percentiles of (the percent of cycles spent in these two functions per `perf record` session). If say, less than half of the Celes fleet had this issue, we would expect the 50%-ile to show 0% of samples in these two functions. The actual data for R56 shows: 1%-ile: 2% 2%-ile: 4% 10%-ile: 5% 50%-ile: 9% The fact that this is non-zero at such low percentiles strongly suggests that every Celes is affected.
,
Apr 18 2017
Rephrase the issue from 'TSC lost' to 'TSC warp'.
Presuming the FW is fixed (recollecting TOLM) in testee, if the clocksource is tsc, each clock_gettime() cost is around 50ns.
While if testee sensed TSC warped, switched the clocksource to HPET, I saw each clock_gettime() cost increased to 1700+ ns.
Did breadth search, yet unable to find any FW/OS combination that can avoid TSC warp. (i.e. all reproducible on my celes)
- FW was down to celes.7287.92.20. (some older FW on CPFE becomes un-reachible from my ken)
- OS wad down to R47-7520.42.0 dev channel (note this was mostly done by USB key rather than installed)
- Consider the BSW boards, I did:
* Evaluated two C stepping (celes) boards, aka. N3050, both were reproducible
* Evaluated one D stepping (celes) board, aka. N3060, it was reproducible
* Asked my collague to grep syslog (/var/log/messages) of his various of BSW projects storage, it looked to me the odd is only on celes so far
Did depth search, dived into the check_tsc_warp() function of tsc_sync.c
- The TSC warp looked to me one time only because of accessing incorrect last_tsc variable updated by another CPU
* The first CPU executed one loop, exited critical section
* The second CPU was in and finisied check, updated last_tsc,
* The first CPU reffered last_tsc updated by the second CPU in next round, judged as warp, one time only
- The detection algo. looks susceptible, if I added more printk message, the warp was gone
Caveat that because of Heisenbug debug principle, I am unable to claim this observation (of codes inserted) is true for problem approaching.
Addendum of my hacking:
$ git diff
diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c
index 2648848..399f5c0 100644
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -54,7 +54,7 @@ static void check_tsc_warp(unsigned int timeout)
*/
end = start + (cycles_t) tsc_khz * timeout;
now = start;
-
+ //printk("HP: tout=%u\n", timeout); <- 3
for (i = 0; ; i++) {
/*
* We take the global lock, measure TSC, save the
@@ -68,7 +68,8 @@ static void check_tsc_warp(unsigned int timeout)
rdtsc_barrier();
last_tsc = now;
arch_spin_unlock(&sync_lock);
-
+ //printk("HP: %d: %d: %llu %llu\n", smp_processor_id(), i, prev, now); <- 1
+ printk("HP: %d: %d: %d\n", smp_processor_id(), i, (prev < now)? 1: -1); <- 2
Read the 1, 2, 3 (of my graph states) as:
Either 1 and 2 I saw problem remained, adding 3 on top of 1 or 2 I saw issue gone
1:
[ 0.060563] .... node #0, CPUs: #1HP: 0: 0: 0: 24427473680
[ 0.114280] HP: 1: 0: 24427473680: 24487106120
[ 0.114285] HP: 1: 1: 24487106120: 24487121920
...snip
[ 0.116296] HP: 1: 704: 24490336520: 24490341040 <- last_tsc
[ 0.079022] HP: 0: 1: 24490341040: 24430704520 <- one time warp
[ 0.079025] HP: 0: 2: 24430704520: 24430709740
...snip
2:
[ 0.060582] .... node #0, CPUs: #1HP: 0: 0: 1
[ 0.114300] HP: 1: 0: 1
[ 0.114304] HP: 1: 1: 1
...snip
[ 0.116295] HP: 1: 832: 1
[ 0.079022] HP: 0: 1: -1
[ 0.079024] HP: 0: 2: 1
...snip
3: (on top of 1)
[ 0.058119] .... node #0, CPUs: #1HP: tout=2
[ 0.090996] HP: tout=2
[ 0.091001] HP: 1: 0: 0 10797421680
[ 0.091004] HP: 1: 1: 10797421680 10797428940
...snip
[ 0.116296] HP: 1: 704: 24490336520: 24490341040
[ 0.079022] HP: 0: 1: 24490341040: 24430704520
[ 0.079025] HP: 0: 2: 24430704520: 24430709740
...snip
[ 0.092998] HP: 1: 776: 10800616040 10800620080
[ 0.076564] HP: 0: 0: 10800620080 10774325120 <- (prev < now) == false
...snip
[ 2.263774] Switched to clocksource tsc
Sum up: so far it looks to me a false postive, yet I am unable to fully explain.
-Harry
,
Apr 21 2017
Continue #155, propose this topic for this upstream series, expecially this: https://marc.info/?l=linux-kernel&m=147956347822061 (commit a36f5136814b "x86/tsc: Sync test only for the first cpu in a package") Upstream 4.10: linux$ git log --pretty=format:'%h %ad %an %d %s' --date=short --abbrev=12 bec8520dca0d^..b836554386cc arch/x86/kernel/tsc_sync.c b836554386cc 2016-11-29 Thomas Gleixner x86/tsc: Fix broken CONFIG_X86_TSC=n build cc4db26899dc 2016-11-19 Thomas Gleixner x86/tsc: Try to adjust TSC if sync test fails 76d3b8515850 2016-11-19 Thomas Gleixner x86/tsc: Prepare warp test for TSC adjustment 4c5e3c637521 2016-11-19 Thomas Gleixner x86/tsc: Move sync cleanup to a safe place a36f5136814b 2016-11-19 Thomas Gleixner x86/tsc: Sync test only for the first cpu in a package 1d0095feea59 2016-11-19 Thomas Gleixner x86/tsc: Verify TSC_ADJUST from idle 8b223bc7abe0 2016-11-19 Thomas Gleixner x86/tsc: Store and check TSC ADJUST MSR bec8520dca0d 2016-11-19 Thomas Gleixner x86/tsc: Detect random warps Topic as: https://chromium-review.googlesource.com/#/q/topic:tsc_warp I evaluated two celes in C and D stepping, both looked fine, will ask more Airmont siblings to evaluate this series. # dmesg | grep -i tsc [ 0.000000] Initial TSC value: 10531764580 [ 0.000000] tsc: Detected 1600.000 MHz processor [ 0.000000] TSC ADJUST: Boot CPU0: 0 [ 0.039293] TSC deadline timer enabled [ 2.258932] Switched to clocksource tsc
,
May 12 2017
Question: Shall we fix the 1st issue (condition A) for all rambi descendant? (as I saw cros-dev tending to go for chromeos-v4.4 for BYT) i.e. coreboot$ git branch -a | grep -e firmware-banjo -e firmware-candi -e firmware-clapper -e firmware-enguarde -e firmware-glimmer -e firmware-gnawty -e firmware-heli -e firmware-kip -e firmware-ninja -e firmware-orco -e firmware-quawks -e firmware-squawks -e firmware-sumo -e firmware-swanky -e firmware-winky remotes/cros/firmware-banjo-5216.334.B remotes/cros/firmware-clapper-5216.199.B remotes/cros/firmware-clapper-5218.B remotes/cros/firmware-enguarde-5216.201.B remotes/cros/firmware-glimmer-5216.198.B remotes/cros/firmware-glimmer-5217.B remotes/cros/firmware-gnawty-5216.239.B remotes/cros/firmware-heli-5216.392.B remotes/cros/firmware-kip-5216.227.B remotes/cros/firmware-ninja-5216.383.B remotes/cros/firmware-orco-5216.362.B remotes/cros/firmware-quawks-5216.204.B remotes/cros/firmware-squawks-5216.152.B remotes/cros/firmware-sumo-5216.382.B remotes/cros/firmware-swanky-5216.238.B remotes/cros/firmware-winky-5216.1.B remotes/cros/firmware-winky-5216.265.B
,
May 12 2017
Sure.
,
May 12 2017
Is there reason to suspect those boards are also affected? Those boards are on Silvermont uarch, and CWP data indicates they are unaffected by Condition A. Namely, as of M56, on average those boards spend < 0.5% of all cycles in VDSO functions.
,
May 18 2017
For BYT: https://chromium-review.googlesource.com/#/q/topic:byt_tolm_fixup - The problem is on chromeos-v3.18 or chromeos-v4.4, while readers can examine /proc/iomem problem even in chromeos-v3.10, refer to the note. - Not enough devices to perform fully validation - Validated on 4 DUTs (5 branches) w/ clock_gettime() average access time, as well as /proc/iomem hierarchy - Noticed high percentage in "mwait_idle_with_hints.constprop.2" (on chromeos-v4.4 by perf top), this is different when I used chromeos-v3.18 branch note: in case RAM(s) are not located in root's sibling, kernel (>3.16) will allocate a non-cacheable page of vdso, that causes penalty (memory hierarchy). bad: localhost ~ # grep RAM /proc/iomem 00001000-0009ffff : System RAM 00100000-1fffffff : System RAM 20100000-7ae6dfff : System RAM 100000000-17fffffff : System RAM good: localhost ~ # grep RAM /proc/iomem 00001000-0009ffff : System RAM 00100000-1fffffff : System RAM 20100000-7ae6dfff : System RAM 100000000-17fffffff : System RAM
,
May 18 2017
Thanks for noticing the issue on BYT. I can confirm the issue appears as a ~3% regression for BYT boards since the M58 release.
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/568b327e9dd33ef6e1f35320c5bf063a4e3c03d1 commit 568b327e9dd33ef6e1f35320c5bf063a4e3c03d1 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 04:38:30 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-winky-5216.265.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506288 [modify] https://crrev.com/568b327e9dd33ef6e1f35320c5bf063a4e3c03d1/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/ac7bb9082f8a565e2e1a0644d8e64f341bcba2f2 commit ac7bb9082f8a565e2e1a0644d8e64f341bcba2f2 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 04:38:33 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-winky-5216.265.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506289 [modify] https://crrev.com/ac7bb9082f8a565e2e1a0644d8e64f341bcba2f2/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/4933fdd1436fdf8e8476fb15cc769614063b2027 commit 4933fdd1436fdf8e8476fb15cc769614063b2027 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 04:38:36 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-gnawty-5216.239.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505223 [modify] https://crrev.com/4933fdd1436fdf8e8476fb15cc769614063b2027/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/ce3bb62326fca017c21bc15a960dea287a4dcf82 commit ce3bb62326fca017c21bc15a960dea287a4dcf82 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 04:38:37 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-gnawty-5216.239.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505224 [modify] https://crrev.com/ce3bb62326fca017c21bc15a960dea287a4dcf82/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/6cf9f785aaa143ca1709c05954966feffc70e4c2 commit 6cf9f785aaa143ca1709c05954966feffc70e4c2 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 04:38:39 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-winky-5216.1.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505932 [modify] https://crrev.com/6cf9f785aaa143ca1709c05954966feffc70e4c2/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/8ec116e8b5aa3497e37e8c048fe2319612a748be commit 8ec116e8b5aa3497e37e8c048fe2319612a748be Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 04:38:41 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-quawks-5216.204.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506233 [modify] https://crrev.com/8ec116e8b5aa3497e37e8c048fe2319612a748be/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/28b42792a6f2e0044310ef3ccf68ac492bd0a915 commit 28b42792a6f2e0044310ef3ccf68ac492bd0a915 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 04:38:43 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-winky-5216.1.B TEST=rebuild firmware, deploy to remote rambi w/ 3.18 kernel, then perform 'perf top' to profile __vdso_clock_gettime() cost; also do 'cat /proc/iomem' examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505933 [modify] https://crrev.com/28b42792a6f2e0044310ef3ccf68ac492bd0a915/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/429536b053e214ede76afa65a3aefb7584e64892 commit 429536b053e214ede76afa65a3aefb7584e64892 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 04:38:45 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-quawks-5216.204.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506234 [modify] https://crrev.com/429536b053e214ede76afa65a3aefb7584e64892/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/f646a5ac4fb20553f58ad91e08a1aac35a514d26 commit f646a5ac4fb20553f58ad91e08a1aac35a514d26 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 04:41:04 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-swanky-5216.238.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505910 [modify] https://crrev.com/f646a5ac4fb20553f58ad91e08a1aac35a514d26/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/7972cdd3e7c707655b710664f7967b5136f8f820 commit 7972cdd3e7c707655b710664f7967b5136f8f820 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 04:41:07 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-swanky-5216.238.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505911 [modify] https://crrev.com/7972cdd3e7c707655b710664f7967b5136f8f820/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/1583cf13f032e7a008086059fa28f694060dd17b commit 1583cf13f032e7a008086059fa28f694060dd17b Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 17:20:47 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-glimmer-5217.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506237 [modify] https://crrev.com/1583cf13f032e7a008086059fa28f694060dd17b/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/0f948753cff6c3f4a33f31da2ad4f5ca92d68c95 commit 0f948753cff6c3f4a33f31da2ad4f5ca92d68c95 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 17:20:50 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-glimmer-5217.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506238 [modify] https://crrev.com/0f948753cff6c3f4a33f31da2ad4f5ca92d68c95/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/75f55ed4371c5ce1fa2b8ddfa22c7d60fa55f559 commit 75f55ed4371c5ce1fa2b8ddfa22c7d60fa55f559 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 17:20:53 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-glimmer-5216.198.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506235 [modify] https://crrev.com/75f55ed4371c5ce1fa2b8ddfa22c7d60fa55f559/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/cad686de3c88049b1b4e9678f0b1aa7c028c079a commit cad686de3c88049b1b4e9678f0b1aa7c028c079a Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 17:20:55 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-glimmer-5216.198.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506236 [modify] https://crrev.com/cad686de3c88049b1b4e9678f0b1aa7c028c079a/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/e7e14b3f7a2942cb08b6a8f9cbefea0ad21a0e1f commit e7e14b3f7a2942cb08b6a8f9cbefea0ad21a0e1f Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 17:41:10 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-clapper-5218.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506030 [modify] https://crrev.com/e7e14b3f7a2942cb08b6a8f9cbefea0ad21a0e1f/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/c8566496eed26abfbec41a8bfd20f7cc359d766a commit c8566496eed26abfbec41a8bfd20f7cc359d766a Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sat May 20 17:41:14 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-clapper-5216.199.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505908 [modify] https://crrev.com/c8566496eed26abfbec41a8bfd20f7cc359d766a/src/include/stddef.h
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/4d8a99a8372f428bfbcc270e5f50888123b3ab1b commit 4d8a99a8372f428bfbcc270e5f50888123b3ab1b Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 17:41:16 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-clapper-5216.199.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505909 [modify] https://crrev.com/4d8a99a8372f428bfbcc270e5f50888123b3ab1b/src/soc/intel/baytrail/northcluster.c
,
May 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/2331949f3568d7ef987519cd7eaa14dda7f7b580 commit 2331949f3568d7ef987519cd7eaa14dda7f7b580 Author: Harry Pan <harry.pan@intel.com> Date: Sat May 20 17:41:18 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-clapper-5218.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506031 [modify] https://crrev.com/2331949f3568d7ef987519cd7eaa14dda7f7b580/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/4654b2b1c22796ea819210cbf6b05c1250a31956 commit 4654b2b1c22796ea819210cbf6b05c1250a31956 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 01:50:23 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-heli-5216.392.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505936 [modify] https://crrev.com/4654b2b1c22796ea819210cbf6b05c1250a31956/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/8959d99823394225db985e6b9fcc523003ab8043 commit 8959d99823394225db985e6b9fcc523003ab8043 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 01:50:26 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-heli-5216.392.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505937 [modify] https://crrev.com/8959d99823394225db985e6b9fcc523003ab8043/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/e1e52ac21c3e95e4a518928098e4065c6ad34406 commit e1e52ac21c3e95e4a518928098e4065c6ad34406 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 01:50:32 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-ninja-5216.383.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506290 [modify] https://crrev.com/e1e52ac21c3e95e4a518928098e4065c6ad34406/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/3ff11f1aff3c362f2c0decacbbece38321a6d5be commit 3ff11f1aff3c362f2c0decacbbece38321a6d5be Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 01:50:34 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-enguarde-5216.201.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505225 [modify] https://crrev.com/3ff11f1aff3c362f2c0decacbbece38321a6d5be/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/72750d1e55b69b4199631d54cb12cea5cf9442ff commit 72750d1e55b69b4199631d54cb12cea5cf9442ff Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 01:50:36 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-ninja-5216.383.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506291 [modify] https://crrev.com/72750d1e55b69b4199631d54cb12cea5cf9442ff/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/3099f6af71f8af9062ca17b2be7a4875dc79bcd7 commit 3099f6af71f8af9062ca17b2be7a4875dc79bcd7 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 01:50:38 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-enguarde-5216.201.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505226 [modify] https://crrev.com/3099f6af71f8af9062ca17b2be7a4875dc79bcd7/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/f1ebf35c9cd34e00dba938315c16d7337339c472 commit f1ebf35c9cd34e00dba938315c16d7337339c472 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 05:22:11 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-kip-5216.227.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505934 [modify] https://crrev.com/f1ebf35c9cd34e00dba938315c16d7337339c472/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/3d772b180501bbf5897d751b2265ea612e8ab791 commit 3d772b180501bbf5897d751b2265ea612e8ab791 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 05:22:14 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-kip-5216.227.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505935 [modify] https://crrev.com/3d772b180501bbf5897d751b2265ea612e8ab791/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/9f311dd31fd93110f0897474713555013ee725a6 commit 9f311dd31fd93110f0897474713555013ee725a6 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 05:22:16 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-orco-5216.362.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506050 [modify] https://crrev.com/9f311dd31fd93110f0897474713555013ee725a6/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/cc9be7866c135fb82688dbe86c5996efe3628443 commit cc9be7866c135fb82688dbe86c5996efe3628443 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 05:22:18 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-orco-5216.362.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506051 [modify] https://crrev.com/cc9be7866c135fb82688dbe86c5996efe3628443/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/7c67b4448e5e42c8fc02a87c1b9c80786901e119 commit 7c67b4448e5e42c8fc02a87c1b9c80786901e119 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 07:11:24 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-sumo-5216.382.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506270 [modify] https://crrev.com/7c67b4448e5e42c8fc02a87c1b9c80786901e119/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/b25ad9fdf3eda0a6cd92cc7db0cb2fb3fa784636 commit b25ad9fdf3eda0a6cd92cc7db0cb2fb3fa784636 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 07:11:27 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-sumo-5216.382.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506271 [modify] https://crrev.com/b25ad9fdf3eda0a6cd92cc7db0cb2fb3fa784636/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/b2ac8cc7c276d842b6ca5137678cba32a2456947 commit b2ac8cc7c276d842b6ca5137678cba32a2456947 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 07:11:29 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-squawks-5216.152.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506114 [modify] https://crrev.com/b2ac8cc7c276d842b6ca5137678cba32a2456947/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/d95337903ac72cde15e92a72c9eb663770e019a5 commit d95337903ac72cde15e92a72c9eb663770e019a5 Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 07:11:36 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-squawks-5216.152.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506115 [modify] https://crrev.com/d95337903ac72cde15e92a72c9eb663770e019a5/src/soc/intel/baytrail/northcluster.c
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/bb39e383de61e1113a0ad0a4afd372062d0f4cf7 commit bb39e383de61e1113a0ad0a4afd372062d0f4cf7 Author: Wei Shun Chang <wei.shun.chang@intel.com> Date: Sun May 21 08:46:59 2017 Partially backport the MAYBE_STATIC macro from upstream This patch partially backports the macro of MAYBE_STATIC from the upstream for the next patch of ACPI table fixing. Suggested by Wei-Shun, commit message by Harry. BUG=chromium:611896 BRANCH=firmware-banjo-5216.334.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I6735f2090fbee2a88733ccc0b7b06cd785ac5249 Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/372403 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506112 [modify] https://crrev.com/bb39e383de61e1113a0ad0a4afd372062d0f4cf7/src/include/stddef.h
,
May 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/ef7210db11efa66cf0b4d93817c34338f58428ac commit ef7210db11efa66cf0b4d93817c34338f58428ac Author: Harry Pan <harry.pan@intel.com> Date: Sun May 21 08:47:06 2017 Baytrial: fix ACPI table by recollecting TOLM On Baytrail devices (w/ 3.18 kernel), by userland 'perf top', observed demanding clocks on __vdso_clock_gettime() since chromeos_3.18 kernel; besides, evaluated massive calling of clock_gettime() cost, up to 700 ns in average. It turns out that Linux kernel of map_vdso() first call of remap_pfn_range() does not fall into reserve_pfn_range() due to size parameter, instead it relies on lookup_memtype() and potentially be failed to be identified as eligible RAM resource because the function of pat_pagerange_is_ram() actually walks through root's sibling. Meanwhile, on current BYT (and BSW) firmware implementation makes System RAM resources located on child leaf, combining all of these factors makes the kernel treat the vvar page of vdso as a uncached-minus one leading slow access in result. This patch recollects TOLM accessing; as Aaron recalled some core_msr_script turns off access to TOLM register, he suggests to store tolm to avoid getting back a zero while setting acpi nvs space. BUG=chromium:611896 BRANCH=firmware-banjo-5216.334.B TEST=rebuild firmware, image it to BYT chrome device, do 'cat /proc/iomem' and examine System RAM in root's sibling. Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad Signed-off-by: Harry Pan <harry.pan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/368516 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/506113 [modify] https://crrev.com/ef7210db11efa66cf0b4d93817c34338f58428ac/src/soc/intel/baytrail/northcluster.c
,
Jul 4 2017
Continue #c147, I still see this odd on celes R61 images, while it does not occur on terra.
,
Jul 6 2017
You had mentioned https://chromium-review.googlesource.com/q/topic:tsc_warp in c156. IIUC, that set of CLs would need to land for condition B to be fixed on Celes.
,
Jul 7 2017
Re #c197, I rebased this topic branch today. https://chromium-review.googlesource.com/q/topic:tsc_warp BTW, an open question, is there chromium-os autotest cover such odd?
,
Jul 7 2017
And, there is enigma I couldn't figure out why I only see race on celes which causes TSC warp.
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2404a94b2d994722f83515ea49b6aab6fa0b330e commit 2404a94b2d994722f83515ea49b6aab6fa0b330e Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:46 2017 UPSTREAM: x86/tsc: Detect random warps If time warps can be observed then they should only ever be observed on one CPU. If they are observed on both CPUs then the system is completely hosed. Add a check for this condition and notify if it happens. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.574838461@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit bec8520dca0d27c1ddac703f9d0a78275ca2603e) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: Icddf9c5dc0b025e3ae47dc113601d929232410e9 Reviewed-on: https://chromium-review.googlesource.com/484242 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/2404a94b2d994722f83515ea49b6aab6fa0b330e/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d55c703656469b8f93eff4b5139f92e76c8e7381 commit d55c703656469b8f93eff4b5139f92e76c8e7381 Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:47 2017 UPSTREAM: x86/tsc: Store and check TSC ADJUST MSR The TSC_ADJUST MSR shows whether the TSC has been modified. This is helpful in a two aspects: 1) It allows to detect BIOS wreckage, where SMM code tries to 'hide' the cycles spent by storing the TSC value at SMM entry and restoring it at SMM exit. On affected machines the TSCs run slowly out of sync up to the point where the clocksource watchdog (if available) detects it. The TSC_ADJUST MSR allows to detect the TSC modification before that and eventually restore it. This is also important for SoCs which have no watchdog clocksource and therefore TSC wreckage cannot be detected and acted upon. 2) All threads in a package are required to have the same TSC_ADJUST value. Broken BIOSes break that and as a result the TSC synchronization check fails. The TSC_ADJUST MSR allows to detect the deviation when a CPU comes online. If detected set it to the value of an already online CPU in the same package. This also allows to reduce the number of sync tests because with that in place the test is only required for the first CPU in a package. In principle all CPUs in a system should have the same TSC_ADJUST value even across packages, but with physical CPU hotplug this assumption is not true because the TSC starts with power on, so physical hotplug has to do some trickery to bring the TSC into sync with already running packages, which requires to use an TSC_ADJUST value different from CPUs which got powered earlier. A final enhancement is the opportunity to compensate for unsynced TSCs accross nodes at boot time and make the TSC usable that way. It won't help for TSCs which run apart due to frequency skew between packages, but this gets detected by the clocksource watchdog later. The first step toward this is to store the TSC_ADJUST value of a starting CPU and compare it with the value of an already online CPU in the same package. If they differ, emit a warning and adjust it to the reference value. The !SMP version just stores the boot value for later verification. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.655323776@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 8b223bc7abe0e30e8d297a24ee6c6c07ef8d0bb9) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: I5b0934d1e0ed172bf8c871e0284d88b809b032c9 Reviewed-on: https://chromium-review.googlesource.com/484243 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Chong Jiang <chongjiang@chromium.org> [modify] https://crrev.com/d55c703656469b8f93eff4b5139f92e76c8e7381/arch/x86/kernel/Makefile [modify] https://crrev.com/d55c703656469b8f93eff4b5139f92e76c8e7381/arch/x86/include/asm/tsc.h [modify] https://crrev.com/d55c703656469b8f93eff4b5139f92e76c8e7381/arch/x86/kernel/tsc.c [modify] https://crrev.com/d55c703656469b8f93eff4b5139f92e76c8e7381/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c310ae4ff41dd0d70b2006b805f0e8965fb828e3 commit c310ae4ff41dd0d70b2006b805f0e8965fb828e3 Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:48 2017 UPSTREAM: x86/tsc: Verify TSC_ADJUST from idle When entering idle, it's a good oportunity to verify that the TSC_ADJUST MSR has not been tampered with (BIOS hiding SMM cycles). If tampering is detected, emit a warning and restore it to the previous value. This is especially important for machines, which mark the TSC reliable because there is no watchdog clocksource available (SoCs). This is not sufficient for HPC (NOHZ_FULL) situations where a CPU never goes idle, but adding a timer to do the check periodically is not an option either. On a machine, which has this issue, the check triggeres right during boot, so there is a decent chance that the sysadmin will notice. Rate limit the check to once per second and warn only once per cpu. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.732180441@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 1d0095feea591bbd94f35d8a98aed746319783e1) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: I5b20b56820b80994bec7fad96eaf3de37f14c097 Reviewed-on: https://chromium-review.googlesource.com/484244 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/c310ae4ff41dd0d70b2006b805f0e8965fb828e3/arch/x86/include/asm/tsc.h [modify] https://crrev.com/c310ae4ff41dd0d70b2006b805f0e8965fb828e3/arch/x86/kernel/tsc_sync.c [modify] https://crrev.com/c310ae4ff41dd0d70b2006b805f0e8965fb828e3/arch/x86/kernel/process.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/60430a2c83f44829378f5db0303b3b7170fbf048 commit 60430a2c83f44829378f5db0303b3b7170fbf048 Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:49 2017 UPSTREAM: x86/tsc: Sync test only for the first cpu in a package If the TSC_ADJUST MSR is available all CPUs in a package are forced to the same value. So TSCs cannot be out of sync when the first CPU in the package was in sync. That allows to skip the sync test for all CPUs except the first starting CPU in a package. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.809901363@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit a36f5136814b6a87601220927cb9ad9ecc731e92) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: Iecc8b7e0cc8ef8f86be57889316f259f29bdd08f Reviewed-on: https://chromium-review.googlesource.com/484245 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/60430a2c83f44829378f5db0303b3b7170fbf048/arch/x86/include/asm/tsc.h [modify] https://crrev.com/60430a2c83f44829378f5db0303b3b7170fbf048/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8853c27048f9b6d45a57a288af8c724c20f4c5cc commit 8853c27048f9b6d45a57a288af8c724c20f4c5cc Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:50 2017 UPSTREAM: x86/tsc: Move sync cleanup to a safe place Cleaning up the stop marker on the control CPU is wrong when we want to add retry support. Move the cleanup to the starting CPU. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.892095627@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 4c5e3c63752162262c42424147f319b8571a20af) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: If09cfbd346d8be3062fbd973d0bd8ba3d7b7ba27 Reviewed-on: https://chromium-review.googlesource.com/484246 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/8853c27048f9b6d45a57a288af8c724c20f4c5cc/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6d6fdb643f8d210a2ae32970bda0503cf432fd18 commit 6d6fdb643f8d210a2ae32970bda0503cf432fd18 Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:51 2017 UPSTREAM: x86/tsc: Prepare warp test for TSC adjustment To allow TSC compensation cross nodes its necessary to know in which direction the TSC warp was observed. Return the maximum observed value on the calling CPU so the caller can determine the direction later. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134017.970859287@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 76d3b85158509cafec5be7675a97ef80118e288e) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: I468ef53bfa2ca889814d134e3d08d9416adeb8d2 Reviewed-on: https://chromium-review.googlesource.com/484247 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/6d6fdb643f8d210a2ae32970bda0503cf432fd18/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/836c5beb717c44374afb83d5f099c5e6dede241f commit 836c5beb717c44374afb83d5f099c5e6dede241f Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:52 2017 UPSTREAM: x86/tsc: Try to adjust TSC if sync test fails If the first CPU of a package comes online, it is necessary to test whether the TSC is in sync with a CPU on some other package. When a deviation is observed (time going backwards between the two CPUs) the TSC is marked unstable, which is a problem on large machines as they have to fall back to the HPET clocksource, which is insanely slow. It has been attempted to compensate the TSC by adding the offset to the TSC and writing it back some time ago, but this never was merged because it did not turn out to be stable, especially not on older systems. Modern systems have become more stable in that regard and the TSC_ADJUST MSR allows us to compensate for the time deviation in a sane way. If it's available allow up to three synchronization runs and if a time warp is detected the starting CPU can compensate the time warp via the TSC_ADJUST MSR and retry. If the third run still shows a deviation or when random time warps are detected the test terminally fails. BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/20161119134018.048237517@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit cc4db26899dcd0e6ff0448c77abd8eb61b1a1333) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: I231f2108409cc21155a34baf03d7db5de89826ec Reviewed-on: https://chromium-review.googlesource.com/484248 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/836c5beb717c44374afb83d5f099c5e6dede241f/arch/x86/kernel/tsc_sync.c
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/13c88d45b1a74d813ea918afc9a7c041319490ec commit 13c88d45b1a74d813ea918afc9a7c041319490ec Author: Thomas Gleixner <tglx@linutronix.de> Date: Fri Jul 14 02:45:53 2017 UPSTREAM: x86/tsc: Fix broken CONFIG_X86_TSC=n build Add the missing return statement to the inline stub tsc_store_and_check_tsc_adjust() and add the other stubs to make a SMP=y,TSC=n build happy. While at it, remove the unused variable from the UP variant of tsc_store_and_check_tsc_adjust(). BUG=chromium:611896 TEST=do 'dmesg | grep -i tsc' on DUT, examine TSC is the clocksource, i.e. no tsc warp. Fixes: commit ba75fb646931 ("x86/tsc: Sync test only for the first cpu in a package") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit b836554386cc77f31ab43a8492a2587e0c51d51e) Signed-off-by: Harry Pan <harry.pan@intel.com> Change-Id: Ibbac1c4443c587cef675c56bcd69f112cc57c13c Reviewed-on: https://chromium-review.googlesource.com/484249 Commit-Ready: Harry Pan <harry.pan@intel.com> Tested-by: Harry Pan <harry.pan@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [modify] https://crrev.com/13c88d45b1a74d813ea918afc9a7c041319490ec/arch/x86/include/asm/tsc.h [modify] https://crrev.com/13c88d45b1a74d813ea918afc9a7c041319490ec/arch/x86/kernel/tsc_sync.c
,
Sep 5 2017
I am seeing a weird situation says the celes's naughty TSC is broken again after booted a while. (OS: R62-9841) localhost ~ # dmesg | grep -i TSC [ 0.000000] Initial TSC value: 9929579700 [ 0.000000] tsc: Detected 1600.000 MHz processor [ 0.000000] TSC ADJUST: Boot CPU0: 0 [ 0.042441] TSC deadline timer enabled [ 2.276556] Switched to clocksource tsc [ 237.689771] Clocksource tsc unstable (delta = -64790892 ns) localhost ~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet
,
Sep 6 2017
I was unable to repro that on my celes device (R62-9887.0.0) after 1.5 hours. Can you share any additional steps, or confirm that it repros reliably for you?
,
Sep 6 2017
I was able to repro it on both of my two Celes (N3050 and N3060) while I was dealing w/ b:64552189 Probably it is relative to non-guest login: By observation, I do not see TSC unstable event before login as well as guest login. However, I could see the TSC unstable event once I login w/ my gmail account and wait a while, after then it switches to hpet. An example that I was monitoring device thro remote ssh: localhost ~ # dmesg | grep -i -e tsc -e hpet [ 0.000000] ACPI: HPET 0x000000007CD2E7A0 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] hpet clockevent registered [ 0.000000] Initial TSC value: 10214122060 [ 0.000000] tsc: Detected 1600.000 MHz processor [ 0.000000] TSC ADJUST: Boot CPU0: 0 [ 0.042508] TSC deadline timer enabled [ 0.095164] Switched to clocksource hpet [ 0.206594] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.206602] hpet0: 3 comparators, 64-bit 14.318180 MHz counter [ 0.624686] rtc_cmos 00:03: alarms up to one month, 242 bytes nvram, hpet irqs [ 2.279893] Switched to clocksource tsc localhost ~ # tail -f /var/log/messages | grep -i -e tsc -e hpet 2017-09-06T12:56:37.423235+08:00 WARNING kernel: [ 266.693654] Clocksource tsc unstable (delta = -63476062 ns) 2017-09-06T12:56:37.364788+08:00 INFO kernel: [ 266.698920] Switched to clocksource hpet These two lines above appeared until my gmail login.
,
Sep 6 2017
This time I waited more than one hour to login my gmail account: localhost ~ # tail -f /var/log/messages | grep -i -e tsc -e hpet 2017-09-06T14:10:50.956084+08:00 WARNING kernel: [ 4375.706876] Clocksource tsc unstable (delta = -64630576 ns) 2017-09-06T14:10:50.957329+08:00 INFO kernel: [ 4375.773373] Switched to clocksource hpet
,
Sep 15 2017
I found that keeping CPU busy would trigger "Clocksource tsc unstable" easily. You can just run the below script(as an example) on VT2,VT3,VT4 and wait less than 5 min, the problem should be triggered. #!/bin/bash i="1" while [ $i ] do echo $i i=$[$i+1] done
,
Sep 21 2017
The TSC unstable problem has been proven by Zhuo-hao and Kane that it is caused by CL:*238419 ("Celes: enable DDR SSC"), I also manually verified again, the mistake I made was it has to image by servo board, rather than flashrom tool.
,
Aug 1
Showing comments 115 - 214
of 214
Older ›
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
