Merge into trunk : fix_1303694 : Code : Checkbox

Reviewer	Date Requested	Status
Jeff Lane 	2014-04-07	Approve on 2014-04-07
Brendan Donegan (community)	2014-04-07	Approve on 2014-04-07
Review via email: mp+214509@code.launchpad.net

Revision history for this message

Brendan Donegan (brendan-donegan) wrote on 2014-04-07:

#

I approve. Let's see what Jeff says

review: Approve

Revision history for this message

Jeff Lane  (bladernr) wrote on 2014-04-07:

#

Download full text (13.9 KiB)

I'm fine with this change of tests and thanks for also editing the server whitelists as well :)

However, a couple things need to be addressed.

First, just to keep the same functionality, I'd prefer that a couple things were fixed:
line 215:
elif args.all:
tests.extend(['wakealarm', 'cpufreq'] + TESTS)

should include 'maxfreq'

However, that's a minor issue that shouldn't affect anything beyond using the --all option.

More importantly though, is why are we using maxfreq as opposed to cpufreq in fwts:

cpufreq CPU frequency scaling tests.
maxfreq Check max CPU frequencies against max scaling frequency.

As I understand it, maxfreq just does a quick check that what the CPU says about frequencies jives with what the kernel thinks it knows about them, while cpufreq actually changes frequencies and does cpu scale testing.

Here's sample output from my Core i5 Ivy Bridge based NUC:
Results generated by fwts: Version V14.03.01 (2014-03-27 02:14:17).

This test run on 07/04/14 at 10:20:53 on host Linux critical-maas
3.13.0-19-generic #40-Ubuntu SMP Mon Mar 24 02:36:06 UTC 2014 x86_64.

Command: "fwts maxfreq".
Running tests: maxfreq.

maxfreq: Test max CPU frequencies against max scaling frequency.
--------------------------------------------------------------------------------
Test 1 of 1: Maximum CPU frequency test.
This test checks the maximum CPU frequency as detected by the kernel for each
CPU against maxiumum frequency as specified by the BIOS frequency scaling
settings.
FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: The maximum scaling frequency 2.301000 GHz for CPU 0 configured by the
BIOS in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies does
not match the expected maximum CPU frequency 1.800000 GHz that the CPU can run
at. This usually indicates a misconfiguration of the ACPI _PSS (Performance
Supported States) object. This is described in section 8.4.4.2 of the APCI
specification.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

================================================================================
0 passed, 4 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================

0 passed, 4 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.

Test Failure Summary
================================================================================

Critical failures: NONE

High failures: NONE

Medium failures: 1
maxfreq: Maximum scali...

I'm fine with this change of tests and thanks for also editing the server whitelists as well :)

However, a couple things need to be addressed.

First, just to keep the same functionality, I'd prefer that a couple things were fixed:
line 215:
    elif args.all:
        tests.extend(['wakealarm', 'cpufreq'] + TESTS)

should include 'maxfreq'

However, that's a minor issue that shouldn't affect anything beyond using the --all option.

More importantly though, is why are we using maxfreq as opposed to cpufreq in fwts:

cpufreq         CPU frequency scaling tests.
maxfreq         Check max CPU frequencies against max scaling frequency.

As I understand it, maxfreq just does a quick check that what the CPU says about frequencies jives with what the kernel thinks it knows about them, while cpufreq actually changes frequencies and does cpu scale testing.

Here's sample output from my Core i5 Ivy Bridge based NUC:
Results generated by fwts: Version V14.03.01 (2014-03-27 02:14:17).

This test run on 07/04/14 at 10:20:53 on host Linux critical-maas
3.13.0-19-generic #40-Ubuntu SMP Mon Mar 24 02:36:06 UTC 2014 x86_64.

Command: "fwts maxfreq".
Running tests: maxfreq.

maxfreq: Test max CPU frequencies against max scaling frequency.
--------------------------------------------------------------------------------
Test 1 of 1: Maximum CPU frequency test.
This test checks the maximum CPU frequency as detected by the kernel for each
CPU against maxiumum frequency as specified by the BIOS frequency scaling
settings.
FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: The maximum scaling frequency 2.301000 GHz for CPU 0 configured by the
BIOS in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies does
not match the expected maximum CPU frequency 1.800000 GHz that the CPU can run
at. This usually indicates a misconfiguration of the ACPI _PSS (Performance
Supported States) object. This is described in section 8.4.4.2 of the APCI
specification.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

