Bug 474856
Summary: | CPUScaling Fails in HTS 5.3-3. | ||
---|---|---|---|
Product: | [Retired] Red Hat Hardware Certification Program | Reporter: | Ryan Armstrong <ryan.armstrong> |
Component: | Test Suite (tests) | Assignee: | Greg Nichols <gnichols> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Lawrence Lim <llim> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | dwa, gnichols, gregg.shick, gwen.lapo, mark.coskey, rlandry, rpacheco, tools-bugs, tyan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-04-23 18:25:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Ryan Armstrong
2008-12-05 16:44:56 UTC
Created attachment 325876 [details]
Output of CPUScaling test failure.
We should fix the traceback, however the error was caused by the scheduling of a test to a non-existent device. Specifically no cpu number was provided, from the log it looks like the test should be scheduled for cpu0-7 (each with their own plan line). I would also be curious why it didn't auto schedule on it's own, that should be caused by a failure of the system, kernel or HAL to identify itself, pickup a capability or report it, in all cases something should be fixed. Created attachment 326522 [details]
cpuscaling.py patch for traceback
The invalid path sys/devices/system/cpu/cpucpu/ is also seen on the HTS-5.3-9. Can we get a copy of the plan output; as well the lshal output for the system? From earlier, it appeared the test was scheduled incorrectly via the --add command to a non-existant cpu (eg. "cpu" does not exist, "cpu0", "cpu1"... "cpu7" are the correct devices the test should be scheduled against individually) which caused a traceback. The traceback should be resolved, but the newer test suit would not address making "cpu" a valid device. Most likely the need to schedule the test manually was cause by lshal not reporting the capabilities of the system correctly which would most likely come from either a kernel, hal or BIOS bug. To verify this a quick look @ 'lshal | grep throttle' should reveal the case, if all throttle lines are reported as false then hts won't schedule the cpuscaling test as the system is reporting as it is not capable and a new bug should be opened. Adding Ron and David to the cc: list so they are aware. Created attachment 328056 [details]
cupscaling output.log for hts-5.3-12
Verified following things in hts-5.3-12: - cpuscaling test was scheduled to separated with different device name(0,1,...). - "hts run -t cpuscaling -v 0" passed without error - "hts plan -a -t cpuscaling -v cpu" output: ... Warning: unknown device: cpu Added test saved test plan to /var/hts/result.xml - "hts run -t cpuscaling -v cpu" still failed, attached the output.log. Re-opened this bug. Created attachment 328293 [details]
cpuscaling.py patch for traceback on R12
Additional changes on the R12 baseline for tracebacks occuring when invalid --device options are used to add the cpuscaling test.
Created attachment 328865 [details]
5.3-12 results
Adding in cpuscaling results from 5.3-12.
The cpuscaling test does not get added automatically during plan creation.
Running "hts plan --enable --test cpuscaling --device cpu" to add test to testplan.
Correction, the attachment added in comment 11 was adding the test to the plan without specifying a device. Created attachment 328866 [details]
5.3-12 results adding cpu device manually
Log file for failing cpuscaling when adding --device cpu.
(In reply to comment #11) > Running "hts plan --enable --test cpuscaling --device cpu" to add test to > testplan. The correct command to add the test for cpu0 would be: hts plan --add --test cpuscaling --device 0 Created attachment 329317 [details]
cupscaling output.log {2} for hts-5.3-12
Re-tested this bug as following steps:
- cpuscaling test was scheduled to separated with different device name(0,1)
- "hts run -t cpuscaling -v 0" passed without error
- "hts plan -a -t cpuscaling -v 2" output:
...
Added test
saved test plan to /var/hts/result.xml
- "hts run -t cpuscaling -v 2" still failed, attached the output.log.
Greg So will I have to schedule a cpuscaling run for each core manually? Greg So will I have to schedule a cpuscaling run for each core manually? Changing state back to POST - the patch is not yet committed. Hey Gregg, Is this sorted, are we able to close this or is there something still pending here that we need to review? I think the original issue was in regards to not understanding the proper command to add the scaling test manually for proper execution. Let me confirm on 5.4 with the latest kit if cpuscaling is automatically being scheduled or not. The attached patch fixes a traceback that happens with the test is manually added incorrectly. comitted patch fixing traceback. |