The following reply was made to PR port-i386/26239; it has been noted by GNATS.

From: RUMI Szabolcs <rumi@rtfm.hu>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: port-i386/26239
Date: Mon, 21 Mar 2005 23:41:58 +0100

 This is an updated version of my posting to port-i386@netbsd.org.
 I'm decorating the obsoleted sections with */**/*** marks, and added
 some updated information below. The original posting follows:
 
 -----8<----------------------------------
 
 I have reviewed the patch proposed by Martin Vegiard to support
 the AMD PowerNow! CPU frequency scaling technology and I have
 added support for CPUID-based detection of CPU support, fixed some
 minor problems, and altered the kernel messages output by the code.
 
 Here are the results:
 
 CVS diff of my changes against netbsd-current (as of 01.16.2005):
 http://quasar.dynaweb.hu/~rumi/powernow/powernow_050116.diff
 
 The original patch by Martin Vegiard against 2.0G:
 http://quasar.dynaweb.hu/~rumi/powernow/powernow_k7-vegiard.patch
 
 A quick'n'dirty patch against estd-r3 to support PowerNow:
 http://quasar.dynaweb.hu/~rumi/powernow/estd_powernow.patch
 
 (*) The estd tarball can be found at (not in pkgsrc, dunno why):
 http://www.elektro-eel.org/estd-netbsd.html
 
 Related PR numbers: 26239, 26423(*)
 
 There are two strange issues:
 
 1.) Some braindead BIOSes (for Acer/ALi chipsets as it seems)
 report CPU signatures that start at 0x700, and this will never
 match the actual signatures because as far as I could tell, the
 '7' would stand there for the CPU Family which is actually 6 for
 the Athlon (K7) series. This means that for my Athlon XP-M,
 the signature 0x781 is expected by the BIOS list, but the CPU
 correctly returns 0x681. These do not match and with the Vegiard
 patch this produces an error so I have added a hack for it in
 my code. (**)
 
 2.) These BIOSes also seem to supply a bogus/incomplete frequency
 list. In my case the machine has an Athlon XP-M 2000+ CPU which
 operates at a maximum of 1666MHz but the frequency list only
 contains values up to 1396Mhz. All supplied values work, but
 the CPU cannot be set to it's maximum frequency by PowerNow,
 only up to 1396Mhz. Maybe the manufacturers try to solve thermal
 design issues this way? (***)
 
 -----8<-----------------------------
 
 *) According to the closure of PR#26423, estd is now in pkgsrc.
 
 **) I learned that there are more functions in the AMD CPUID to
 detect CPU model information and one of them reports the family
 number +1 by design, maybe this is the reason for the signatures
 having +0x100 on the notebook I have tested (FSC Amilo-A). Anyways,
 I found no indication of consistency between vendors regarding this
 practice so I don't think one can rely on that. My patch tries to match
 both the original signature and the signature+0x100 and this actually
 does work but I don't think this is the right way to do it.
 
 ***) I learned that one cannot rely on BIOS support to extract the
 proper FID/VID values from PSBs. Some vendors do provide this
 information in their BIOSes, some do not, some provide incorrect,
 incomplete, or unusable information. Even worse, the ACPI P-states
 list was also empty in the notebook I had, which means one cannot
 rely neither on APM nor on ACPI to get proper FID/VID pairs, one can
 only hope that something is present or is usable.
 
 Conclusion:
 
 If one sets a FID/VID pair which is not supported by the CPU then
 it may hang completely, so one has to make sure the FID/VID values
 are correct before they are tried. Currently I think the only way to
 ensure that is to get the correct tables from AMD for each and
 every CPU model and include these in the kernel, detect the
 exact CPU model by CPUID at boot time and use the table
 specific to that particular CPU.