FAILED [MEDIUM] CPUFreqSpeedMismatch: Test 1, Maximum scaling frequency 2.301000
GHz do not match expected frequency 1.800000 GHz.

ADVICE: See advice for previous CPU.

================================================================================
0 passed, 4 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================

0 passed, 4 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.

Test Failure Summary
================================================================================

Critical failures: NONE

High failures: NONE

Medium failures: 1
 maxfreq: Maximum scaling frequency 2.301000 GHz do not match expected frequency 1.800000 GHz.

Low failures: NONE

Other failures: NONE
Test           |Pass |Fail |Abort|Warn |Skip |Info |
---------------+-----+-----+-----+-----+-----+-----+
maxfreq        |     |    4|     |     |     |     |
---------------+-----+-----+-----+-----+-----+-----+
Total:         |    0|    4|    0|    0|    0|    0|
---------------+-----+-----+-----+-----+-----+-----+
Results generated by fwts: Version V14.03.01 (2014-03-27 02:14:17).

And here are the results of cpufreq on the same machine:
Command: "fwts cpufreq".
Running tests: cpufreq.

cpufreq: CPU frequency scaling tests.
--------------------------------------------------------------------------------
Test 1 of 1: CPU P-State tests.
For each processor in the system, this test steps through the various frequency
states (P-states) that the BIOS advertises for the processor. For each processor
/frequency combination, a quick performance value is measured. The test then
validates that:
  1. Each processor has the same number of frequency states.
  2. Higher advertised frequencies have a higher performance.
  3. No duplicate frequency values are reported by the BIOS.
  4. BIOS doing Sw_All P-state coordination across cores.
  5. BIOS doing Sw_Any P-state coordination across cores.

WARNING: Test 1, There were 5 CPU frequencies larger than the _PSS maximum CPU
frequency of 1.85 GHz for CPU 0. Has /sys/devices/system/cpu/cpu0/cpufreq
/scaling_max_freq been set too low?
WARNING: Test 1, The CPU frequency BIOS limit /sys/devices/system/cpu/cpu0
/cpufreq/bios_limit for CPU 0 was set to 1.85 GHz which is lower than some of
the ACPI scaling frequencies.
CPU 0: 16 CPU frequency steps supported.
 Frequency | Relative Speed | Bogo loops
-----------+----------------+-----------
  2.35 GHz |      99.9 %    |    267164
  2.35 GHz |      99.9 %    |    267163
  2.25 GHz |      99.7 %    |    266628
  2.15 GHz |     100.0 %    |    267181
  2.05 GHz |     100.0 %    |    267298
  1.85 GHz |      99.9 %    |    267033
  1.75 GHz |      60.8 %    |    162648
  1.65 GHz |      57.3 %    |    153062
  1500 MHz |      53.7 %    |    143468
  1400 MHz |      50.1 %    |    133924
  1300 MHz |      46.5 %    |    124342
  1200 MHz |      42.9 %    |    114765
  1000 MHz |      35.8 %    |     95607
   900 MHz |      32.2 %    |     86036
   800 MHz |      28.6 %    |     76453
   759 MHz |      28.6 %    |     76454

FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 800 MHz
is slower (76453 bogo loops) than frequency 800 MHz (76454 bogo loops) on CPU 0.
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.15 GHz
is slower (267181 bogo loops) than frequency 2.15 GHz (267298 bogo loops) on CPU
0.
WARNING: Test 1, Frequency 2000000 not achievable; _PSS limit of 1800000 in
effect?
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.25 GHz
is slower (266628 bogo loops) than frequency 2.25 GHz (267181 bogo loops) on CPU
0.
WARNING: Test 1, There were 5 CPU frequencies larger than the _PSS maximum CPU
frequency of 1.85 GHz for CPU 1. Has /sys/devices/system/cpu/cpu1/cpufreq
/scaling_max_freq been set too low?
WARNING: Test 1, The CPU frequency BIOS limit /sys/devices/system/cpu/cpu1
/cpufreq/bios_limit for CPU 1 was set to 1.85 GHz which is lower than some of
the ACPI scaling frequencies.

CPU 1: 16 CPU frequency steps supported.
 Frequency | Relative Speed | Bogo loops
