Bug 688995

Summary: Cpuscaling fails ondemand test section only on RH6 x86
Product: [Retired] Red Hat Hardware Certification Program Reporter: Gregg Shick <gregg.shick>
Component: Test Suite (tests)Assignee: Greg Nichols <gnichols>
Status: CLOSED DUPLICATE QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.3CC: rlandry, ykun
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-06 18:43:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
failing x86 log
none
x64 passing results none

Description Gregg Shick 2011-03-18 18:29:13 UTC
Created attachment 486298 [details]
failing x86 log

Description of problem: Cpuscaling fails ondemand test section only on RH6 x86


Version-Release number of selected component (if applicable):  RH6 x86 / v7-1-2-25



How reproducible: Every time


Steps to Reproduce:
1.  Install RH6 x86
2.  Install v7-1-2-25
3.  Execute cpuscaling
  
Actual results:  Userspace and performance pass.  Ondemand fails.  Failure only occurs in x86. x64 passes successfully.  


Expected results:  Ondemand should complete work at the same speed as userspace.  


Additional info:

We executed "watch -n1 /sys/devices/system/cpu/cpu*/cpufreq/cur_scale_feq" to watch the processor speeds as the test was executing. It showed the processors going to the same high speed during ondemand as it did during userspace, but for some reason ondemand took longer to execute the test task.

Comment 1 Gregg Shick 2011-03-18 18:29:55 UTC
Created attachment 486300 [details]
x64 passing results

Comment 2 David Aquilina 2011-03-30 21:57:33 UTC
Gregg, do you still see the failures with the v7-1.3-19 beta?

Comment 4 Greg Nichols 2011-04-06 18:43:00 UTC

*** This bug has been marked as a duplicate of bug 579498 ***