powernow-k8 fails to load with linux 3.7.2
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): 20130115224755.085aa6b7@bluemoon
A message that is not in the archive (sent off-list or not yet received): CAG-2HqWPOYKVCj-Z=z_1e=mE6b6z9hMYFJzHf2GYAmTwQovN0A@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): 20130116131725.4e590c34@bluemoon
[dropped arch-general, added kernel folks]
Quoted 9 lines · Leonid Isaev
Quoted 6 lines · On Wed, 16 Jan 2013 11:10:19 +0100 Tom Gundersen <[email protected]> wrote:
Quoted 2 lines · Leonid Isaev
I just installed linux 3.7.2 from [testing] on an AMD system and
noticed that powernow-k8 is not loaded.Probably due to this:
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e1f0b8e9b04a262834ed1>.
[...]
Quoted 11 lines
Quoted 2 lines
Hm, I thought
acpi_cpufreqshould have been loaded instead, no idea why that does not happen for you. Could you try loading it manually?Neither
acpi_cpufreqnorpowernow_k8is loaded automatically which of course leads to failure of all custom units configuring ondemand governor via sysfs. Manually modprob'ingacpi_cpufreqdoes work and indeed properly scales down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided_PSDdata".So, if the cpufreq driver works OK for other AMD users, I'll happily blame asus...
Matthew, Andre, Rafael,
Is what Leonid experinces above expected behavior or is this a bug? He is using stock Arch kernel, which is almost vanilla 3.7.3 (see [0] for the applied patches, nothing looks relevant).
Cheers,
Tom
[0]: <https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux>
Quoted 24 lines · Tom Gundersen
[dropped arch-general, added kernel folks]
Quoted 9 lines · Leonid Isaev
Quoted 6 lines · On Wed, 16 Jan 2013 11:10:19 +0100 Tom Gundersen <[email protected]> wrote:
Quoted 2 lines · Leonid Isaev
I just installed linux 3.7.2 from [testing] on an AMD system and
noticed that powernow-k8 is not loaded.Probably due to this:
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e1f0b8e9b04a262834ed1>.[...]
Quoted 9 lines
Quoted 2 lines
Hm, I thought
acpi_cpufreqshould have been loaded instead, no idea why that does not happen for you. Could you try loading it manually?Neither
acpi_cpufreqnorpowernow_k8is loaded automatically which of course leads to failure of all custom units configuring ondemand governor via sysfs. Manually modprob'ingacpi_cpufreqdoes work and indeed properly scales down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided_PSDdata".
Quoted 8 lines
Quoted 2 lines
So, if the cpufreq driver works OK for other AMD users, I'll happily blame asus...
Matthew, Andre, Rafael,
Is what Leonid experinces above expected behavior or is this a bug? He is using stock Arch kernel, which is almost vanilla 3.7.3 (see [0] for the applied patches, nothing looks relevant).
Well, I was afraid that something like this would happen after the recent AMD cpufreq changes.
Andre, do we have a clear way to address these problems?
Rafael
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
[ fixup Andre's address. ]
Quoted 2 lines · Rafael J. Wysocki
Quoted 2 lines
down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided
_PSDdata".
That just says that BIOS has crappy data and we're using our own.
Quoted 4 lines
Well, I was afraid that something like this would happen after the recent AMD cpufreq changes.
Andre, do we have a clear way to address these problems?
I'm working on a patch (see thread at
http://marc.info/?l=linux-pm&m=135791578516584&w=2) that should take care of really fixing handoff to acpi_cpufreq from powernow-k8, need to sort out some stuff first though.
Btw, the handoff from powernow-k8 to acpi_cpufreq works on my systems, but I haven't tested 3.7.2 so maybe we're missing some patches there. Leonid, can you send your config pls?
Thanks.
Signature · 2 lines
Regards/Gruss, Boris.
A message that is not in the archive (sent off-list or not yet received): 20130116181600.4c48ee3b@bluemoon
Quoted 10 lines · Leonid Isaev
Quoted 7 lines
[ fixup Andre's address. ]
Quoted 2 lines · Rafael J. Wysocki
Quoted 2 lines
down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided
_PSDdata".That just says that BIOS has crappy data and we're using our own.
OK. Yes, my BIOS is broken, so I thought it was the reason why autoloading does not work.
Hmm, come to think of it, we're issuing this message on SMP on *all* AMDs with HW_PSTATE. Andre, remind me again why we're doing this? We're basically saying that we're overriding ACPI data but we still read it out from acpi_perf_data and use *that* data to prepare the frequencies table. What am I missing?
Quoted 1 line
To be more precise: "modprobe powernow-k8" returns a "no such device" error,
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.
Quoted 7 lines
but in kernel logs I see that acpi-cpufreq is indeed loaded:
-------Jan 15 22:42:19 metal-0 kernel: [ 534.003995] acpi-cpufreq: overriding BIOS provided _PSD data Jan 15 22:42:32 metal-0 kernel: [ 547.122695] powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. Jan 15 22:42:45 metal-0 kernel: [ 559.623068] powernow-k8: this CPU is not
Quoted 6 lines
supported anymore, using acpi-cpufreq instead.
-------
(the CPU in question is phenom II x4 955). However, this is only after I attempt to _manually_ load powernow-k8 (the timestamps in [...] are ~6 mins after boot is completed). So the above-mentioned handoff seems to work, but please find attached my kernel config.
Ok, this is maybe the issue. What used to load powernow-k8 on your distro before? Because basically it's enough if some script did 'modprobe powernow-k8' for the handoff to just work.
But, we also have the CPU autoprobing deal:
so, *actually*, powernow-k8 should be loaded by default. I dunno, maybe upgrade udev on your distro?
Btw, your config looks fine:
CONFIG_X86_POWERNOW_K8=mCONFIG_X86_ACPI_CPUFREQ=m
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 37 lines · Borislav Petkov
Quoted 10 lines · Leonid Isaev
Quoted 7 lines
[ fixup Andre's address. ]
Quoted 2 lines · Rafael J. Wysocki
Quoted 2 lines
down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided
_PSDdata".That just says that BIOS has crappy data and we're using our own.
OK. Yes, my BIOS is broken, so I thought it was the reason why autoloading does not work.
Hmm, come to think of it, we're issuing this message on SMP on *all* AMDs with
HW_PSTATE. Andre, remind me again why we're doing this? We're basically saying that we're overriding ACPI data but we still read it out fromacpi_perf_dataand use *that* data to prepare the frequencies table. What am I missing?Quoted 1 line
To be more precise: "modprobe powernow-k8" returns a "no such device" error,
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.
Quoted 7 lines
but in kernel logs I see that acpi-cpufreq is indeed loaded:
-------Jan 15 22:42:19 metal-0 kernel: [ 534.003995] acpi-cpufreq: overriding BIOS provided _PSD data Jan 15 22:42:32 metal-0 kernel: [ 547.122695] powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. Jan 15 22:42:45 metal-0 kernel: [ 559.623068] powernow-k8: this CPU is notQuoted 6 lines
supported anymore, using acpi-cpufreq instead.
-------
(the CPU in question is phenom II x4 955). However, this is only after I attempt to _manually_ load powernow-k8 (the timestamps in [...] are ~6 mins after boot is completed). So the above-mentioned handoff seems to work, but please find attached my kernel config.
Quoted 7 lines
Ok, this is maybe the issue. What used to load powernow-k8 on your distro before? Because basically it's enough if some script did 'modprobe powernow-k8' for the handoff to just work.
But, we also have the CPU autoprobing deal:
Arch relies entirely on the CPU autoprobing, there are no scripts modprobing things at boot.
Quoted 2 lines
so, *actually*, powernow-k8 should be loaded by default. I dunno, maybe upgrade udev on your distro?
Assuming Leonid's system is up-to-date, Arch ships the most recent udev version (197).
Cheers,
Tom
Sorry for a late reply...
Quoted 43 lines · On Thu, 17 Jan 2013 11:34:22 +0100 Tom Gundersen <[email protected]> wrote:
Quoted 42 lines · Borislav Petkov
Quoted 10 lines · Leonid Isaev
Quoted 7 lines
[ fixup Andre's address. ]
Quoted 2 lines · Rafael J. Wysocki
Quoted 2 lines
down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided
_PSDdata".That just says that BIOS has crappy data and we're using our own.
OK. Yes, my BIOS is broken, so I thought it was the reason why autoloading does not work.
Hmm, come to think of it, we're issuing this message on SMP on *all* AMDs with
HW_PSTATE. Andre, remind me again why we're doing this? We're basically saying that we're overriding ACPI data but we still read it out fromacpi_perf_dataand use *that* data to prepare the frequencies table. What am I missing?Quoted 2 lines
To be more precise: "modprobe powernow-k8" returns a "no such device" error,
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.
Quoted 7 lines
but in kernel logs I see that acpi-cpufreq is indeed loaded:
-------Jan 15 22:42:19 metal-0 kernel: [ 534.003995] acpi-cpufreq: overriding BIOS provided _PSD data Jan 15 22:42:32 metal-0 kernel: [ 547.122695] powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. Jan 15 22:42:45 metal-0 kernel: [ 559.623068] powernow-k8: this CPU isQuoted 6 lines
not supported anymore, using acpi-cpufreq instead.
-------
(the CPU in question is phenom II x4 955). However, this is only after I attempt to _manually_ load powernow-k8 (the timestamps in [...] are ~6 mins after boot is completed). So the above-mentioned handoff seems to work, but please find attached my kernel config.Ok, this is maybe the issue. What used to load powernow-k8 on your distro before? Because basically it's enough if some script did 'modprobe powernow-k8' for the handoff to just work.
Quoted 6 lines
Quoted 3 lines
But, we also have the CPU autoprobing deal:
Arch relies entirely on the CPU autoprobing, there are no scripts modprobing things at boot.
That's right, processor drivers used to be automatically loaded alongside with kvm and kvm_amd. Now, only the KVM stuff is loaded.
Quoted 6 lines
Quoted 3 lines
so, *actually*, powernow-k8 should be loaded by default. I dunno, maybe upgrade udev on your distro?
Assuming Leonid's system is up-to-date, Arch ships the most recent udev version (197).
Yes, the system is fully updated running systemd/udev 197.
Quoted 4 lines
Cheers,
Tom
Thank you,
L.
Signature · 3 lines
Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Quoted 38 lines · On Thu, 17 Jan 2013 10:46:48 +0100 Borislav Petkov <[email protected]> wrote:
Quoted 10 lines · Leonid Isaev
Quoted 7 lines
[ fixup Andre's address. ]
Quoted 2 lines · Rafael J. Wysocki
Quoted 2 lines
down the frequancy, but is accompanied by an info-level kernel message "acpi-cpufreq: overriding BIOS provided
_PSDdata".That just says that BIOS has crappy data and we're using our own.
OK. Yes, my BIOS is broken, so I thought it was the reason why autoloading does not work.
Hmm, come to think of it, we're issuing this message on SMP on *all* AMDs with
HW_PSTATE. Andre, remind me again why we're doing this? We're basically saying that we're overriding ACPI data but we still read it out fromacpi_perf_dataand use *that* data to prepare the frequencies table. What am I missing?Quoted 2 lines
To be more precise: "modprobe powernow-k8" returns a "no such device" error,
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.
Quoted 7 lines
but in kernel logs I see that acpi-cpufreq is indeed loaded:
-------Jan 15 22:42:19 metal-0 kernel: [ 534.003995] acpi-cpufreq: overriding BIOS provided _PSD data Jan 15 22:42:32 metal-0 kernel: [ 547.122695] powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. Jan 15 22:42:45 metal-0 kernel: [ 559.623068] powernow-k8: this CPU isQuoted 6 lines
not supported anymore, using acpi-cpufreq instead.
-------
(the CPU in question is phenom II x4 955). However, this is only after I attempt to _manually_ load powernow-k8 (the timestamps in [...] are ~6 mins after boot is completed). So the above-mentioned handoff seems to work, but please find attached my kernel config.
Quoted 3 lines
Ok, this is maybe the issue. What used to load powernow-k8 on your distro before? Because basically it's enough if some script did 'modprobe powernow-k8' for the handoff to just work.
Arrh, modprobe still does not exit cleanly with this...
Quoted 7 lines
But, we also have the CPU autoprobing deal:
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.
I don't know if it matters, but I also have AMD microcode "0x10000c8", albeit it didn't cause problems with 3.6.11...
Quoted 8 lines
Btw, your config looks fine:
CONFIG_X86_POWERNOW_K8=mCONFIG_X86_ACPI_CPUFREQ=mThanks.
Sincerely,
L.
Signature · 3 lines
Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Quoted 1 line · Leonid Isaev
Arrh, modprobe still does not exit cleanly with this...
As I said already above:
Quoted 3 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 6 lines
But, we also have the CPU autoprobing deal:
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.
Before I go and install archlinux here, where can I get the udev sources which are in your archlinux installation to stare at them a little? :) Especially the cpu autoprobing part which supposedly uses the cpuid kernel driver.
Quoted 2 lines
I don't know if it matters, but I also have AMD microcode "
0x10000c8", albeit it didn't cause problems with 3.6.11...
Nah, microcode doesn't have anything to do with it.
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--On Fri, 18 Jan 2013 12:37:17 +0100
Borislav Petkov <[email protected]> wrote:
(updating Matthew's email as per MAINTAINERS)
Quoted 20 lines · Leonid Isaev
Quoted 1 line
Arrh, modprobe still does not exit cleanly with this...
As I said already above:
Quoted 3 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 6 lines
But, we also have the CPU autoprobing deal:
so, *actually*, powernow-k8 should be loaded by default. I dunno, maybe upgrade udev on your distro?
Quoted 7 lines
Quoted 3 lines
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_PSTATEis 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?
Regards,
Andre.
Can you try this (entirely untested) patch?
(quoted diff) +0 -0
b/drivers/cpufreq/acpi-cpufreq.c
index 0d048f6..7b0d49d 100644
drivers/cpufreq/acpi-cpufreq.c +7 -0
@@ -1030,4 +1030,11 @@ MODULE_PARM_DESC(acpi_pstate_strict,late_initcall (acpi_cpufreq_init);module_exit (acpi_cpufreq_exit); +static const struct x86_cpu_id acpi_cpufreq_ids[] = { +X86_FEATURE_MATCH (X86_FEATURE_ACPI ), +X86_FEATURE_MATCH (X86_FEATURE_HW_PSTATE ), + {} +}; +MODULE_DEVICE_TABLE (x86cpu, acpi_cpufreq_ids); +MODULE_ALIAS ("acpi" );
Quoted 8 lines · Matthew Garrett
Can you try this (entirely untested) patch?
drivers/cpufreq/acpi-cpufreq.c +0
-0
drivers/cpufreq/acpi-cpufreq.c MODULE_PARM_DESC(acpi_pstate_strict, · line 1036
Quoted 7 lines
drivers/cpufreq/acpi-cpufreq.c +4
-0@@ -1030,4 +1030,11 @@ MODULE_PARM_DESC(acpi_pstate_strict,late_initcall (acpi_cpufreq_init);module_exit (acpi_cpufreq_exit); +static const struct x86_cpu_id acpi_cpufreq_ids[] = { +X86_FEATURE_MATCH (X86_FEATURE_ACPI ), +X86_FEATURE_MATCH (X86_FEATURE_HW_PSTATE ), + {}
Yep, that should be one way to fix it.
One other fix IMHO would be if udev is looking at CPUID bits, to teach it to check the proper P-States feature bits on Intel and AMD:
On Intel: CPUID_0x00000001[ECX] bit 7
On AMD : CPUID_0x80000007[EDX] bit 7
AFAICT.
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 4 lines · Borislav Petkov
Yep, that should be one way to fix it.
One other fix IMHO would be if udev is looking at CPUID bits, to teach it to check the proper P-States feature bits on Intel and AMD:
I think it makes more sense to use the existing CPU modaliases than to special-case it in udev.
Quoted 8 lines · Matthew Garrett
Quoted 4 lines · Borislav Petkov
Yep, that should be one way to fix it.
One other fix IMHO would be if udev is looking at CPUID bits, to teach it to check the proper P-States feature bits on Intel and AMD:
I think it makes more sense to use the existing CPU modaliases than to special-case it in udev.
Well, actually, those CPUID bits are there for exactly that reason: to query them and enable software features. And this is one of the reasons CPUID is a ring 3 instruction: so that even userspace can use it.
So, in a perfect world, udev should simply run CPUID, check the respective bits, and, if they're set, load the respective driver. That is, if it doesn't do it already.
No need for additional code glue in the kernel or anywhere else.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 9 lines · Borislav Petkov
Well, actually, those CPUID bits are there for exactly that reason: to query them and enable software features. And this is one of the reasons CPUID is a ring 3 instruction: so that even userspace can use it.
So, in a perfect world, udev should simply run CPUID, check the respective bits, and, if they're set, load the respective driver. That is, if it doesn't do it already.
No need for additional code glue in the kernel or anywhere else.
We already have the additional code in the kernel - it means we can add modaliases when new functionality gets added to the kernel, instead of having to update udev as well. We /could/ have udev use outb and inb to identify PCI devices as well, but it seems more reasonable to use the information the kernel already has and exposes :)
Quoted 9 lines · Matthew Garrett
Can you try this (entirely untested) patch?
drivers/cpufreq/acpi-cpufreq.c +0
-0@@ -1030,4 +1030,11 @@ MODULE_PARM_DESC(acpi_pstate_strict,late_initcall (acpi_cpufreq_init);
drivers/cpufreq/acpi-cpufreq.c MODULE_PARM_DESC(acpi_pstate_strict, · line 1040
Quoted 10 lines
drivers/cpufreq/acpi-cpufreq.c +7
-0module_exit (acpi_cpufreq_exit); +static const struct x86_cpu_id acpi_cpufreq_ids[] = { +X86_FEATURE_MATCH (X86_FEATURE_ACPI ), +X86_FEATURE_MATCH (X86_FEATURE_HW_PSTATE ), + {} +}; +MODULE_DEVICE_TABLE (x86cpu, acpi_cpufreq_ids); +MODULE_ALIAS ("acpi" );
Leonid, can you try Matthew's patch?
This is adding the additional cpufreatures aliases:
alias: x86cpu:vendor:*:family:*:model:*:feature:*00E8* alias: x86cpu:vendor:*:family:*:model:*:feature:*0016*
and since powernow-k8 used to load on 3.6-stable, it probably happened because the 0xe8 feature and since 3.7 moved it to acpi-cpufreq, this patch should actually fix it.
Thanks.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 25 lines · On Sat, 19 Jan 2013 13:08:14 +0100 Borislav Petkov <[email protected]> wrote:
Quoted 9 lines · Matthew Garrett
Can you try this (entirely untested) patch?
drivers/cpufreq/acpi-cpufreq.c +0
-0@@ -1030,4 +1030,11 @@ MODULE_PARM_DESC(acpi_pstate_strict,late_initcall (acpi_cpufreq_init);drivers/cpufreq/acpi-cpufreq.c MODULE_PARM_DESC(acpi_pstate_strict, · line 1040
Quoted 10 lines
drivers/cpufreq/acpi-cpufreq.c +7
-0module_exit (acpi_cpufreq_exit); +static const struct x86_cpu_id acpi_cpufreq_ids[] = { +X86_FEATURE_MATCH (X86_FEATURE_ACPI ), +X86_FEATURE_MATCH (X86_FEATURE_HW_PSTATE ), + {} +}; +MODULE_DEVICE_TABLE (x86cpu, acpi_cpufreq_ids); +MODULE_ALIAS ("acpi" );Leonid, can you try Matthew's patch?
This is adding the additional cpufreatures aliases:
Quoted 9 lines
alias: x86cpu:vendor:*:family:*:model:*:feature:*00E8* alias: x86cpu:vendor:*:family:*:model:*:feature:*0016*and since powernow-k8 used to load on 3.6-stable, it probably happened because the
0xe8feature and since 3.7 moved it to acpi-cpufreq, this patch should actually fix it.Thanks.
Matthew and Borislav, thanks a lot for the patch and explanation!
I applied the above patch on top of linux 3.7.3 -- it does generate the aliases and fixes the autoprobing issue, at least on my AMD machine. Should we expect it in 3.7.4 or 3.8? Otherwise, I'll forward it to archlinux devel ML to be possibly included in current -stable kernel. Also, Borislav, this patch is not in your patch series, is it?
Thanks again,
L.
Signature · 3 lines
Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Quoted 7 lines · Leonid Isaev
Matthew and Borislav, thanks a lot for the patch and explanation!
I applied the above patch on top of linux 3.7.3 -- it does generate the aliases and fixes the autoprobing issue, at least on my AMD machine. Should we expect it in 3.7.4 or 3.8? Otherwise, I'll forward it to archlinux devel ML to be possibly included in current -stable kernel. Also, Borislav, this patch is not in your patch series, is it?
Yeah, it's not.
Matthew, care to write a proper commit message with your SOB and Leonid's Tested-by pls?
Then Rafael could take it for 3.8 and tag it for 3.7-stable, methinks.
Leonid, thanks for testing.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 40 lines · On Fri, 18 Jan 2013 13:32:33 +0100 André Przywara <[email protected]> wrote:
On Fri, 18 Jan 2013 12:37:17 +0100
Borislav Petkov <[email protected]> wrote:(updating Matthew's email as per
MAINTAINERS)Quoted 20 lines · Leonid Isaev
Quoted 1 line
Arrh, modprobe still does not exit cleanly with this...
As I said already above:
Quoted 3 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 6 lines
But, we also have the CPU autoprobing deal:
so, *actually*, powernow-k8 should be loaded by default. I dunno, maybe upgrade udev on your distro?
Quoted 7 lines
Quoted 3 lines
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_PSTATEis 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
Quoted 6 lines
$ /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
Quoted 3 lines
Regards,
Andre.
Sincerely,
L.
Signature · 3 lines
Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Quoted 24 lines · On Fri, 18 Jan 2013 12:37:17 +0100 Borislav Petkov <[email protected]> wrote:
Quoted 1 line · Leonid Isaev
Arrh, modprobe still does not exit cleanly with this...
As I said already above:
Quoted 3 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 6 lines
But, we also have the CPU autoprobing deal:
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.
Quoted 8 lines
Hmm, I'll bet this has something to do with the fact that
HW_PSTATEis in another CPUID function on AMD than on Intel and udev doesn't see that bit to load acpi-cpufreq automatically.Before I go and install archlinux here, where can I get the udev sources which are in your archlinux installation to stare at them a little? :) Especially the cpu autoprobing part which supposedly uses the cpuid kernel driver.
They are vanilla systemd-197
(http://www.freedesktop.org/software/systemd/systemd-197.tar.xz) with only 1 dbus-related patch
(https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/systemd).
Quoted 8 lines
Quoted 3 lines
I don't know if it matters, but I also have AMD microcode "
0x10000c8", albeit it didn't cause problems with 3.6.11...Nah, microcode doesn't have anything to do with it.
Thanks.
Thanks,
L.
Signature · 3 lines
Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D