Bug 916071 - cpufreq don't work with kernel 3.9.0.0.rc0
Summary: cpufreq don't work with kernel 3.9.0.0.rc0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-27 07:51 UTC by dominique
Modified: 2013-04-09 20:12 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-04-09 20:12:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg with cpufreq.debug=7 (89.08 KB, text/plain)
2013-03-03 05:57 UTC, dominique
no flags Details
Comment (1.27 MB, text/plain)
2013-03-02 05:00 UTC, dominique
no flags Details

Description dominique 2013-02-27 07:51:04 UTC
I test Fedora 19 rawhide, and there is problem with cpuinfo and kernel 3.9.0.0.

With kernel 3.8, that work and i can see my frequencies up and down, but with kernel 3.9.0.0, there are only one number 782 Mhz :

[dominique@host ~]$ cat /proc/cpuinfo | grep "cpu MHz"
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000
[dominique@host ~]$

I don't know if it's a kernel bug or a fedora bug.

Comment 1 dominique 2013-03-01 19:14:40 UTC
A little up...
Nobodies are same issues ?

Comment 2 Dave Jones 2013-03-01 21:14:58 UTC
I suspect this is due to the new intel pstate driver. Can you attach the full dmesg after booting with cpufreq.debug=7

Comment 3 dominique 2013-03-02 05:00:16 UTC
Created attachment 915676 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 4 dominique 2013-03-02 05:02:30 UTC
output of dmesg with cpufreq.debug=7

Comment 5 dominique 2013-03-03 05:57:48 UTC
Created attachment 704523 [details]
dmesg with cpufreq.debug=7

Comment 6 dominique 2013-03-03 06:01:11 UTC
I create an attachment "dmesg with cpufreq.debug=7", but I can delete comment #3, that is horrible...

If an admin can delete this for me...

Comment 7 dominique 2013-03-04 18:21:21 UTC
Hi
I post a bug report on kernel.org : https://bugzilla.kernel.org/show_bug.cgi?id=54541

I do a gitbisect on the kernel-source git, with no error...

I know that fedora patch the kernel, maybe one of those patches is responsible for this bug...

Comment 8 Dave Jones 2013-03-04 21:09:54 UTC
Fedora has no patches that would be relevant to this code.
The problem is caused by the new pstate driver. I suspect you previously were running acpi-cpufreq, but this new driver is now binding instead.

Added the maintainer to the Cc of this bug.

Comment 9 Dirk Brandewie 2013-03-04 21:51:09 UTC
If you are doing this on an idle system you will probably not see this move from the lowest P state (frequency).  Do you see the frequency change when you have the system loaded?

Comment 10 dominique 2013-03-05 05:59:27 UTC
When the system is loaded, the frequency don't change and stay on 782 value.

With my conky, I can see cpu occupancy rate which varies, but frequency don't change.

Comment 11 dominique 2013-03-09 08:07:18 UTC
For test I rebuild kernel-3.9.0-0.rc1.git0.4.fc19 for F18 with rpmbuild and install.

I boot on kernel kernel-3.9.0-0.rc1.git0.4.fc18, and I have same problem, 

[dominique@host ~]$ cat /proc/cpuinfo | grep "cpu MHz"
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000
[dominique@host ~]$

If that help you...

Comment 12 dominique 2013-03-16 10:59:48 UTC
I do an other test, with kernel-3.9.0-0.rc2.git0.3.fc19.src.rpm

Like an gitbisect, I build different kernels, and after some steeps, the patch with problem is patch-3.9-rc2.xz.

I build without this patch, and no problem, but this patch is for transform a 3.8 kernel in 3.9 kernel...

Why didn't you build a fedora 3.9 kernel with the 3.9-rc2 kernel from kernel.org ?

Comment 13 Dave Jones 2013-03-16 14:17:33 UTC
3.8+the 3.9rc2 patch is bit for bit identical with the tarball.

All you've proven with the bisect is that 3.8 works for you, which we knew, as the pstate driver wasn't in 3.8, you were using acpi-cpufreq instead there.

