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

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

[bugme-daemon]

http://bugme.osdl.org/show_bug.cgi?id=3600

           Summary: Cpu recognization fails after upgrade from 2.6.7 to
                    2.6.9
    Kernel Version: 2.6.9
            Status: NEW
          Severity: normal
             Owner: cpufreq@www.linux.org.uk
         Submitter: dbonomi@crema.unimi.it


Hardware Environment:
acer 1356 lmi (laptop) with AMD athlon-xp 2800+


Problem Description:
with linux 2.6.7 my processor is correctly recognized, this is the relative
kernel output

powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: FSB: 132.686 MHz
powernow: Found PSB header at c00f06f0
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 8 PST tables. (Only dumping ones relevant to this CPU).
powernow: PST:3 (@c00f0746)
powernow:  cpuid: 0x7a0^Ifsb: 133^ImaxFID: 0x1a^Istartvid: 0x7
powernow:    FID: 0x0 (11.0x [1459MHz])^IVID: 0xe (1.300V)
powernow:    FID: 0x1 (11.5x [1525MHz])^IVID: 0xd (1.350V)
powernow:    FID: 0x2 (12.0x [1592MHz])^IVID: 0xc (1.400V)
powernow:    FID: 0x3 (12.5x [1658MHz])^IVID: 0xb (1.450V)
powernow:    FID: 0x14 (13.0x [1724MHz])^IVID: 0xa (1.500V)
powernow:    FID: 0x15 (13.5x [1791MHz])^IVID: 0x9 (1.550V)
powernow:    FID: 0x18 (15.0x [1990MHz])^IVID: 0x8 (1.600V)
powernow:    FID: 0x1a (16.0x [2122MHz])^IVID: 0x7 (1.650V)
powernow: SGTC: 13333
powernow: Minimum speed 1459 MHz. Maximum speed 2122 MHz.

with 2.6.9 is not 

powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: No PST tables match this cpuid (0x7a0)
powernow: This is indicative of a broken BIOS.
powernow: Trying ACPI perflib
powernow: Minimum speed 298 MHz. Maximum speed 796 MHz.

Kernel configuration (for frequency scaling) is equal for both

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_PROC_INTF=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_24_API=y
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
# CONFIG_X86_POWERNOW_K6 is not set
CONFIG_X86_POWERNOW_K7=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set


lspci output is

00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:07.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller
(rev 02)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
Controller (PHY/Link)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device
8180 (rev 20)
00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237
AC97 Audio Controller (rev 50)
00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem]
(rev 80)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: ATI Technologies Inc RV250 5c61 [Radeon
Mobility 9200 M9+] (rev 01)

Thanks
Daniele

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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

[Kronos]

Il Wed, Oct 20, 2004 at 07:13:07AM -0700, bugme-daemon@osdl.org ha scritto: 
> Problem Description:
> with linux 2.6.7 my processor is correctly recognized, this is the relative
> kernel output
> 
> powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
> powernow: FSB: 132.686 MHz
> powernow: Found PSB header at c00f06f0
> powernow: Table version: 0x12
> powernow: Flags: 0x0 (Mobile voltage regulator)
> powernow: Settling Time: 100 microseconds.
> powernow: Has 8 PST tables. (Only dumping ones relevant to this CPU).
> powernow: PST:3 (@c00f0746)
> powernow:  cpuid: 0x7a0^Ifsb: 133^ImaxFID: 0x1a^Istartvid: 0x7
> powernow:    FID: 0x0 (11.0x [1459MHz])^IVID: 0xe (1.300V)
> powernow:    FID: 0x1 (11.5x [1525MHz])^IVID: 0xd (1.350V)
> powernow:    FID: 0x2 (12.0x [1592MHz])^IVID: 0xc (1.400V)
> powernow:    FID: 0x3 (12.5x [1658MHz])^IVID: 0xb (1.450V)
> powernow:    FID: 0x14 (13.0x [1724MHz])^IVID: 0xa (1.500V)
> powernow:    FID: 0x15 (13.5x [1791MHz])^IVID: 0x9 (1.550V)
> powernow:    FID: 0x18 (15.0x [1990MHz])^IVID: 0x8 (1.600V)
> powernow:    FID: 0x1a (16.0x [2122MHz])^IVID: 0x7 (1.650V)
> powernow: SGTC: 13333
> powernow: Minimum speed 1459 MHz. Maximum speed 2122 MHz.
> 
> with 2.6.9 is not 
> 
> powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
> powernow: No PST tables match this cpuid (0x7a0)
> powernow: This is indicative of a broken BIOS.
> powernow: Trying ACPI perflib
> powernow: Minimum speed 298 MHz. Maximum speed 796 MHz.

