kernel_Delay test failing on elm/hana/oak |
|||
Issue descriptionChrome Version: (copy from chrome://version) OS: (e.g. Win7, OSX 10.9.5, etc...) What steps will reproduce the problem? (1) test_that -b oak DUT kernel_Delay What is the expected result? Test passes. What happens instead? Test fails with: setspeed changed from 1703000 to 1807000 The test set the userspace governor and speed to 1703000, runs the udelay_test, and at the end of the test verifies that the CPU speed wasn't changed. For elm/hana/oak, it looks like the CPU speed is being changes to 1807000 during the test. https://wmatrix.googleplex.com/failures/kernel?tests=kernel_Delay Please use labels and text to provide additional information. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Feb 22 2017
Slightly better wmatrix link: https://wmatrix.googleplex.com/kernel?platforms=elm%2Chana%2Coak&tests=kernel_Delay&days_back=100 This does not appears to be a regression (the test started running only after November 13, for some reason, and never passed).
,
Feb 22 2017
Yeah, I'm not sure if it ever worked on elm. I don't have an elm available, djkurtz said one of you guys might be able to quickly check the test and see why the speed is being changed from what it was set to and see if there is anything obviously wrong?
,
Feb 23 2017
I had a very cursory look. The test assumes that all cores can scale to the same set of frequencies, which is not true on big-little SoC like MT8173 (oak/elm) or RK3399 (gru/kevin, but the test does no run on gru/kevin as they use a 4.4 kernel and there seems to be other issues).
Test does this:
CPUFREQ_AVAIL_FREQS_PATH = (
'/sys/devices/system/cpu/cpu0/cpufreq/'
'scaling_available_frequencies')
But this isn't the right thing to do:
# grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:507000 702000 1001000 1105000 1209000 1300000 1508000 1703000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies:507000 702000 1001000 1105000 1209000 1300000 1508000 1703000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_available_frequencies:507000 702000 1001000 1209000 1404000 1612000 1807000 2106000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_frequencies:507000 702000 1001000 1209000 1404000 1612000 1807000 2106000
I assume the test tries to use 1703000 on one of the big cores (2/3), and is then surprised when that does not work.
,
Feb 23 2017
The 4.4 issue is due to the kernel module being rename upstream. https://chromium-review.googlesource.com/c/446036/ is a fix for that. Yeah, the test currently assumes that the same frequency will work on all cores. Thanks for taking a cursory look.
,
Mar 7 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by davidri...@chromium.org
, Feb 21 2017