-----------+----------------+-----------
  2.35 GHz |     100.0 %    |    267137
  2.35 GHz |      99.8 %    |    266569
  2.25 GHz |      99.8 %    |    266660
  2.15 GHz |      98.6 %    |    263456
  2.05 GHz |      99.9 %    |    266913
  1.85 GHz |     100.0 %    |    267071
  1.75 GHz |      60.9 %    |    162593
  1.65 GHz |      57.3 %    |    153063
  1500 MHz |      53.7 %    |    143504
  1400 MHz |      50.1 %    |    133920
  1300 MHz |      46.5 %    |    124349
  1200 MHz |      43.0 %    |    114754
  1000 MHz |      35.8 %    |     95606
   900 MHz |      32.2 %    |     86030
   800 MHz |      28.6 %    |     76466
   759 MHz |      28.6 %    |     76462

FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.05 GHz
is slower (266913 bogo loops) than frequency 2.05 GHz (267071 bogo loops) on CPU
1.
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.15 GHz
is slower (263456 bogo loops) than frequency 2.15 GHz (266913 bogo loops) on CPU
1.
WARNING: Test 1, Frequency 2000000 not achievable; _PSS limit of 1800000 in
effect?
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.35 GHz
is slower (266569 bogo loops) than frequency 2.35 GHz (266660 bogo loops) on CPU
1.
WARNING: Test 1, There were 5 CPU frequencies larger than the _PSS maximum CPU
frequency of 1.85 GHz for CPU 2. Has /sys/devices/system/cpu/cpu2/cpufreq
/scaling_max_freq been set too low?
WARNING: Test 1, The CPU frequency BIOS limit /sys/devices/system/cpu/cpu2
/cpufreq/bios_limit for CPU 2 was set to 1.85 GHz which is lower than some of
the ACPI scaling frequencies.

CPU 2: 16 CPU frequency steps supported.
 Frequency | Relative Speed | Bogo loops
-----------+----------------+-----------
  2.35 GHz |      99.9 %    |    266977
  2.35 GHz |      99.3 %    |    265400
  2.25 GHz |      99.8 %    |    266583
  2.15 GHz |      99.9 %    |    266994
  2.05 GHz |     100.0 %    |    267216
  1.85 GHz |      96.4 %    |    257560
  1.75 GHz |      60.4 %    |    161401
  1.65 GHz |      55.5 %    |    148415
  1500 MHz |      51.9 %    |    138672
  1400 MHz |      50.1 %    |    133940
  1300 MHz |      46.5 %    |    124362
  1200 MHz |      43.0 %    |    114781
  1000 MHz |      35.8 %    |     95629
   900 MHz |      32.2 %    |     86046
   800 MHz |      28.6 %    |     76471
   759 MHz |      28.6 %    |     76298

FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.15 GHz
is slower (266994 bogo loops) than frequency 2.15 GHz (267216 bogo loops) on CPU
2.
WARNING: Test 1, Frequency 2000000 not achievable; _PSS limit of 1800000 in
effect?
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.25 GHz
is slower (266583 bogo loops) than frequency 2.25 GHz (266994 bogo loops) on CPU
2.
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.35 GHz
is slower (265400 bogo loops) than frequency 2.35 GHz (266583 bogo loops) on CPU
2.
WARNING: Test 1, There were 5 CPU frequencies larger than the _PSS maximum CPU
frequency of 1.85 GHz for CPU 3. Has /sys/devices/system/cpu/cpu3/cpufreq
/scaling_max_freq been set too low?
WARNING: Test 1, The CPU frequency BIOS limit /sys/devices/system/cpu/cpu3
/cpufreq/bios_limit for CPU 3 was set to 1.85 GHz which is lower than some of
the ACPI scaling frequencies.

CPU 3: 16 CPU frequency steps supported.
 Frequency | Relative Speed | Bogo loops
-----------+----------------+-----------
  2.35 GHz |     100.0 %    |    267145
  2.35 GHz |      98.8 %    |    263873
  2.25 GHz |      99.9 %    |    266863
  2.15 GHz |     100.0 %    |    267081
  2.05 GHz |      99.7 %    |    266384
  1.85 GHz |      99.7 %    |    266269
  1.75 GHz |      60.9 %    |    162629
  1.65 GHz |      57.3 %    |    153074
  1500 MHz |      53.7 %    |    143492
  1400 MHz |      50.1 %    |    133892
  1300 MHz |      46.5 %    |    124339
  1200 MHz |      43.0 %    |    114765
  1000 MHz |      35.8 %    |     95606
   900 MHz |      32.2 %    |     86035
   800 MHz |      28.6 %    |     76458

759 MHz |      28.6 %    |     76455