Hi,
I saw something similar on my notebook. In my case when the notebook is
turned on while using battery BIOS sets CPU speed to a frequency lower
than the defaul (800MHz for me). It seems that powernow driver is
confused by the BIOS fiddling with CPU speed and fails to load. I had
the same symptoms: PST not found and wrong min/max frequencies.

Disabling "Automatic CPU power saving" (or something like that) in the
BIOS cures the problem for me. Note that this option do not affect power
management under linux (or windows), it just controls the CPU before a
real OS comes up.

Luca
-- 
Home: http://kronoz.cjb.net
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.

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

[Daniele Bonomi]

On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:

> Hi,
> I saw something similar on my notebook. In my case when the notebook
> is turned on while using battery BIOS sets CPU speed to a frequency
> lower than the defaul (800MHz for me). It seems that powernow driver
> is confused by the BIOS fiddling with CPU speed and fails to load. I
> had the same symptoms: PST not found and wrong min/max frequencies.
> 
> Disabling "Automatic CPU power saving" (or something like that) in the
> BIOS cures the problem for me. Note that this option do not affect
> power management under linux (or windows), it just controls the CPU
> before a real OS comes up.

I tried but it didn't worked for me.
For me doesn't work even if i'm plugged in...

Thanks for your help.
Gufo

