|Summary:||powernow-k8 not working w/ 2.6.19+ kernels|
|Product:||Gentoo Linux||Reporter:||Joshua Hoblitt <j_gentoo>|
|Component:||[OLD] Core system||Assignee:||Daniel Drake (RETIRED) <dsd>|
|Severity:||normal||CC:||duaneg, j_gentoo, kernel|
|Package list:||Runtime testing required:||---|
2.6.21 config w/o CONFIG_X86_POWERNOW_K8
2.6.21 config w/ CONFIG_ACPI_PROCESSOR & CONFIG_X86_POWERNOW_K8
Description Joshua Hoblitt 2007-05-15 00:57:14 UTC
This is on a Tyan S2892 motherboard with Opteron 285 CPUs - I recall having to have flashed the BIOS to get powernow working and I believe the current BIOS rev is 2.03. I am also experiencing this issue on a Tyan S2927 motherboard with 2220 CPUs but I have never attempted to boot with system with a kernel older that 2.6.19 so I have never confirmed that the bios on this system correctly enables powernow (although I have tried flashing the bios to the latest rev.). Powernow does function with 2.6.17-gentoo-r8 but not with 2.6.19-gentoo-r5, 2.6.20-gentoo-r8, or 2.6.21-gentoo. I'm not sure exactly when the regression was introduced. The relevant dmesg text is: powernow-k8: Found 4 Dual Core AMD Opteron(tm) Processor 285 processors (version 2.00.00) powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure Reproducible: Always Portage 126.96.36.199 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r2, 2.6.21-gentoo x86_64) ================================================================= System uname: 2.6.21-gentoo x86_64 Dual Core AMD Opteron(tm) Processor 285 Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 14 May 2007 23:30:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/init.d /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="digest distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/src/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi amd64 apache2 bash-completion berkdb bitmap-fonts cli cracklib crypt cups dri firefox fortran gdbm gnome gnome2 gnutls gpm gtk gtk2 iconv imap ipv6 isdnlog libg++ mbox midi ncurses nls nptl ntpl pam pcre perl pic ppds pppd python readline reflection samba session spl ssl sysfs tcpd truetype-fonts type1-fonts unicode vim-with-x xattr xinerama xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="rage128" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 2 Duane Griffin 2007-05-15 11:51:01 UTC
Looks like it might be similar to this: http://bugzilla.kernel.org/show_bug.cgi?id=8075 The comments there suggest it is caused by PowerNow requiring ACPI to be loaded first. I see you have PowerNow compiled into the kernel and ACPI as a module. Could you try reversing that, so: CONFIG_X86_POWERNOW_K8=m CONFIG_X86_ACPI_CPUFREQ=y That way ACPI should be loaded first, I believe.
Comment 3 Thomas Anderson (tanderson) (RETIRED) 2007-05-15 12:13:29 UTC
Maybe this is a stupid thing to say, but I had the same problem, and it was fixed by turning "Cool'n'Quiet" on in the BIOS. And I thought the same thing(about ACPI) when I had the problem. It doesn't really matter what it is configured like.
Comment 4 Joshua Hoblitt 2007-05-15 21:51:44 UTC
(In reply to comment #3) > Maybe this is a stupid thing to say, but I had the same problem, and it was > fixed by turning "Cool'n'Quiet" on in the BIOS. Powernow is enable in the bios on all of the systems affected by this bug, it was the first thing I checked. And as I said, it was prevously working on these systems.
Comment 5 Joshua Hoblitt 2007-05-15 23:52:13 UTC
(In reply to comment #2) > Looks like it might be similar to this: > http://bugzilla.kernel.org/show_bug.cgi?id=8075 > > The comments there suggest it is caused by PowerNow requiring ACPI to be loaded > first. I see you have PowerNow compiled into the kernel and ACPI as a module. > Could you try reversing that, so: > > CONFIG_X86_POWERNOW_K8=m > CONFIG_X86_ACPI_CPUFREQ=y > > That way ACPI should be loaded first, I believe. Nice catch! Compling them both in fixes the problem. As does building them both as modules and then loading powernow-k8 by hand as the ACPI module has already been loaded. This is a kconfig bug as you should not be able to select CONFIG_X86_POWERNOW_K8=y while CONFIG_X86_ACPI_CPUFREQ=m
Comment 6 Joshua Hoblitt 2007-05-16 01:17:34 UTC
I just sent a possible patch to LKML: http://lkml.org/lkml/2007/5/15/352
Comment 7 Daniel Drake (RETIRED) 2007-05-16 02:30:58 UTC
Duane, what made you suggest CONFIG_X86_ACPI_CPUFREQ in the comments above? As far as I can see, the upstream bug only references the ACPI processor driver (CONFIG_ACPI_PROCESSOR) as a dependency. Curiosity aside, the most recent comments here indicate that is a fix. Actually, I suspect it there may be more to it. Joshua, what happens if you try the following configuration: CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K8=n (no, that's not a typo) [Sidenote, I think if the grounds for that patch are correct, it's not a complete fix: the module itself should be modified to depend on the X86_ACPI_CPUFREQ object too, so that modprobe loads them in the right order]
Comment 8 Duane Griffin 2007-05-16 11:23:03 UTC
(In reply to comment #7) > Duane, what made you suggest CONFIG_X86_ACPI_CPUFREQ in the comments above? As > far as I can see, the upstream bug only references the ACPI processor driver > (CONFIG_ACPI_PROCESSOR) as a dependency. To be honest, it was a mistake. I didn't pick up on the "ACPI processor module" comment and assumed that ACPI_CPUFREQ was what was needed. > Curiosity aside, the most recent comments here indicate that is a fix. Looking at Joshua's config again it seems the ACPI processor module is being built as a module too. So actually I think CONFIG_X86_ACPI_CPUFREQ=y is just papering over the problem. Looking at the Kconfig and source it seems the controlling factor is actually X86_POWERNOW_K8_ACPI. This is an invisible config option with the following dependencies: depends on X86_POWERNOW_K8 && ACPI_PROCESSOR depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m) If it is defined powernow-k8.c calls acpi_processor_register_performance during initialisation. If not then it doesn't (and hence won't work on SMP). The current situation is certainly rather confusing, but I'm not sure what the correct fix is. An easy solution would be to make X86_POWERNOW_K8 depend on ACPI_PROCESSOR, but presumably that is not desirable. Maybe the best idea would be a warning in the X86_POWERNOW_K8 help text. How about something like this: "ACPI support is required for non-UP systems and requires ACPI_PROCESSOR to be selected. If ACPI_PROCESSOR is compiled as a module then this option must be too in order for ACPI support to be available."
Comment 9 Daniel Drake (RETIRED) 2007-05-16 12:15:10 UTC
Let's wait for the results from comment #7 to get a better understanding. There are 2 possibilities: X86_ACPI_CPUFREQ's direct dependency on ACPI_PROCESSOR causes the processor module to be loaded which makes powernow-k8 work later on or X86_ACPI_CPUFREQ drives the performance states through generic ACPI tables and powernow-k8 is not needed at all
Comment 10 Joshua Hoblitt 2007-05-16 21:44:26 UTC
(In reply to comment #7) > Actually, I suspect it there may be more to it. Joshua, what happens if you try > the following configuration: > > CONFIG_X86_ACPI_CPUFREQ=y > CONFIG_X86_POWERNOW_K8=n (no, that's not a typo) OK - with my config as: # # CPUFreq processor drivers # # CONFIG_X86_POWERNOW_K8 is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_ACPI_CPUFREQ=y No CPU scaling is enabled: ls /sys/devices/system/cpu/cpu0/cpufreq ls: cannot access /sys/devices/system/cpu/cpu0/cpufreq: No such file or directory
Comment 11 Joshua Hoblitt 2007-05-16 21:45:23 UTC
Created attachment 119484 [details] 2.6.21 config w/o CONFIG_X86_POWERNOW_K8 # CONFIG_X86_POWERNOW_K8 is not set CONFIG_X86_ACPI_CPUFREQ=y
Comment 12 Joshua Hoblitt 2007-05-16 21:55:11 UTC
CONFIG_ACPI_PROCESSOR=y . . # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=m # CONFIG_X86_ACPI_CPUFREQ is not set I get frequency scaling: ls -lad /sys/devices/system/cpu/cpu0/cpufreq/ drwxr-xr-x 3 root root 0 May 16 15:04 /sys/devices/system/cpu/cpu0/cpufreq/ So I believe that CONFIG_X86_POWERNOW_K8 needs to depend on CONFIG_ACPI_PROCESSOR on this system.
Comment 13 Joshua Hoblitt 2007-05-16 21:56:08 UTC
Created attachment 119485 [details] 2.6.21 config w/ CONFIG_ACPI_PROCESSOR & CONFIG_X86_POWERNOW_K8
Comment 14 Joshua Hoblitt 2007-05-16 22:51:46 UTC
Created attachment 119488 [details] dep fix Is the fix this simple?
Comment 15 Daniel Drake (RETIRED) 2007-05-16 23:36:06 UTC
No, because on some configurations powernow-k8 can run just fine without acpi-processor.
Comment 16 Joshua Hoblitt 2007-05-30 01:17:26 UTC
Dave Jones has accepted a patch that should appear (someday) in cpufreq.git.
Comment 17 Daniel Drake (RETIRED) 2007-05-30 02:52:07 UTC
Please don't close the bug until it is fixed in Gentoo kernels.
Comment 18 Daniel Drake (RETIRED) 2007-06-12 13:23:40 UTC
Fixed in gentoo-sources-2.6.21-r3