Bug 722715 - [RFE] Turbo boost test fails in v7 cpuscaling test with Intel Westmere-EX E7-8837 CPU
Summary: [RFE] Turbo boost test fails in v7 cpuscaling test with Intel Westmere-EX E7-...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Hardware Certification Program
Classification: Retired
Component: Test Suite (tests)
Version: 6.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Greg Nichols
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-16 23:31 UTC by Simon Sekidde
Modified: 2018-11-14 11:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-13 19:04:51 UTC


Attachments (Terms of Use)
CPUSCALING FAIL with E5620 processors and x86_64 kernel (2.71 MB, application/x-rpm)
2011-10-11 20:06 UTC, Simon Sekidde
no flags Details
BIOS 59 FIXES CPUSCALING BUG (2.31 MB, application/x-7z-compressed)
2011-10-11 20:07 UTC, Simon Sekidde
no flags Details

Description Simon Sekidde 2011-07-16 23:31:51 UTC
[RFE] Turbo boost test fails in v7 cpuscaling test with Intel Westmere-EX E7-8837 CPU 

Description of problem:

We tested 2 types of CPUs to verify the cpuscaling test fail symptom.

E7-8870 CPU (CPU frequency from 2.4GHz up to 2.77GHz) - 3 speed steps up when the turbo boost is active - Passed 
E7-8837 CPU (CPU frequency from 2.67GHz up to 2.80GHz) - 1 speed step up only in turbo boost active - Failed 

Version-Release number of selected component (if applicable):

v7-1.3-46.el6

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:

v7 cpuscaling test script unable to verify E7-8837 CPU 

Expected results:

Run cpuscaling test with wider frequency for both
Improve the turbo boost check for the cpuscaling script 

Additional info:

Comment 1 Greg Nichols 2011-09-29 15:06:09 UTC
Please retest with the v7 1.4 beta (R30).

Comment 2 Simon Sekidde 2011-10-11 20:05:47 UTC
sfdc #00530264 in reference to Bug 713543

https://bugzilla.redhat.com/show_bug.cgi?id=713543

I am coming to the conclusion that something is broken with the Red Hat 6.1  x86_64 kernel.
I swapped out a pair of E5645 Xeon's from one of my two CPUSCLAING failing system and replced them with slightly earlier E5620 Xeon.  The CPUSCALING test still fails under the x86_64 kernel.
Both of these processor models (E5620 and E5645) passed teh CPUSCALING using the RHEL 5.4 x86_64 kernel, as evidenced by my completed certification:
https://hardware.redhat.com/show.cgi?id=585367

There is no evidence that the CPUSCALING even makes any attempt to run, because, according to the test description,

 The test is scheduled when the hardware detection routines find the following directories in /sys containing more than one cpu frequency:

    /sys/devices/system/cpu/cpu<number>/cpufreq

These directories DO NOT EXIST after the x86_64 kernel boots.
(root)/root/Desktop# ls /sys/devices/system/cpu/
cpu0/                    cpu15/                   cpu8/                    perf_events/
cpu1/                    cpu2/                    cpu9/                    possible
cpu10/                   cpu3/                    cpufreq/                 present
cpu11/                   cpu4/                    cpuidle/                 sched_mc_power_savings
cpu12/                   cpu5/                    kernel_max               sched_smt_power_savings
cpu13/                   cpu6/                    offline                  
cpu14/                   cpu7/                    online                   

and /sys/devices/system/cpu/cpufreq is empty....

(root)/root/Desktop# ls /sys/devices/system/cpu/cpufreq
(root)/root/Desktop# 

I have attached the results with teh E5620 processors.

Last update (both files attached)

BIOS 59 FIXES CPUSCALING BUG.7z

Simon

Comment 3 Simon Sekidde 2011-10-11 20:06:37 UTC
Created attachment 527538 [details]
CPUSCALING FAIL with E5620 processors and x86_64 kernel

Comment 4 Simon Sekidde 2011-10-11 20:07:28 UTC
Created attachment 527539 [details]
BIOS 59 FIXES CPUSCALING BUG

Comment 5 Greg Nichols 2011-10-13 19:05:35 UTC
Closing as fixed via BIOS update in comment 4.


Note You need to log in before you can comment on or make changes to this bug.