WARNING: Test 1, Frequency 2000000 not achievable; _PSS limit of 1800000 in
effect?
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.25 GHz
is slower (266863 bogo loops) than frequency 2.25 GHz (267081 bogo loops) on CPU
3.
FAILED [MEDIUM] CPUFreqSlowerOnCPU: Test 1, Supposedly higher frequency 2.35 GHz
is slower (263873 bogo loops) than frequency 2.35 GHz (266863 bogo loops) on CPU
3.
PASSED: Test 1, P-state coordination under hardware control.

================================================================================
1 passed, 11 failed, 12 warnings, 0 aborted, 0 skipped, 0 info only.
================================================================================

1 passed, 11 failed, 12 warnings, 0 aborted, 0 skipped, 0 info only.

Test Failure Summary
================================================================================

Critical failures: NONE

High failures: NONE

Medium failures: 11
 cpufreq: Supposedly higher frequency 800 MHz is slower (76453 bogo loops) than frequency 800 MHz (76454 bogo loops) on CPU 0.
 cpufreq: Supposedly higher frequency 2.15 GHz is slower (267181 bogo loops) than frequency 2.15 GHz (267298 bogo loops) on CPU 0.
 cpufreq: Supposedly higher frequency 2.25 GHz is slower (266628 bogo loops) than frequency 2.25 GHz (267181 bogo loops) on CPU 0.
 cpufreq: Supposedly higher frequency 2.05 GHz is slower (266913 bogo loops) than frequency 2.05 GHz (267071 bogo loops) on CPU 1.
 cpufreq: Supposedly higher frequency 2.15 GHz is slower (263456 bogo loops) than frequency 2.15 GHz (266913 bogo loops) on CPU 1.
 cpufreq: Supposedly higher frequency 2.35 GHz is slower (266569 bogo loops) than frequency 2.35 GHz (266660 bogo loops) on CPU 1.
 cpufreq: Supposedly higher frequency 2.15 GHz is slower (266994 bogo loops) than frequency 2.15 GHz (267216 bogo loops) on CPU 2.
 cpufreq: Supposedly higher frequency 2.25 GHz is slower (266583 bogo loops) than frequency 2.25 GHz (266994 bogo loops) on CPU 2.
 cpufreq: Supposedly higher frequency 2.35 GHz is slower (265400 bogo loops) than frequency 2.35 GHz (266583 bogo loops) on CPU 2.
 cpufreq: Supposedly higher frequency 2.25 GHz is slower (266863 bogo loops) than frequency 2.25 GHz (267081 bogo loops) on CPU 3.
 cpufreq: Supposedly higher frequency 2.35 GHz is slower (263873 bogo loops) than frequency 2.35 GHz (266863 bogo loops) on CPU 3.

Low failures: NONE

Other failures: NONE

Test           |Pass |Fail |Abort|Warn |Skip |Info |
---------------+-----+-----+-----+-----+-----+-----+
cpufreq        |    1|   11|     |   12|     |     |
---------------+-----+-----+-----+-----+-----+-----+
Total:         |    1|   11|    0|   12|    0|    0|
---------------+-----+-----+-----+-----+-----+-----+

Finally,  There needs to either be a re-evaluation of what triggers a "Failure" as far as checkbox/plainbox is concerned, and/or a log check to parse the logs for this test to evaluate this.

You can change the fail threshold using the -f option of fwts_test, It defaults to fail only on Critical or High, but as you can see above, 11 of 12 tests failed at Medium level, and thus could be overlooked on review even though they could indicate a real failure issue.

Or, as mentioned above, a second job similar to sleep_test_log_check to parse the log and make that determination may be more appropriate and preferable as it can contain a lot more job specific log parsing without adding a lot of test specific stuff to the main wrapper.

review: Needs Fixing

Revision history for this message

Ara Pulido (ara) wrote on 2014-04-07:

#

Jeff, I agree with your first comment, but I don't understand your reasoning for the second one.

You are arguing that we would miss errors, but, actually, cpufreq test was already being run outside fwts in its own test, with the same level (High or Critical) and there hasn't been any complains yet. Can you clarify, please?

Also, the MEDIUM level here is correct. The fwts adjusts this levels so in Checkbox/Plainbox (i.e. for certificatoin) we only need to care about HIGH/CRITICAL.

Revision history for this message

Jeff Lane  (bladernr) wrote on 2014-04-07:

#

Yeah, actually, I said "a couple things" but meant three:

1: we agree on