-- 
  ,___,	  While most peoples' opinions change, the conviction of their
  (9v9)   	     correctness never does
  (_^((\     	Gpg Key at filibusta.crema.unimi.it/~dbonomi/db.asc
-^-"-"-\\-^--	FP = C613 3CF3 94CD FA27 7900 D16C 3A6E 1CB5 585A CD71

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

[Kronos]

Il Wed, Oct 20, 2004 at 06:05:37PM +0200, Daniele Bonomi ha scritto: 
> On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:
> 
> > Hi,
> > I saw something similar on my notebook. In my case when the notebook
> > is turned on while using battery BIOS sets CPU speed to a frequency
> > lower than the defaul (800MHz for me). It seems that powernow driver
> > is confused by the BIOS fiddling with CPU speed and fails to load. I
> > had the same symptoms: PST not found and wrong min/max frequencies.
> > 
> > Disabling "Automatic CPU power saving" (or something like that) in the
> > BIOS cures the problem for me. Note that this option do not affect
> > power management under linux (or windows), it just controls the CPU
> > before a real OS comes up.
> 
> I tried but it didn't worked for me.
> For me doesn't work even if i'm plugged in...

Ok, can you apply this patch to 2.6.9 (and enable debug):

--- 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;


Luca
-- 
Home: http://kronoz.cjb.net
Se non puoi convincerli, confondili.

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

[Daniele Bonomi]

On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:

With the patch previously supplied by Kronos things started working as
well.
 
Output from the "broken" kernel with debug enabled is 

powernow: PowerNOW! Technology present. Can scale: frequency and
voltage. powernow: FSB:  49.758 MHz
powernow: Found PSB header at c00f06f0
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 8 PST tables. (Only dumping ones relevant to this CPU).
powernow: No PST tables match this cpuid (0x7a0)
powernow: This is indicative of a broken BIOS.
powernow: Trying ACPI perflib
powernow: acpi:  P0: 2133 MHz 75000 mW 125 uS control 00d058fa SGTC
13334 powernow:    FID: 0x1a (16.0x [796MHz])  VID: 0x7 (1.650V)
powernow: acpi:  P1: 1800 MHz 55000 mW 125 uS control 00d05935 SGTC
13334 powernow:    FID: 0x15 (13.5x [671MHz])  VID: 0x9 (1.550V)
powernow: acpi:  P2: 1467 MHz 32000 mW 125 uS control 00d059c0 SGTC
13334 powernow:    FID: 0x0 (11.0x [547MHz])  VID: 0xe (1.300V)
powernow: acpi:  P3: 1064 MHz 30000 mW 125 uS control 00d059ca SGTC
13334 powernow:    FID: 0xa (8.0x [398MHz])  VID: 0xe (1.300V)
powernow: acpi:  P4: 800 MHz 26000 mW 125 uS control 00d059c6 SGTC 13334
powernow:    FID: 0x6 (6.0x [298MHz])  VID: 0xe (1.300V)
powernow: Minimum speed 298 MHz. Maximum speed 796 MHz.

now is right

powernow: PowerNOW! Technology present. Can scale:
frequency and voltage. powernow: FSB: 132.718 MHz
powernow: Found PSB header at c00f06f0
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 8 PST tables. (Only dumping ones relevant to this CPU).
powernow: PST:3 (@c00f0746)
powernow:  cpuid: 0x7a0  fsb: 133  maxFID: 0x1a  startvid: 0x7
powernow:    FID: 0x0 (11.0x [1459MHz])  VID: 0xe (1.300V)
powernow:    FID: 0x1 (11.5x [1526MHz])  VID: 0xd (1.350V)
powernow:    FID: 0x2 (12.0x [1592MHz])  VID: 0xc (1.400V)
powernow:    FID: 0x3 (12.5x [1658MHz])  VID: 0xb (1.450V)
powernow:    FID: 0x14 (13.0x [1725MHz])  VID: 0xa (1.500V)
powernow:    FID: 0x15 (13.5x [1791MHz])  VID: 0x9 (1.550V)
powernow:    FID: 0x18 (15.0x [1990MHz])  VID: 0x8 (1.600V)
powernow:    FID: 0x1a (16.0x [2123MHz])  VID: 0x7 (1.650V)
powernow: SGTC: 13333
powernow: Minimum speed 1459 MHz. Maximum speed 2123 MHz.


Thank you all very much for the help.

Daniele



-- 
  ,___,	  While most peoples' opinions change, the conviction of their
  (9v9)   	     correctness never does
  (_^((\     	Gpg Key at filibusta.crema.unimi.it/~dbonomi/db.asc
-^-"-"-\\-^--	FP = C613 3CF3 94CD FA27 7900 D16C 3A6E 1CB5 585A CD71

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

[Bruno Ducrot]

On Wed, Oct 20, 2004 at 06:51:10PM +0200, Kronos wrote:
> Il Wed, Oct 20, 2004 at 06:05:37PM +0200, Daniele Bonomi ha scritto: 
> > On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:
> > 
> > > Hi,
> > > I saw something similar on my notebook. In my case when the notebook
> > > is turned on while using battery BIOS sets CPU speed to a frequency
> > > lower than the defaul (800MHz for me). It seems that powernow driver
> > > is confused by the BIOS fiddling with CPU speed and fails to load. I
> > > had the same symptoms: PST not found and wrong min/max frequencies.
> > > 
> > > Disabling "Automatic CPU power saving" (or something like that) in the
> > > BIOS cures the problem for me. Note that this option do not affect
> > > power management under linux (or windows), it just controls the CPU
> > > before a real OS comes up.
> > 
> > I tried but it didn't worked for me.
> > For me doesn't work even if i'm plugged in...
> 
> Ok, can you apply this patch to 2.6.9 (and enable debug):
> 
> --- 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.

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

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

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

[Kronos]

Il Thu, Oct 21, 2004 at 12:25:29PM +0200, Bruno Ducrot ha scritto: 
> On Wed, Oct 20, 2004 at 06:51:10PM +0200, Kronos wrote:
> > Il Wed, Oct 20, 2004 at 06:05:37PM +0200, Daniele Bonomi ha scritto: 
> > > On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:
> > > 
> > > > Hi,
> > > > I saw something similar on my notebook. In my case when the notebook
> > > > is turned on while using battery BIOS sets CPU speed to a frequency
> > > > lower than the defaul (800MHz for me). It seems that powernow driver
> > > > is confused by the BIOS fiddling with CPU speed and fails to load. I
> > > > had the same symptoms: PST not found and wrong min/max frequencies.
> > > > 
> > > > Disabling "Automatic CPU power saving" (or something like that) in the
> > > > BIOS cures the problem for me. Note that this option do not affect
> > > > power management under linux (or windows), it just controls the CPU
> > > > before a real OS comes up.
> > > 
> > > I tried but it didn't worked for me.
> > > For me doesn't work even if i'm plugged in...
> > 
> > Ok, can you apply this patch to 2.6.9 (and enable debug):
> > 
> > --- 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). 

Yes I know, I was trying to pin down the problem. I was almost sure that
the BIOS was changing frequency since I had the same problem, though in
my case I was able to teach the BIOS to not touch the CPU.

Luca
-- 
Home: http://kronoz.cjb.net
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies

[PATCH] Fix cpu recognization if BIOS does not set cpu to max freq [was: Re: [Bug 3600] New: Cpu recognization fails after upgrade from 2.6.7 to 2.6.9]

[Kronos]

Il Thu, Oct 21, 2004 at 12:25:29PM +0200, Bruno Ducrot ha scritto: 
> On Wed, Oct 20, 2004 at 06:51:10PM +0200, Kronos wrote:
> > Il Wed, Oct 20, 2004 at 06:05:37PM +0200, Daniele Bonomi ha scritto: 
> > > On Wed, 20 Oct 2004 17:47:44 +0200 Kronos <kronos@kronoz.cjb.net> wrote:
> > > 
> > > > Hi,
> > > > I saw something similar on my notebook. In my case when the notebook
> > > > is turned on while using battery BIOS sets CPU speed to a frequency
> > > > lower than the defaul (800MHz for me). It seems that powernow driver
> > > > is confused by the BIOS fiddling with CPU speed and fails to load. I
> > > > had the same symptoms: PST not found and wrong min/max frequencies.
> > > > 
> > > > Disabling "Automatic CPU power saving" (or something like that) in the
> > > > BIOS cures the problem for me. Note that this option do not affect
> > > > power management under linux (or windows), it just controls the CPU
> > > > before a real OS comes up.
> > > 
> > > I tried but it didn't worked for me.
> > > For me doesn't work even if i'm plugged in...
> > 
> > Ok, can you apply this patch to 2.6.9 (and enable debug):
> > 
> > --- 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.

What about the following patch. Tested here and works as expected:

powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: CPU wasn't set to maximum frequency. Using workaround.
powernow: FSB: 133.917 MHz
powernow: Found PSB header at c00f0320
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 1 PST tables. (Only dumping ones relevant to this CPU).
powernow: PST:0 (@c00f0330)
powernow:  cpuid: 0x7a0  fsb: 133  maxFID: 0x16  startvid: 0xb
powernow:    FID: 0x12 (4.0x [535MHz])  VID: 0x13 (1.200V)
powernow:    FID: 0x6 (6.0x [803MHz])  VID: 0x13 (1.200V)
powernow:    FID: 0xa (8.0x [1071MHz])  VID: 0x13 (1.200V)
powernow:    FID: 0xe (10.0x [1339MHz])  VID: 0xe (1.300V)
powernow:    FID: 0x2 (12.0x [1607MHz])  VID: 0xc (1.400V)
powernow:    FID: 0x16 (14.0x [1874MHz])  VID: 0xb (1.450V)
powernow: SGTC: 13333
powernow: Minimum speed 535 MHz. Maximum speed 1874 MHz.

without the workaround:

powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: FSB:  57.393 MHz
powernow: Found PSB header at c00f0320
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 1 PST tables. (Only dumping ones relevant to this CPU).
powernow: No PST tables match this cpuid (0x7a0)
powernow: This is indicative of a broken BIOS.
powernow: Trying ACPI perflib
powernow: acpi:  P0: 1862 MHz 21000 mW 125 uS control 009c4176 SGTC 10000
powernow:    FID: 0x16 (14.0x [803MHz])  VID: 0xb (1.450V)
powernow: acpi:  P1: 1600 MHz 15000 mW 125 uS control 009c4182 SGTC 10000
powernow:    FID: 0x2 (12.0x [688MHz])  VID: 0xc (1.400V)
powernow: acpi:  P2: 1333 MHz 15000 mW 125 uS control 009c41ce SGTC 10000
powernow:    FID: 0xe (10.0x [573MHz])  VID: 0xe (1.300V)
powernow: acpi:  P3: 1064 MHz 15000 mW 125 uS control 009c426a SGTC 10000
powernow:    FID: 0xa (8.0x [459MHz])  VID: 0x13 (1.200V)
powernow: acpi:  P4: 798 MHz 15000 mW 125 uS control 009c4266 SGTC 10000
powernow:    FID: 0x6 (6.0x [344MHz])  VID: 0x13 (1.200V)
powernow: acpi:  P5: 532 MHz 15000 mW 125 uS control 009c4272 SGTC 10000
powernow:    FID: 0x12 (4.0x [229MHz])  VID: 0x13 (1.200V)
powernow: Minimum speed 229 MHz. Maximum speed 803 MHz.

---

On some notebooks BIOS fails to set K7 CPUs to the maximum frequency.
powernow-k7 fails to load or falls back to ACPI (if available) with
wrong values. If a bogus FSB speed is detected a workaround should be
used.

Signed-off-by: Luca Tettamanti <kronos@kronoz.cjb.net>

--- a/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-23 22:29:40.000000000 +0200
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-23 22:39:23.000000000 +0200
@@ -598,6 +598,13 @@
 
 	/* A K7 with powernow technology is set to max frequency by BIOS */
 	fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.MFID];
+	if (fsb < 99000) {
+		/* BIOS did not set the processor to the max frequency.
+		 * This does not respect AMD recomandation, but it happens.
+		 */
+		printk(KERN_INFO PFX "CPU wasn't set to maximum frequency. Using workaround.\n");
+		fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.CFID];
+	}
 	if (!fsb) {
 		printk(KERN_WARNING PFX "can not determine bus frequency\n");
 		return -EINVAL;


Luca
-- 
Home: http://kronoz.cjb.net
Software is like sex; it's better when it's free.
Linus Torvalds

Re: [PATCH] Fix cpu recognization if BIOS does not set cpu to max freq [was: Re: [Bug 3600] New: Cpu recognization fails after upgrade from 2.6.7 to 2.6.9]

[Dominik Brodowski]

On Sat, Oct 23, 2004 at 11:43:25PM +0200, Kronos wrote:
> On some notebooks BIOS fails to set K7 CPUs to the maximum frequency.
> powernow-k7 fails to load or falls back to ACPI (if available) with
> wrong values. If a bogus FSB speed is detected a workaround should be
> used.
> 
> Signed-off-by: Luca Tettamanti <kronos@kronoz.cjb.net>
> 
> --- a/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-23 22:29:40.000000000 +0200
> +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-10-23 22:39:23.000000000 +0200
> @@ -598,6 +598,13 @@
>  
>  	/* A K7 with powernow technology is set to max frequency by BIOS */
>  	fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.MFID];
> +	if (fsb < 99000) {
> +		/* BIOS did not set the processor to the max frequency.
> +		 * This does not respect AMD recomandation, but it happens.
> +		 */

So if the motherboard allows for modifying the FSB, and I decide to set the
FSB to 98 MHz, it breaks... What about the following approaches?

- yet another DMI table?

- there's an entry "fsbspeed" in pst_s. Is this useful to determining the
  FSB, and then checking whether FSB*CFID makes more sense than FSB*MFID
  when comparing it to cpu_khz?


	Dominik

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

[Dave Jones]

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

[PATCH for other issue included] Re: [Bug 3600] New: Cpu recognization fails after upgrade from 2.6.7 to 2.6.9

[Dominik Brodowski]

On Tue, Nov 02, 2004 at 09:10:52PM +0000, Dave Jones wrote:
> 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)

From somebody who doesn't know the details and who assumes that MFID is the
maximum frequency multiplier and CFID the assumed current frequency
multiplier: 

There's a "fsb" entry in the psb structure -- can't we do the following:

long int freq_cfid = cfid * fsb_entry_in_psb;
long int freq_mfid = mfid * fsb_entry_in_psb;

freq_cfid -= cpu_khz;
freq_mfid -= cpu_khz;

if (abs(freq_cfid) < abs(freq_mfid))
	/* use CFID */
else
	/* use MFID */

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

We can't do this (currently) in the driver's ->exit() function, as
cpufreq_notify_transition may not be called that late in the
cpufreq_remove_dev() process, as cpufreq_cpu_data[cpu] is already zeroed to
make cpufreq_cpu_get() fail. Problem is that cpufreq_cpu_get() _needs_ to
fail pretty soon in _remove_dev() so that there are no severe
side-effects... Actually, while looking at it, there's a lock-grabbing missing...
but even adding the lock doesn't lead to the exclusion I'd like to have
there... in theory it should work like this:

cpufreq_remove_dev() {
	1.) disallow other cpufreq code to grab references to this CPU,
		including sysfs access
	2.) stop the governor. From here on there may be no calls succeeding
		to either the governor or the cpufreq driver using
		__cpufreq_driver_target()
	3.) possibly set the CPU to max freq. Can't work currently because
		it'll break because of 1.) above
	4.) wait for all references to all sysfs files etc. to be dropped
	5.) call the driver's ->exit() function which may, among others,
		remove remaining sysfs files.
	6.) be [k]free() and go
}

