Bugzilla Bug 178585

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 2.1.2.2 (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

Created an attachment (id=119291) [details]
2.6.21 config

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.

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.

(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.

(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

I just sent a possible patch to LKML:

http://lkml.org/lkml/2007/5/15/352

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]

(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."

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

(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

Created an attachment (id=119484) [details]
2.6.21 config w/o CONFIG_X86_POWERNOW_K8

# CONFIG_X86_POWERNOW_K8 is not set
CONFIG_X86_ACPI_CPUFREQ=y

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.

Created an attachment (id=119485) [details]
2.6.21 config w/ CONFIG_ACPI_PROCESSOR & CONFIG_X86_POWERNOW_K8

Created an attachment (id=119488) [details]
dep fix

Is the fix this simple?

No, because on some configurations powernow-k8 can run just fine without
acpi-processor.

Dave Jones has accepted a patch that should appear (someday) in cpufreq.git.

Please don't close the bug until it is fixed in Gentoo kernels.

Fixed in gentoo-sources-2.6.21-r3