[please CC your replies, because i'm not subscribed]
I'm testing 2.6.0-test1 on my HP nx9005 Laptop (using a Mobile AMD Athlon XP)
But i can't get the sysfs interface of CPUFreq part to show up. I then
recomplied the kernel with both old (obsolete) /proc interfaces enabled. The old
interfaces both show up, but seem to be not working (but the is my first try to
get CPUFreq working with any kernel version). I googled around for hours
without finding any useful information for this case.
Anyway, /proc/sys/cpu/0/{speed,speed-max,speed-min} are all 0 when i cat them.
If i cat /proc/cpufreq i get:
Badness in kobject_get at lib/kobject.c:378
Call Trace:
[<c01f775c>] kobject_get+0x4c/0x50
[<c0135e85>] cpufreq_cpu_get+0x85/0x100
[<c0136e13>] cpufreq_get_policy+0x23/0xa0
[<c01f962f>] sprintf+0x1f/0x30
[<c02a6bf0>] cpufreq_proc_read+0x50/0x170
[<c0161ff8>] real_lookup+0xc8/0xf0
[<c013e011>] buffered_rmqueue+0xd1/0x170
[<c016b6a2>] dput+0x22/0x200
[<c013e140>] __alloc_pages+0x90/0x300
[<c02a6ba0>] cpufreq_proc_read+0x0/0x170
[<c0184805>] proc_file_read+0xc5/0x280
[<c0154b48>] vfs_read+0xd8/0x140
[<c0154df2>] sys_read+0x42/0x70
[<c010b29b>] syscall_call+0x7/0xb
minimum CPU frequency - maximum CPU frequency - policy
The last line output by cat, the rest are kernel messages.
/sys/devices/system/cpu/cpu0/ is just an empty directory, it even does not
contain a 'name' file.
I can echo > to /proc/cpufreq and /proc/sys/cpu/0/speed without any
result (i.e. no speed change as far as i can tell).
The powernow driver detects the CPU.
Martin H.
Form bootup messages:
powernow: AMD K7 CPU detected.
powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: Found PSB header at c00f18c0
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 14 PST tables. (Only dumping ones relevant to this CPU).
Hopefully relevant parts from my .config:
CONFIG_X86_PC=y
CONFIG_MK7=y
CONFIG_X86_USE_3DNOW=y
CONFIG_PREEMPT=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
#
# ACPI Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_PROC_INTF=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_24_API=y
CONFIG_CPU_FREQ_TABLE=y
#
# CPUFreq processor drivers
#
CONFIG_X86_POWERNOW_K7=y
# [every thing else not set]
On Sun, 20 Jul 2003 17:02:43 +0200
[email protected] wrote:
> [please CC your replies, because i'm not subscribed]
>
> I'm testing 2.6.0-test1 on my HP nx9005 Laptop (using a Mobile AMD
> Athlon XP)
>
> But i can't get the sysfs interface of CPUFreq part to show up. I then
> recomplied the kernel with both old (obsolete) /proc interfaces enabled.
> The old interfaces both show up, but seem to be not working (but the is
> my first try to get CPUFreq working with any kernel version). I googled
> around for hours without finding any useful information for this case.
My .config attached.. Hope that will help you..
With this setup I have /sys/devices/system/cpu/cpu0/cpufreq/ and it's all
working perfectly. I am also using a Mobile AMD Athlon XP.
--
Henrik Persson [email protected] http://nix.badanka.com
[please CC your replies, because i'm not subscribed]
On Sun, Jul 20, 2003 at 07:45:37PM +0200, Henrik Persson wrote:
> On Sun, 20 Jul 2003 17:02:43 +0200
> [email protected] wrote:
>
> > [please CC your replies, because i'm not subscribed]
> >
> > I'm testing 2.6.0-test1 on my HP nx9005 Laptop (using a Mobile AMD
> > Athlon XP)
> >
> > But i can't get the sysfs interface of CPUFreq part to show up. I then
> > recomplied the kernel with both old (obsolete) /proc interfaces enabled.
> > The old interfaces both show up, but seem to be not working (but the is
> > my first try to get CPUFreq working with any kernel version). I googled
> > around for hours without finding any useful information for this case.
>
> My .config attached.. Hope that will help you..
>
> With this setup I have /sys/devices/system/cpu/cpu0/cpufreq/ and it's all
> working perfectly. I am also using a Mobile AMD Athlon XP.
>
I tried your config (with just one change, i enabled reiserfs, i use it for my
root fs) but It's the same. /sys/devices/system/cpu/cpu0/ is just empty, no
change.
I tried with gcc 2.95.4 (as shipped with debian testing) and gcc 3.3.1 (same)
but neither solved to problem.
What else could be the Problem? I assume problems loading modules or such
userspace problems can't cause this behaviour?
Any help diagnosing the problem appricatied,
Martin H.
> I tried your config (with just one change, i enabled reiserfs, i use it for my
> root fs) but It's the same. /sys/devices/system/cpu/cpu0/ is just empty, no
> change.
>
> I tried with gcc 2.95.4 (as shipped with debian testing) and gcc 3.3.1 (same)
> but neither solved to problem.
> What else could be the Problem? I assume problems loading modules or such
> userspace problems can't cause this behaviour?
>
> Any help diagnosing the problem appricatied,
>
> Martin H.
What's the output [if any] in "dmesg" starting with either "cpufreq" or
"powernow"?
I guess it's yet another BIOS problem... [as seen quite often wrt AMD
PowerNow, unfortunately]
Dominik
On Tue, Jul 22, 2003 at 02:08:11PM +0200, Dominik Brodowski wrote:
>
> What's the output [if any] in "dmesg" starting with either "cpufreq" or
> "powernow"?
I included some more information about my system in my first mail, but anyway.
the IMHO relevant dmesg messages are:
Machine check exception polling timer started.
powernow: AMD K7 CPU detected.
powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
powernow: Found PSB header at c00f17f0
powernow: Table version: 0x12
powernow: Flags: 0x0 (Mobile voltage regulator)
powernow: Settling Time: 100 microseconds.
powernow: Has 14 PST tables. (Only dumping ones relevant to this CPU).
Enabling SEP on CPU 0
I did a little bit of investigation in the kernel source (powernow-k7.c) and
downloaded x86info. The Output of x86info --pm --bios with the following
clueless little patch.
--- AMD/dumppsb.c 16 Jan 2003 19:46:52 -0000 1.4
+++ AMD/dumppsb.c 22 Jul 2003 13:47:59 -0000
@@ -81,8 +81,10 @@
for (i = 0 ; i <psb->numpst; i++) {
pst = (struct pst_s *) p;
numpstates = pst->numpstates;
-
- if ((etuple(cpu) == pst->cpuid) && (maxfid==pst->maxfid) && (startvid==pst->startvid))
+ printf(" --DEBUG: %x ?= %x && %d ?= %d, %d ?= %d\n",
+ etuple(cpu),pst->cpuid, maxfid,pst->maxfid, startvid, pst->startvid);
+ //if ((etuple(cpu) == pst->cpuid) && (maxfid==pst->maxfid) && (startvid==pst->startvid))
+ if (1)
{
printf (" PST:%d (@%p)\n", i, pst);
printf (" cpuid: 0x%x\t", pst->cpuid);
Output:
x86info v1.12. Dave Jones 2001-2003
Feedback to <[email protected]>.
Found 1 CPU
--------------------------------------------------------------------------
Family: 6 Model: 10 Stepping: 0
CPU Model : Mobile Athlon XP (Barton)
PowerNOW! Technology information
Available features:
Temperature sensing diode present.
Bus divisor control
Voltage ID control
MSR: 0xc0010041=0x0000000000130b15 : 00000000 00000000 00000000 00000000
00000000 00010011 00001011 00010101
MSR: 0xc0010042=0x000b0b0b00150615 : 00000000 00001011 00001011 00001011
00000000 00010101 00000110 00010101
FID changes will happen
VID changes will happen
Current VID multiplier code: 1.450
Current FSB multiplier code: 13.5
Voltage ID codes: Maximum=1.450V Startup=1.450V Currently=1.450V
Frequency ID codes: Maximum=13.5x Startup=6.0x Currently=13.5x
Decoding BIOS PST tables (maxfid=15, startvid=b)
Found PSB header at 0x4017d7f0
Table version: 0x12
Flags: 0x0 (Mobile voltage regulator)
Settling Time: 100 microseconds.
Has 14 PST tables. (Only dumping ones relevant to this CPU).
--DEBUG: 7a0 ?= 780 && 21 ?= 12, 11 ?= 11
PST:0 (@0x4017d800)
cpuid: 0x780 fsb: 133 maxFID: 0xc startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0x8 (7.0x [931MHz]) VID: 0xe (1.300V)
FID: 0xc (9.0x [1197MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 780 && 21 ?= 14, 11 ?= 11
PST:1 (@0x4017d812)
cpuid: 0x780 fsb: 133 maxFID: 0xe startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0x8 (7.0x [931MHz]) VID: 0x11 (1.250V)
FID: 0xe (10.0x [1330MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 780 && 21 ?= 15, 11 ?= 9
PST:2 (@0x4017d824)
cpuid: 0x780 fsb: 133 maxFID: 0xf startvid: 0x9
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xa (8.0x [1064MHz]) VID: 0xc (1.400V)
FID: 0xf (10.5x [1396MHz]) VID: 0x9 (1.550V)
--DEBUG: 7a0 ?= 780 && 21 ?= 0, 11 ?= 9
PST:3 (@0x4017d836)
cpuid: 0x780 fsb: 133 maxFID: 0x0 startvid: 0x9
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0xc (1.400V)
FID: 0x0 (11.0x [1463MHz]) VID: 0x9 (1.550V)
--DEBUG: 7a0 ?= 780 && 21 ?= 1, 11 ?= 9
PST:4 (@0x4017d848)
cpuid: 0x780 fsb: 133 maxFID: 0x1 startvid: 0x9
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0xd (1.350V)
FID: 0x1 (11.5x [1530MHz]) VID: 0x9 (1.550V)
--DEBUG: 7a0 ?= 780 && 21 ?= 2, 11 ?= 10
PST:5 (@0x4017d85a)
cpuid: 0x780 fsb: 133 maxFID: 0x2 startvid: 0xa
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0x11 (1.250V)
FID: 0x2 (12.0x [1596MHz]) VID: 0xa (1.500V)
--DEBUG: 7a0 ?= 780 && 21 ?= 3, 11 ?= 10
PST:6 (@0x4017d86c)
cpuid: 0x780 fsb: 133 maxFID: 0x3 startvid: 0xa
num of p states in this table: 6
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xa (8.0x [1064MHz]) VID: 0x13 (1.200V)
FID: 0xe (10.0x [1330MHz]) VID: 0xe (1.300V)
FID: 0x3 (12.5x [1662MHz]) VID: 0xa (1.500V)
--DEBUG: 7a0 ?= 781 && 21 ?= 15, 11 ?= 11
PST:7 (@0x4017d880)
cpuid: 0x781 fsb: 133 maxFID: 0xf startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xa (8.0x [1064MHz]) VID: 0xe (1.300V)
FID: 0xf (10.5x [1396MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 0, 11 ?= 11
PST:8 (@0x4017d892)
cpuid: 0x781 fsb: 133 maxFID: 0x0 startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0xd (1.350V)
FID: 0x0 (11.0x [1463MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 1, 11 ?= 11
PST:9 (@0x4017d8a4)
cpuid: 0x781 fsb: 133 maxFID: 0x1 startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0xd (1.350V)
FID: 0x1 (11.5x [1530MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 2, 11 ?= 11
PST:10 (@0x4017d8b6)
cpuid: 0x781 fsb: 133 maxFID: 0x2 startvid: 0xb
num of p states in this table: 5
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xc (9.0x [1197MHz]) VID: 0xd (1.350V)
FID: 0x2 (12.0x [1596MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 3, 11 ?= 11
PST:11 (@0x4017d8c8)
cpuid: 0x781 fsb: 133 maxFID: 0x3 startvid: 0xb
num of p states in this table: 6
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0xa (8.0x [1064MHz]) VID: 0x11 (1.250V)
FID: 0xe (10.0x [1330MHz]) VID: 0xd (1.350V)
FID: 0x3 (12.5x [1662MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 21, 11 ?= 11
PST:12 (@0x4017d8dc)
cpuid: 0x781 fsb: 133 maxFID: 0x15 startvid: 0xb
num of p states in this table: 6
FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
FID: 0x8 (7.0x [931MHz]) VID: 0x13 (1.200V)
FID: 0xe (10.0x [1330MHz]) VID: 0xe (1.300V)
FID: 0x15 (13.5x [1796MHz]) VID: 0xb (1.450V)
--DEBUG: 7a0 ?= 781 && 21 ?= 22, 11 ?= 11
PST:13 (@0x4017d8f0)
cpuid: 0x781 fsb: 133 maxFID: 0x16 startvid: 0xb
num of p states in this table: 5
FID: 0xb (8.5x [1130MHz]) VID: 0x13 (1.200V)
FID: 0xf (10.5x [1396MHz]) VID: 0xe (1.300V)
FID: 0x1 (11.5x [1530MHz]) VID: 0xd (1.350V)
FID: 0x3 (12.5x [1662MHz]) VID: 0xc (1.400V)
FID: 0x16 (14.0x [1862MHz]) VID: 0xb (1.450V)
So it seems to me that the BIOS doesn't have the tables for my Athlon
model/stepping. I tried to get a new bios from hp, but it didn't change anything
relevant (they changed something in the PSTs but did not add a new one for my
processor)
>
> I guess it's yet another BIOS problem... [as seen quite often wrt AMD
> PowerNow, unfortunately]
I think it would be a good thing to display a Message explaining why powernow
isn't working to the user in the case that no relevant PST is found.
Can you suggest any workaround for this problem, or is my only option to
complain to HP do supply an updated BIOS.
I very much would like to have a way to override (or add to) the bios provided
values. BTW windows XP somehow manages to use powernow on this laptop anyway.
Martin H.
On Tue, Jul 22, 2003 at 04:18:39PM +0200, [email protected] wrote:
> So it seems to me that the BIOS doesn't have the tables for my Athlon
> model/stepping. I tried to get a new bios from hp, but it didn't change anything
> relevant (they changed something in the PSTs but did not add a new one for my
> processor)
Indeed, that's the BUG().
> > I guess it's yet another BIOS problem... [as seen quite often wrt AMD
> > PowerNow, unfortunately]
>
> I think it would be a good thing to display a Message explaining why powernow
> isn't working to the user in the case that no relevant PST is found.
Patch appended at the end.
> Can you suggest any workaround for this problem, or is my only option to
> complain to HP do supply an updated BIOS.
Well, you could try using the PST which mostly matches your system except
the CPUID [PST #12, see below] -- if the values used are similar to the ones
Windows XP uses. But this might be risky!!!
> I very much would like to have a way to override (or add to) the bios provided
> values.
AFAIK, Dave Jones will add support to override the BIOS-provided tables.
> --DEBUG: 7a0 ?= 781 && 21 ?= 21, 11 ?= 11
> PST:12 (@0x4017d8dc)
> cpuid: 0x781 fsb: 133 maxFID: 0x15 startvid: 0xb
> num of p states in this table: 6
> FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
> FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
> FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
> FID: 0x8 (7.0x [931MHz]) VID: 0x13 (1.200V)
> FID: 0xe (10.0x [1330MHz]) VID: 0xe (1.300V)
> FID: 0x15 (13.5x [1796MHz]) VID: 0xb (1.450V)
Dominik
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-07-11 14:12:35.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-07-22 16:16:00.000000000 +0200
@@ -345,6 +345,7 @@
p+=2;
}
}
+ dprintk (KERN_INFO PFX "Did not find any PST table for this CPU -- exiting\n");
return -EINVAL;
}
p++;
On Tue, Jul 22, 2003 at 04:23:53PM +0200, Dominik Brodowski wrote:
> On Tue, Jul 22, 2003 at 04:18:39PM +0200, [email protected] wrote:
> > So it seems to me that the BIOS doesn't have the tables for my Athlon
> > model/stepping. I tried to get a new bios from hp, but it didn't change anything
> > relevant (they changed something in the PSTs but did not add a new one for my
> > processor)
> Indeed, that's the BUG().
Can you also mail the output of dmidecode, and the model of the laptop.
This is a 'beat up BIOS vendor' case, which AMD are actively trying to do.
I'll forward the info on to the right people..
> > I think it would be a good thing to display a Message explaining why powernow
> > isn't working to the user in the case that no relevant PST is found.
> Patch appended at the end.
Looks fine. I'll apply it when I get back from KS/OLS.
> > I very much would like to have a way to override (or add to) the bios provided
> > values.
> AFAIK, Dave Jones will add support to override the BIOS-provided tables.
There's been some sysfs discussion with Pat in the last few days
(not specifically cpufreq related, but its going to become easier
to add this aparently..).
Dave
On Tue, Jul 22, 2003 at 04:23:53PM +0200, Dominik Brodowski wrote:
> On Tue, Jul 22, 2003 at 04:18:39PM +0200, [email protected] wrote:
> > So it seems to me that the BIOS doesn't have the tables for my Athlon
> > model/stepping. I tried to get a new bios from hp, but it didn't change anything
> > relevant (they changed something in the PSTs but did not add a new one for my
> > processor)
>
> Indeed, that's the BUG().
I'll complain to HP about that.
>
> > > I guess it's yet another BIOS problem... [as seen quite often wrt AMD
> > > PowerNow, unfortunately]
> >
> > I think it would be a good thing to display a Message explaining why powernow
> > isn't working to the user in the case that no relevant PST is found.
>
> Patch appended at the end.
Yes that patch would IMHO point users with broken BIOS tables in the right
direction.
>
> > Can you suggest any workaround for this problem, or is my only option to
> > complain to HP do supply an updated BIOS.
>
> Well, you could try using the PST which mostly matches your system except
> the CPUID [PST #12, see below] -- if the values used are similar to the ones
> Windows XP uses. But this might be risky!!!
>
I think you know a bit more about these matters than me, so please allow me this
question:
How much risk do you think that would be (with the usual 'you are not responible
for any damages' stuff as usual) to just use that entry? At with the performance
governour it is exactly the same as displayed as currently by x86info so that
shouldn't be a problem. Do you think that lower frequencies and voltages can
kill the processor? [I can cope with instabilities]
Thank you for your help.
Martin H.
> > --DEBUG: 7a0 ?= 781 && 21 ?= 21, 11 ?= 11
> > PST:12 (@0x4017d8dc)
> > cpuid: 0x781 fsb: 133 maxFID: 0x15 startvid: 0xb
> > num of p states in this table: 6
> > FID: 0x12 (4.0x [532MHz]) VID: 0x13 (1.200V)
> > FID: 0x4 (5.0x [665MHz]) VID: 0x13 (1.200V)
> > FID: 0x6 (6.0x [798MHz]) VID: 0x13 (1.200V)
> > FID: 0x8 (7.0x [931MHz]) VID: 0x13 (1.200V)
> > FID: 0xe (10.0x [1330MHz]) VID: 0xe (1.300V)
> > FID: 0x15 (13.5x [1796MHz]) VID: 0xb (1.450V)
>
> Dominik
>
> diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
> --- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-07-11 14:12:35.000000000 +0200
> +++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2003-07-22 16:16:00.000000000 +0200
> @@ -345,6 +345,7 @@
> p+=2;
> }
> }
> + dprintk (KERN_INFO PFX "Did not find any PST table for this CPU -- exiting\n");
> return -EINVAL;
> }
> p++;
Hi!
> I think you know a bit more about these matters than me, so please allow me this
> question:
> How much risk do you think that would be (with the usual 'you are not responible
> for any damages' stuff as usual) to just use that entry? At with the performance
> governour it is exactly the same as displayed as currently by x86info so that
> shouldn't be a problem. Do you think that lower frequencies and voltages can
> kill the processor? [I can cope with instabilities]
>
You are not likely to kill cpu (BTDT).
--
Pavel
Hardware that lets software kill it deserved that.
On Wed, 23 Jul 2003, Pavel Machek wrote:
[SNIPPED...]
> Pavel
> Hardware that lets software kill it deserved that.
Don't touch the Motorola 56xxx DSP, then. There are several
"insane instructions" that will smoke the device (programming
a pin for both input and output at the same time). There are
many other chips, often used on Motherboards, that have
programmable pins (even the AMD SC520)... These can be destroyed
by software.
Also, the bits for setting the power supply voltages to be
applied to your CPU are available in I/O space on many motherboards.
Try your 2.5 volt CPU on 5.0 volts. It will melt the solder that
holds the socket to the board!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Hi!
> > Pavel
> > Hardware that lets software kill it deserved that.
>
> Don't touch the Motorola 56xxx DSP, then. There are several
> "insane instructions" that will smoke the device (programming
> a pin for both input and output at the same time). There are
Well, if motorola was so stupid that you can kill it by mistake... I
don't want to touch _that_.
> Also, the bits for setting the power supply voltages to be
> applied to your CPU are available in I/O space on many motherboards.
> Try your 2.5 volt CPU on 5.0 volts. It will melt the solder that
> holds the socket to the board!
On mainboards I saw it was in 'reasonable' range. I trust it not to
melt cpu before thermal diode does its job.
AMD's PowerNow at least will not let you overclock and/or
overvoltage. You are free to undervoltage, but that's crash-only.
Its true that HP Omnibook xe3 probably can be damaged, provided that
its CPU fan fails and there's just enough airflow to keep thermal
protection from kicking in. Its harddrive overheats in such case.
I guess that's uncommon enough.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Tue, Jul 22, 2003 at 04:53:52PM +0200, [email protected] wrote:
> > Well, you could try using the PST which mostly matches your system except
> > the CPUID [PST #12, see below] -- if the values used are similar to the ones
> > Windows XP uses. But this might be risky!!!
> >
>
> I think you know a bit more about these matters than me, so please allow me this
> question:
> How much risk do you think that would be (with the usual 'you are not responible
> for any damages' stuff as usual) to just use that entry? At with the performance
> governour it is exactly the same as displayed as currently by x86info so that
> shouldn't be a problem. Do you think that lower frequencies and voltages can
> kill the processor? [I can cope with instabilities]
I really can't answer on that as I do neither know the hardware nor the BIOS
implementation well enough. Sorry.
BTW, it's no surprise that the x86info and cpufreq output are the same --
they use the same code. It'd be more interesting if Window$ uses the same
values [just mentioning it as you said PowerNow works on it, so....]
Dominik