... and I _think_ this patch allows us to do 1 to 6 without 3 at least.

Please apply on top of the other patches submitted to you.

Thanks,
	Dominik


[CPUFREQ] core: CPUFREQ_GOV_STOP needs to be last

Assert that the call to the cpufreq governor with CPUFREQ_GOV_STOP is really
the last. Without this patch, some strange in-kernel preemption combined with
the scheduler disliking the "removing" task may cause the opposite.

Signed-off-by: Dominik Brodowski <linux@brodo.de>

diff -ruN linux-original/drivers/cpufreq/cpufreq.c linux/drivers/cpufreq/cpufreq.c
--- linux-original/drivers/cpufreq/cpufreq.c	2004-11-01 23:24:45.000000000 +0100
+++ linux/drivers/cpufreq/cpufreq.c	2004-11-02 22:51:22.000000000 +0100
@@ -763,8 +763,11 @@
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 #endif
 
+	down(&data->lock);
 	if (cpufreq_driver->target)
 		__cpufreq_governor(data, CPUFREQ_GOV_STOP);
+	cpufreq_driver->target = NULL;
+	up(&data->lock);
 
 	kobject_unregister(&data->kobj);
 
@@ -1025,7 +1029,7 @@
 	lock_cpu_hotplug();
 	dprintk("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
 		target_freq, relation);
-	if (cpu_online(policy->cpu))
+	if (cpu_online(policy->cpu) && cpufreq_driver->target)
 		retval = cpufreq_driver->target(policy, target_freq, relation);
 	unlock_cpu_hotplug();
 	return retval;

Re: [PATCH] Fix cpu recognization if BIOS does not set cpu to max freq [was: Re: [Bug 3600] New: Cpu recognization fails after upgrade from 2.6.7 to 2.6.9]

[Bruno Ducrot]

> - there's an entry "fsbspeed" in pst_s. Is this useful to determining the
>   FSB, and then checking whether FSB*CFID makes more sense than FSB*MFID
>   when comparing it to cpu_khz?

There is no such information if you have to configure with acpi...
Further, fsbspeed is used in order to check if PST is valid by
comparing with the actual FSB.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.