2: you suggest using maxfreq as opposed to cpufreq. As best as I can tell, maxfreq is simply a comparison of stated frequencies, similar in function to the CPU topology test where we simply compare one thing to another. cpufreq in fwts actually does cpu scaling and tests that the frequency change happens and makes sense, which is closer to the intention of the older frequency_governors test.

And thinking back, I intentionally left cpufreq out of the wrapper because we were already testing this via frequency governors. Perhaps this would be better as a new option to specify running cpufreq instead and putting maxfreq back in the man tests list?

3: Error handling - this was more a suggestion. The real reason we "ignored" frequency_governors is that the test was mysterious, no one quite understood how it worked and the results were very often dodgy (it would pass on a machine at one moment, and fail the next for no good reason at all, or it would fail outright but the logs would appear to have been satisfactory).

If the intention is to use the fwts test because the fwts team are the experts there, it MAY be useful to figure out what an actual failure is. Test this on several different systems with different CPUs and such and find out exactly what it looks like and maybe decide if there's a need to parse the results for different fail criteria.

Yeah, I admit my sample is very small and unscientific and does NOT demonstrate a real failure, but to be honest, I don't know what a "Real" failure with this test would be. So the third item is more a suggestion.

I'm sorry for not making that more clear before... to summarize, in order of importance:

1: Are we using maxfreq or cpufreq, and if not cpufreq, why?
2: Line 215 just to maintain the same functionality in the wrapper
3: Just a suggestion about fail criteria and log parsing because I can't say what this really looks like when it fails. Perhaps just asking the firmware team would give a good enough idea.

Yeah, actually, I said "a couple things" but meant three:

1: we agree on

2: you suggest using maxfreq as opposed to cpufreq.  As best as I can tell, maxfreq is simply a comparison of stated frequencies, similar in function to the CPU topology test where we simply compare one thing to another.  cpufreq in fwts actually does cpu scaling and tests that the frequency change happens and makes sense, which is closer to the intention of the older frequency_governors test.

And thinking back, I intentionally left cpufreq out of the wrapper because we were already testing this via frequency governors.  Perhaps this would be better as a new option to specify running cpufreq instead and putting maxfreq back in the man tests list?

3: Error handling - this was more a suggestion.  The real reason we "ignored" frequency_governors is that the test was mysterious, no one quite understood how it worked and the results were very often dodgy (it would pass on a machine at one moment, and fail the next for no good reason at all, or it would fail outright but the logs would appear to have been satisfactory).

If the intention is to use the fwts test because the fwts team are the experts there, it MAY be useful to figure out what an actual failure is. Test this on several different systems with different CPUs and such and find out exactly what it looks like and maybe decide if there's a need to parse the results for different fail criteria.

Yeah, I admit my sample is very small and unscientific and does NOT demonstrate a real failure, but to be honest, I don't know what a "Real" failure with this test would be.  So the third item is more a suggestion.

I'm sorry for not making that more clear before... to summarize, in order of importance:

1: Are we using maxfreq or cpufreq, and if not cpufreq, why?
2: Line 215 just to maintain the same functionality in the wrapper
3: Just a suggestion about fail criteria and log parsing because I can't say what this really looks like when it fails. Perhaps just asking the firmware team would give a good enough idea.

lp:~ara/checkbox/fix_1303694 updated on 2014-04-07

2896. By Ara Pulido on 2014-04-07: Added maxfreq to the list of tests to extend when running fwts_test with the all parameter

Revision history for this message

Jeff Lane  (bladernr) wrote on 2014-04-07:

#

To sync with the discussion on IRC and email, I agree with Ara's disagreement :) Silly me should read more than just the diff... sigh...

Thanks for fixing the first item too :)

review: Approve

Revision history for this message

Zygmunt Krynicki (zyga) wrote on 2014-04-07:

#

+command: [[ -e ${CHECKBOX_DATA}/maxfreq_test.log ]] && cat ${CHECKBOX_DATA}/maxfreq_test.log

This is an useless bashism. Use [ ] the next time. I've fixed this while rebasing my provider changes.

