All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Isaev <lisaev@umail.iu.edu>
To: "André Przywara" <andre@andrep.de>
Cc: Borislav Petkov <bp@alien8.de>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Tom Gundersen <teg@jklm.no>,
	Matthew Garrett <matthew.garrett@nebula.com>,
	cpufreq@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [arch-general] powernow-k8 fails to load with linux 3.7.2
Date: Fri, 18 Jan 2013 11:13:42 -0600	[thread overview]
Message-ID: <20130118111342.3d17fef1@bluemoon> (raw)
In-Reply-To: <20130118133233.4521ddb6@hydra>

[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

On Fri, 18 Jan 2013 13:32:33 +0100
André Przywara <andre@andrep.de> wrote:

> On Fri, 18 Jan 2013 12:37:17 +0100
> Borislav Petkov <bp@alien8.de> wrote:
> 
> (updating Matthew's email as per MAINTAINERS)
> 
> > On Thu, Jan 17, 2013 at 07:40:44PM -0600, Leonid Isaev wrote:
> > > Arrh, modprobe still does not exit cleanly with this...
> > 
> > As I said already above:
> > 
> > >> That's correct - we say ENODEV on your CPU which supports hardware
> > >> P-states and hand off to acpi-cpufreq which has that functionality
> > >> now.
> > 
> > It is supposed to work that way: we return an error from the
> > powernow-k8 init function so that it doesn't load but hand off to
> > acpi-cpufreq so that it gets loaded instead.
> > 
> > > > But, we also have the CPU autoprobing deal:
> > > > 
> > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=644e9cbbe3fc032cc92d0936057e166a994dc246
> > > > 
> > > > so, *actually*, powernow-k8 should be loaded by default. I dunno,
> > > > maybe upgrade udev on your distro?
> > > 
> > > Udev 196 and 197 + linux <= 3.6.11 yield correct CPU autoprobing.
> > > However, udev 197 + linux 3.7.2 do not. I haven't tested udev 196
> > > with 3.7.2 though, but it does not look like a udev issue.
> > 
> > Hmm, I'll bet this has something to do with the fact that HW_PSTATE is
> > in another CPUID function on AMD than on Intel and udev doesn't see
> > that bit to load acpi-cpufreq automatically.
> 
> But the acpi-cpufreq does not export it's dependency on some CPUID
> flags, since it is an _ACPI_ module. Shouldn't the load be triggered
> while parsing the ACPI tree instead?
> 
> $ /sbin/modinfo drivers/cpufreq/acpi-cpufreq.ko | grep alias
> alias:          acpi
> 
> $ /sbin/modinfo drivers/cpufreq/powernow-k8.ko | grep alias
> alias:          x86cpu:vendor:0002:family:000F:model:*:feature:*
> 
> How does ArchLinux loads acpi-cpufreq on Intel CPUs? It should now be
> the same mechanism on AMD. Or does it have acpi-cpufreq somehow
> hard-coded in the scripts for GenuineIntel?

In both cases Intel and AMD we rely on the kernel/udev autoprobing to insert
correct CPU and KVM drivers, i.e. there are no custom scripts or manual loading
of modules via systemd. However, in Intel's case acpi_cpufreq is loaded
correctly (and always has been). Indeed, on an Intel core2duo:
 $ dmesg | grep -i cpufreq
[    9.005851] ACPI: Requesting acpi_cpufreq

> 
> Regards,
> Andre.

Sincerely,
L.

-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2013-01-18 17:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130115224755.085aa6b7@bluemoon>
     [not found] ` <CAG-2HqWPOYKVCj-Z=z_1e=mE6b6z9hMYFJzHf2GYAmTwQovN0A@mail.gmail.com>
     [not found]   ` <20130116131725.4e590c34@bluemoon>
2013-01-16 20:37     ` [arch-general] powernow-k8 fails to load with linux 3.7.2 Tom Gundersen
2013-01-16 22:33       ` Rafael J. Wysocki
2013-01-16 23:17         ` Borislav Petkov
     [not found]           ` <20130116181600.4c48ee3b@bluemoon>
2013-01-17  9:46             ` Borislav Petkov
2013-01-17 10:34               ` Tom Gundersen
2013-01-18  1:27                 ` Leonid Isaev
2013-01-18  1:40               ` Leonid Isaev
2013-01-18 11:37                 ` Borislav Petkov
2013-01-18 12:32                   ` André Przywara
2013-01-18 15:17                     ` Matthew Garrett
2013-01-18 15:26                       ` Borislav Petkov
2013-01-18 15:32                         ` Matthew Garrett
2013-01-18 17:10                           ` Borislav Petkov
2013-01-18 17:17                             ` Matthew Garrett
2013-01-19 12:08                       ` Borislav Petkov
2013-01-21  5:14                         ` Leonid Isaev
2013-01-21 10:54                           ` Borislav Petkov
2013-01-18 17:13                     ` Leonid Isaev [this message]
2013-01-18 16:59                   ` Leonid Isaev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130118111342.3d17fef1@bluemoon \
    --to=lisaev@umail.iu.edu \
    --cc=andre@andrep.de \
    --cc=bp@alien8.de \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=rjw@sisk.pl \
    --cc=teg@jklm.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.