Re: [Bug 3600] New: Cpu recognization fails after upgrade from 2.6.7 to 2.6.9

[Dave Jones <davej@redhat.com>]

On Thu, Oct 21, 2004 at 12:25:29PM +0200, Bruno Ducrot wrote:

 > > --- a/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-20 18:46:51.000000000 +0200
 > > +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-20 18:47:06.000000000 +0200
 > > @@ -597,7 +597,7 @@
 > >  	rdmsrl (MSR_K7_FID_VID_STATUS, fidvidstatus.val);
 > >  
 > >  	/* A K7 with powernow technology is set to max frequency by BIOS */
 > > -	fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.MFID];
 > > +	fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.CFID];
 > >  	if (!fsb) {
 > >  		printk(KERN_WARNING PFX "can not determine bus frequency\n");
 > >  		return -EINVAL;
 > > 
 > > 
 > 
 > No.  It's wrong.  Though I *much* prefer the form you submit, this will
 > break other unfortunately, and therefore maxfid have to be used
 > here for now as per AMD documentation (problem is, your bios is broken
 > because it do not respect AMD recomandation since after POST the
 > processor shall be put in max frequencies instead of 800MHz).  In short,
 > there is a need to choose who would be broken here for now, and
 > I have to do the one recommanded by AMD.

Since 2.6.9, I've been getting at least one private mail about this
every few days, so I'd like to get this fixed for 2.6.10.
Some ideas..

- A module parameter to switch between usage of MFID / CFID.
- If cpu_khz is greater than any of the frequencies in the table
  we calculate, use CFID.
  (This might not work as running frequency on battery may be
   in the list of frequencies we calculate)
- Construct tables for _both_ MFID and CFID, and merge the
  results.

 > I'm not sure for now how to implement correctly this, and I don't have
 > time for now to make free developpements, but when I got time, I will
 > try to make a workaround (there is also another trouble with the MFID,
 > since we can not modprobe a second time if the processor is not in max
 > for example, but I don't think it will be so hard to fix).

That just needs 'restore to max on unload' as longhaul did.
Maybe we should make a core function that does that on module
shutdown.

		Dave