Comment 14 dominique 2013-03-17 07:22:18 UTC
OK OK OK...

I'm not disputing what you say but when I rebuild a 3.9.0-0.rc2.git0.3.fc19 kernel with only patch-3.9-rc2.xz I have the problem, and when I build a kernel with 3.9-rc2 source from kernel.org, I have not this problem...

Comment 15 Dave Jones 2013-03-18 00:31:20 UTC
ok, that doesn't make much sense to me.   Are you using the same config options as the fedora kernel or configuring it yourself ?

Comment 16 dominique 2013-03-18 05:03:14 UTC
I don't know if i use the same option in configuring kernel.

When I compile a kernel 3.9-rc2 from kernel.org, I just do a "make gconfig", and save without modifications.

And after :
make
make modules
su -c "make modules_install"
su -c "make install"
Let me know if you want I do test. But this week I will be moving and will not have access to my computer.

Comment 17 Dave Jones 2013-03-18 13:17:54 UTC
grep PSTATE .config

Comment 18 Dirk Brandewie 2013-03-18 15:16:49 UTC
(In reply to comment #14)
> OK OK OK...
> 
> I'm not disputing what you say but when I rebuild a 3.9.0-0.rc2.git0.3.fc19
> kernel with only patch-3.9-rc2.xz I have the problem, and when I build a
> kernel with 3.9-rc2 source from kernel.org, I have not this problem...

Do the kernel builds take about the same amount of time with the same config?

Have you looked at frequency during the kernel build?

I have not been able to reproduce your results.  

What type of system are you running on?  desktop, notebook ...

What BIOS is on the system?

Sorry for being out of the discussion but I was travelling all last week.

Comment 19 dominique 2013-03-18 15:41:40 UTC
result of grep pstate .config :

[dominique@chepioq linux-git]$ cat .config | grep pstate
[dominique@chepioq linux-git]$ cat .config | grep PSTATE
# CONFIG_X86_INTEL_PSTATE is not set
[dominique@chepioq linux-git]$

Comment 20 Dave Jones 2013-03-18 16:12:24 UTC
ok, so we're back where we were.  You're not building the new driver in your build, which is why it's working (it's using acpi instead).

Comment 21 dominique 2013-03-18 16:23:14 UTC
OK
I go building this kernel with CONFIG_X86_INTEL_PSTATE=y and I report you if that work or not...

Comment 22 dominique 2013-03-18 16:28:48 UTC
OK
I go building this kernel with CONFIG_X86_INTEL_PSTATE=y and I report you if that work or not...

Comment 23 dominique 2013-03-18 18:26:18 UTC
Ok ok ok...
I build the 3.9-rc2 kernel from kernel.org with CONFIG_X86_INTEL_PSTATE=y and after installing, I have the error : 

[dominique@host ~]$ cat /proc/cpuinfo | grep "cpu MHz"
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000
cpu MHz         : 782.000

But that don't help...