1	=== modified file 'plainbox-provider-certification-client/provider_whitelists/client-cert.whitelist'
2	--- plainbox-provider-certification-client/provider_whitelists/client-cert.whitelist 2014-03-27 20:36:34 +0000
3	+++ plainbox-provider-certification-client/provider_whitelists/client-cert.whitelist 2014-04-07 15:08:50 +0000
4	@@ -270,9 +270,10 @@
5	benchmarks/graphics/gtkperf
6	cpu/scaling_test
7	cpu/scaling_test-log-attach
8	+cpu/maxfreq_test
9	+cpu/maxfreq_test-log-attach
10	cpu/offlining_test
11	cpu/topology
12	-cpu/frequency_governors
13	cpu/clocktest
14	disk/stats
15	disk/stats_.*
16
17	=== modified file 'plainbox-provider-certification-client/provider_whitelists/client-selftest.whitelist'
18	--- plainbox-provider-certification-client/provider_whitelists/client-selftest.whitelist 2014-03-27 20:36:34 +0000
19	+++ plainbox-provider-certification-client/provider_whitelists/client-selftest.whitelist 2014-04-07 15:08:50 +0000
20	@@ -278,9 +278,10 @@
21	benchmarks/graphics/gtkperf
22	cpu/scaling_test
23	cpu/scaling_test-log-attach
24	+cpu/maxfreq_test
25	+cpu/maxfreq_test-log-attach
26	cpu/offlining_test
27	cpu/topology
28	-cpu/frequency_governors
29	cpu/clocktest
30	disk/stats
31	disk/stats_.*
32
33	=== modified file 'plainbox-provider-certification-server/provider_whitelists/server-selftest-14.04.whitelist'
34	--- plainbox-provider-certification-server/provider_whitelists/server-selftest-14.04.whitelist 2014-04-01 16:01:57 +0000
35	+++ plainbox-provider-certification-server/provider_whitelists/server-selftest-14.04.whitelist 2014-04-07 15:08:50 +0000
36	@@ -55,9 +55,10 @@
37	cpu/clocktest
38	cpu/scaling_test
39	cpu/scaling_test-log-attach
40	+cpu/maxfreq_test
41	+cpu/maxfreq_test-log-attach
42	cpu/offlining_test
43	cpu/topology
44	-cpu/frequency_governors
45	__disk__
46	disk/detect
47	disk/stats
48
49	=== modified file 'plainbox-provider-checkbox/provider_bin/fwts_test'
50	--- plainbox-provider-checkbox/provider_bin/fwts_test 2014-03-20 14:01:58 +0000
51	+++ plainbox-provider-checkbox/provider_bin/fwts_test 2014-04-07 15:08:50 +0000
52	@@ -22,7 +22,6 @@
53	'fadt',
54	'hpet_check',
55	'klog',
56	- 'maxfreq',
57	'mcfg',
58	'method',
59	'mpcheck',
60	@@ -212,7 +211,7 @@
61	elif args.test:
62	tests.extend(args.test)
63	elif args.all:
64	- tests.extend(['wakealarm', 'cpufreq'] + TESTS)
65	+ tests.extend(['wakealarm', 'cpufreq', 'maxfreq'] + TESTS)
66	elif args.sleep:
67	args.sleep = fix_sleep_args(args.sleep)
68	iterations = 1
69
70	=== modified file 'plainbox-provider-checkbox/provider_jobs/cpu.txt.in'
71	--- plainbox-provider-checkbox/provider_jobs/cpu.txt.in 2014-03-20 14:07:18 +0000
72	+++ plainbox-provider-checkbox/provider_jobs/cpu.txt.in 2014-04-07 15:08:50 +0000
73	@@ -16,6 +16,23 @@
74	Attaches the log generated by cpu/scaling_test to the results
75
76	plugin: shell
77	+name: cpu/maxfreq_test
78	+requires:
79	+ package.name == 'fwts'
80	+user: root
81	+environ: CHECKBOX_DATA
82	+command: fwts_test -t maxfreq -l ${CHECKBOX_DATA}/maxfreq_test.log
83	+_description:
84	+ Test that the CPU can run at its max frequency using Firmware Test Suite (fwts cpufreq).
85	+
86	+plugin: attachment
87	+name: cpu/maxfreq_test-log-attach
88	+depends: cpu/maxfreq_test
89	+command: [[ -e ${CHECKBOX_DATA}/maxfreq_test.log ]] && cat ${CHECKBOX_DATA}/maxfreq_test.log
90	+_description:
91	+ Attaches the log generated by cpu/maxfreq_test to the results
92	+
93	+plugin: shell
94	name: cpu/clocktest
95	command: clocktest
96	_description:

Checkbox

Merge lp:~ara/checkbox/fix_1303694 into lp:checkbox

Commit message

Description of the change

Preview Diff

Subscribers