Comment 24 dominique 2013-03-18 18:53:17 UTC
(In reply to comment #18)
> (In reply to comment #14)
> > OK OK OK...
> > 
> > I'm not disputing what you say but when I rebuild a 3.9.0-0.rc2.git0.3.fc19
> > kernel with only patch-3.9-rc2.xz I have the problem, and when I build a
> > kernel with 3.9-rc2 source from kernel.org, I have not this problem...
> 
> Do the kernel builds take about the same amount of time with the same config?
> 
> Have you looked at frequency during the kernel build?
> 
> I have not been able to reproduce your results.  
> 
> What type of system are you running on?  desktop, notebook ...
> 
> What BIOS is on the system?
> 
> Sorry for being out of the discussion but I was travelling all last week.

The kernel build take the same about of time

During the kernel build, I can see my frequencies up and down (800 to 2300)

My computer is a laptop Toshiba L770/775 with Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz, 4 core.

The BIOS version (with the command dd if=/dev/mem bs=32k skip=31 count=1 | strings -n 8 | grep -i bios) :

AMIBIOS 080010
AMIBIOS(C)2010 American Megatrends, Inc.                                      
BIOS Date: 07/18/12 11:16:52 Ver: 04.06.03

Comment 25 dominique 2013-03-18 18:59:08 UTC
And more info for bios with dmidecode

BIOS Information
        Vendor: American Megatrends Inc.
        Version: 2.30
        Release Date: 07/18/2012
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 2048 kB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
        BIOS Revision: 4.6

Comment 26 Dirk Brandewie 2013-03-18 21:34:20 UTC
(In reply to comment #24)
> The kernel build take the same about of time
> 
> During the kernel build, I can see my frequencies up and down (800 to 2300)
> 

If you are seeing the frequencies change then I am not sure what you think the bug is.  The intel_pstate driver doesn't change the frequency like the ondemand governor which is the point :-)  you will not see the frequency changing like you have been used to.

If you lose performance compared to the governor that you are using that would be somthing I would like to know about.

If I missed what you meant to say please strighten me out ;-)

Comment 27 dominique 2013-03-19 06:01:48 UTC
(In reply to comment #26)
> If you are seeing the frequencies change then I am not sure what you think
> the bug is.  The intel_pstate driver doesn't change the frequency like the
> ondemand governor which is the point :-)  you will not see the frequency
> changing like you have been used to.
> 
> If you lose performance compared to the governor that you are using that
> would be somthing I would like to know about.
> 
> If I missed what you meant to say please strighten me out ;-)

Ok...

I build the 3.9-rc2 on my Fedora 18, with kernel 3.8, and not with Fedora 19 and kernel 3.9.

For test, I build on Fedora 19 (and kernel 3.9), and frequency stay on 782 Mhz.

But the performance is about the same, approximately 1 hour for building.

If I understand what you say, it's the normal way, processor stay on 782 Mhz (but that is very strange...)

My i3-2350M CPU @ 2.30GHz can goes to 2.3 Ghz, 

Is it possible to force on 2.3 Ghz ?

Comment 28 Fedora End Of Life 2013-04-03 15:44:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 29 dominique 2013-04-09 18:48:12 UTC
Hi,
I install F19 tc5 and kernel 3.9.0-0.rc6.git0.1.fc19.x86_64.
 
As I can see in this bug report: 746372 I also install kernel-tools and enable cpupower.service.

With that I can see my cpu freq up and down :
[root@host Téléchargements]# cat /proc/cpuinfo | grep MHz
cpu MHz         : 1955.000
cpu MHz         : 1426.000
cpu MHz         : 2208.000
cpu MHz         : 2231.000
[root@host Téléchargements]# 
[root@host Téléchargements]# cat /proc/cpuinfo | grep MHz
cpu MHz         : 1426.000
cpu MHz         : 2231.000
cpu MHz         : 1978.000
cpu MHz         : 1702.000
[root@host Téléchargements]# cat /proc/cpuinfo | grep MHz
cpu MHz         : 1748.000
cpu MHz         : 1380.000
cpu MHz         : 2116.000
cpu MHz         : 2277.000

For info :
[root@host Téléchargements]# cpupower frequency-info
analyse du CPU 0 :
  pilote : intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  limitation matérielle : 800 MHz - 2.30 GHz
  régulateurs disponibles : performance, powersave
  tactique actuelle : la fréquence doit être comprise entre 800 MHz et 2.30 GHz.
                  Le régulateur "performance" est libre de choisir la vitesse
                  dans cette plage de fréquences.
  la fréquence actuelle de ce CPU est 1.63 GHz (vérifié par un appel direct du matériel).
  boost state support:
    Supported: no
    Active: no
    2300 MHz max turbo 4 active cores
    2300 MHz max turbo 3 active cores
    2300 MHz max turbo 2 active cores
    2300 MHz max turbo 1 active cores

it's seem that for me this bug is soved.

Comment 30 Justin M. Forbes 2013-04-09 20:12:18 UTC
Excellent, thanks!


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