Re: [lm-sensors] k8temp, BE-2350 CPU

Re: [lm-sensors] k8temp, BE-2350 CPU

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sorry for the delay. I'm CCing the list too please do too.


Alistair John Strachan wrote:
> Hi,
> 
> I've noticed a problem with the k8temp driver on a new BE-2350 processor. It 
> seems the sensors report bogus values on this CPU. This is when it is idling:
> 
> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> -5000
> -5000
> -3000
> 1000
> 
> And this is under load:
> 
> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> 7000
> 12000
> 11000
> 17000
> 
> This is a socket AM2 processor. Any idea what's wrong? Using kernel 
> 2.6.23-rc1, but it's also broken on Debian's 2.6.22.

Hmm perhaps the formula does not work anymore :/ Can you send me output of cat
/proc/cpuinfo?

Or even better output of cpuid utillity?

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGuqvT3J9wPJqZRNURAl22AKCrWdYSRaU7yWQ8W8YXQ6kuMbWzJgCeJfwg
kyqz2BC9CRDjeNY37zDE+8s=Ig1D
-----END PGP SIGNATURE-----

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Alistair John Strachan]

On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
> Hi,
>
> Sorry for the delay. I'm CCing the list too please do too.
>
> Alistair John Strachan wrote:
> > Hi,
> >
> > I've noticed a problem with the k8temp driver on a new BE-2350 processor.
> > It seems the sensors report bogus values on this CPU. This is when it is
> > idling:
> >
> > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > -5000
> > -5000
> > -3000
> > 1000
> >
> > And this is under load:
> >
> > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > 7000
> > 12000
> > 11000
> > 17000
> >
> > This is a socket AM2 processor. Any idea what's wrong? Using kernel
> > 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
>
> Hmm perhaps the formula does not work anymore :/ Can you send me output of
> cat /proc/cpuinfo?

root@joyeuse:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) X2 Dual Core Processor BE-2350
stepping        : 1
cpu MHz         : 2099.919
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips        : 4202.60
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) X2 Dual Core Processor BE-2350
stepping        : 1
cpu MHz         : 2099.919
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips        : 4200.00
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

> Or even better output of cpuid utillity?

root@joyeuse:~# cpuid
 eax in    eax      ebx      ecx      edx
00000000 00000001 68747541 444d4163 69746e65
00000001 00060fb1 01020800 00002001 178bfbff
80000000 80000018 68747541 444d4163 69746e65
80000001 00060fb1 0000464a 0000011f ebd3fbff
80000002 20444d41 6c687441 74286e6f 5820296d
80000003 75442032 43206c61 2065726f 636f7250
80000004 6f737365 45422072 3533322d 00000030
80000005 ff08ff08 ff20ff20 40020140 40020140
80000006 00000000 42004200 02008140 00000000
80000007 00000000 00000000 00000000 0000007f
80000008 00003028 00000000 00000001 00000000
80000009 00000000 00000000 00000000 00000000
8000000a 00000001 00000040 00000000 00000002
8000000b 00000000 00000000 00000000 00000000
8000000c 00000000 00000000 00000000 00000000
8000000d 00000000 00000000 00000000 00000000
8000000e 00000000 00000000 00000000 00000000
8000000f 00000000 00000000 00000000 00000000
80000010 00000000 00000000 00000000 00000000
80000011 00000000 00000000 00000000 00000000
80000012 00000000 00000000 00000000 00000000
80000013 00000000 00000000 00000000 00000000
80000014 00000000 00000000 00000000 00000000
80000015 00000000 00000000 00000000 00000000
80000016 00000000 00000000 00000000 00000000
80000017 00000000 00000000 00000000 00000000
80000018 00000000 00000000 00000000 00000000

Vendor ID: "AuthenticAMD"; CPUID level 1

AMD-specific functions
Version 00060fb1:
Family: 15 Model: 11 []

Standard feature flags 178bfbff:
Floating Point Unit
Virtual Mode Extensions
Debugging Extensions
Page Size Extensions
Time Stamp Counter (with RDTSC and CR4 disable bit)
Model Specific Registers with RDMSR & WRMSR
PAE - Page Address Extensions
Machine Check Exception
COMPXCHG8B Instruction
APIC
SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions
MTRR - Memory Type Range Registers
Global paging extension
Machine Check Architecture
Conditional Move Instruction
PAT - Page Attribute Table
PSE-36 - Page Size Extensions
19 - reserved
MMX instructions
FXSAVE/FXRSTOR
25 - reserved
26 - reserved
28 - reserved
Generation: 15 Model: 11
Extended feature flags ebd3fbff:
Floating Point Unit
Virtual Mode Extensions
Debugging Extensions
Page Size Extensions
Time Stamp Counter (with RDTSC and CR4 disable bit)
Model Specific Registers with RDMSR & WRMSR
PAE - Page Address Extensions
Machine Check Exception
COMPXCHG8B Instruction
APIC
SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions
MTRR - Memory Type Range Registers
Global paging extension
Machine Check Architecture
Conditional Move Instruction
PAT - Page Attribute Table
PSE-36 - Page Size Extensions
20 - reserved
AMD MMX Instruction Extensions
MMX instructions
FXSAVE/FXRSTOR
25 - reserved
27 - reserved
29 - reserved
3DNow! Instruction Extensions
3DNow instructions

Processor name string: AMD Athlon(tm) X2 Dual Core Processor BE-2350
L1 Cache Information:
2/4-MB Pages:
   Data TLB: associativity 255-way #entries 8
   Instruction TLB: associativity 255-way #entries 8
4-KB Pages:
   Data TLB: associativity 255-way #entries 32
   Instruction TLB: associativity 255-way #entries 32
L1 Data cache:
   size 64 KB associativity 2-way lines per tag 1 line size 64
L1 Instruction cache:
   size 64 KB associativity 2-way lines per tag 1 line size 64

L2 Cache Information:
2/4-MB Pages:
   Data TLB: associativity L2 off #entries 0
   Instruction TLB: associativity L2 off #entries 0
4-KB Pages:
   Data TLB: associativity 2-way #entries 0
   Instruction TLB: associativity 2-way #entries 0
   size 2 KB associativity L2 off lines per tag 129 line size 64

Advanced Power Management Feature Flags
Has temperature sensing diode
Supports Frequency ID control
Supports Voltage ID control
Maximum linear address: 48; maximum phys address 40

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Rudolf Marek]

Hi Bernhard!

Sooo... the 49 needs to be substracted even from the LSB bits! Does it 
really work then ;) ? If so then cool,
I will find out what are the CPUIDs for the revF.
> The formula has changed indeed, see page 181 of: 
>
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
>
> I wrote a quick and dirty patch. It works for me on both an old Sempron
> and a Brisbane, but it's not yet production quality ;)
>
> It uses the cpuid "100mhzsteps" flag to decide which formula to use,
> because I couldn't find any information about existing cpuid "model"
> values.
>   
I think I overseen that information, I simply though that the 
temperature will be just truncated to nearest degC.

Please CC the list too. Unfortunately I dont know if I will be online in 
the evening, I moved to flat and still no internet.
For the CPUID range of revF I would suggest to check the
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33610.pdf

Page 7, I think you may use > operator in IF to check if CPUID is bigger 
or equal than first CPUID of the revF series.

Gotta work now ;)



-- 

S přátelským pozdravem / Best regards / Mit freundlichen Grüßen

Ing. Rudolf Marek
SYSGO s.r.o.
Zelený pruh 99
CZ-14800 Praha 4
Phone: +420 222138 627, +49 6136 9948 627
Fax: +420 296374890, +49 6136 9948 1 627
rudolf.marek@sysgo.com

http://www.sysgo.com | http://www.elinos.com | http://www.pikeos.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Bernhard Seibold]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Hi!

On Mo, 2007-09-03 at 12:36 +0200, Rudolf Marek wrote:
> Sooo... the 49 needs to be substracted even from the LSB bits! Does it 
> really work then ;) ? If so then cool,

Seems to works on my Brisbane BE-2350, the reported temperatures look
reasonable.

> For the CPUID range of revF I would suggest to check the
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33610.pdf
> 
> Page 7, I think you may use > operator in IF to check if CPUID is bigger 
> or equal than first CPUID of the revF series.

Thanks, that's what I was looking for.

I revised my patch to use the CPUID model to determine the CPU revision.

The patch now uses a function pointer for the selected conversion
formula. Not sure if you'll like it, but to me it looks better than
using "if" and a macro.

Regards,
Bernhard

[-- Attachment #2: k8temp_brisbane_support.patch --]
[-- Type: text/x-patch, Size: 2063 bytes --]

--- linux/drivers/hwmon/k8temp.c	2007-09-03 17:43:00.000000000 +0200
+++ linux/drivers/hwmon/k8temp.c	2007-09-03 23:24:40.000000000 +0200
@@ -32,7 +32,6 @@
 #include <linux/err.h>
 #include <linux/mutex.h>
 
-#define TEMP_FROM_REG(val)	(((((val) >> 16) & 0xff) - 49) * 1000)
 #define REG_TEMP	0xe4
 #define SEL_PLACE	0x40
 #define SEL_CORE	0x04
@@ -47,6 +46,7 @@ struct k8temp_data {
 	/* registers values */
 	u8 sensorsp;		/* sensor presence bits - SEL_CORE & SEL_PLACE */
 	u32 temp[2][2];		/* core, place */
+	u32 (*convert)(u32);
 };
 
 static struct k8temp_data *k8temp_update_device(struct device *dev)
@@ -94,6 +94,16 @@ static struct k8temp_data *k8temp_update
 	return data;
 }
 
+static u32 convert_rev_f(u32 val)
+{
+	return (((((val) >> 16) & 0xff) - 49) * 1000);
+}
+
+static u32 convert_rev_g(u32 val)
+{
+	return (((((val) >> 14) & 0x3ff) - 49) * 250);
+}
+
 /*
  * Sysfs stuff
  */
@@ -116,8 +126,8 @@ static ssize_t show_temp(struct device *
 	int place = attr->index;
 	struct k8temp_data *data = k8temp_update_device(dev);
 
-	return sprintf(buf, "%d\n",
-		       TEMP_FROM_REG(data->temp[core][place]));
+	u32 temp = data->convert(data->temp[core][place]);
+	return sprintf(buf, "%d\n", temp);
 }
 
 /* core, place */
@@ -142,10 +152,15 @@ static int __devinit k8temp_probe(struct
 	u8 scfg;
 	u32 temp;
 	struct k8temp_data *data;
-	u32 cpuid = cpuid_eax(1);
+	struct cpuinfo_x86 *c = cpu_data;
+
+	if (c->x86 != 15) {
+		err = -ENODEV;
+		goto exit;
+	}
 
 	/* this feature should be available since SH-C0 core */
-	if ((cpuid == 0xf40) || (cpuid == 0xf50) || (cpuid == 0xf51)) {
+	if (c->x86_model < 6 && c->x86_mask < 8) {
 		err = -ENODEV;
 		goto exit;
 	}
@@ -155,6 +170,12 @@ static int __devinit k8temp_probe(struct
 		goto exit;
 	}
 
+	if (c->x86_model < 96) {			/* up to core F */
+		data->convert = &convert_rev_f;
+	} else {
+		data->convert = &convert_rev_g;
+	}
+		
 	pci_read_config_byte(pdev, REG_TEMP, &scfg);
 	scfg &= ~(SEL_PLACE | SEL_CORE);		/* Select sensor 0, core0 */
 	pci_write_config_byte(pdev, REG_TEMP, scfg);

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Rudolf Marek]

Hi Bernhard,

+static u32 convert_rev_f(u32 val)
+{
+	return (((((val) >> 16) & 0xff) - 49) * 1000);
+}
+
+static u32 convert_rev_g(u32 val)
+{
+	return (((((val) >> 14) & 0x3ff) - 49) * 250);
+}

Are you sure those are correct? The datasheets suggest that you need first
extract the 0.25 degC from two lowest bits and THEN subtract 49.

Your code does it first. Your method will work only if AMD made a mistake in
documentation. Are you sure?

Thanks,

Rudolf


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Bernhard Seibold]

On Di, 2007-09-04 at 20:53 +0200, Rudolf Marek wrote:
> Are you sure those are correct? The datasheets suggest that you need first
> extract the 0.25 degC from two lowest bits and THEN subtract 49.
> 
> Your code does it first. Your method will work only if AMD made a mistake in
> documentation. Are you sure?

You're right, it should be (raw * 250) - 49000, as M. G. Berberich also
pointed out to me.

This means the original formula should have worked, so either the
documentation is wrong, or the sensors are broken (as someone at the AMD
forums claims).


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Rudolf Marek]

Bernhard Seibold wrote:
> On Di, 2007-09-04 at 20:53 +0200, Rudolf Marek wrote:
>> Are you sure those are correct? The datasheets suggest that you need first
>> extract the 0.25 degC from two lowest bits and THEN subtract 49.
>>
>> Your code does it first. Your method will work only if AMD made a mistake in
>> documentation. Are you sure?
> 
> You're right, it should be (raw * 250) - 49000, as M. G. Berberich also
> pointed out to me.
> 
> This means the original formula should have worked, so either the
> documentation is wrong, or the sensors are broken (as someone at the AMD
> forums claims).

Yes it is broken, some Errata suggests this :/

Rudolf

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Juergen.Bausa]

Rudolf Marek <rudolf.marek <at> sysgo.com> writes:

> 
> Bernhard Seibold wrote:
> > On Di, 2007-09-04 at 20:53 +0200, Rudolf Marek wrote:
> >> Are you sure those are correct? The datasheets suggest that you need first
> >> extract the 0.25 degC from two lowest bits and THEN subtract 49.
> >>
> >> Your code does it first. Your method will work only if AMD made a mistake in
> >> documentation. Are you sure?
> > 
> > You're right, it should be (raw * 250) - 49000, as M. G. Berberich also
> > pointed out to me.
> > 
> > This means the original formula should have worked, so either the
> > documentation is wrong, or the sensors are broken (as someone at the AMD
> > forums claims).
> 
> Yes it is broken, some Errata suggests this :/
> 

I just installed the patch on my BE-2350 system and the results seem reasonable.
Does this mean that the hardware sensor itself is broken and that the results
are reasonable by chance?

Juergen



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I just installed the patch on my BE-2350 system and the results seem reasonable.
> Does this mean that the hardware sensor itself is broken and that the results
> are reasonable by chance?

No it seems that only certain CPUs have problems. If it is reasonable than it
probably works. What is your CPUID? (cat /proc/cpuinfo or run cpuid util)

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG36p/3J9wPJqZRNURAvveAJ93MDSGly9HBs4LQyO6PI56Hqc4hACeMs/h
C5dEUHaCnW5Mlf44yezRq88=Vm+M
-----END PGP SIGNATURE-----

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Alistair John Strachan]

On Thursday 09 August 2007 07:38:29 Alistair John Strachan wrote:
> On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
> > Hi,
> >
> > Sorry for the delay. I'm CCing the list too please do too.
> >
> > Alistair John Strachan wrote:
> > > Hi,
> > >
> > > I've noticed a problem with the k8temp driver on a new BE-2350
> > > processor. It seems the sensors report bogus values on this CPU. This
> > > is when it is idling:
> > >
> > > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > > -5000
> > > -5000
> > > -3000
> > > 1000
> > >
> > > And this is under load:
> > >
> > > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > > 7000
> > > 12000
> > > 11000
> > > 17000
> > >
> > > This is a socket AM2 processor. Any idea what's wrong? Using kernel
> > > 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
> >
> > Hmm perhaps the formula does not work anymore :/ Can you send me output
> > of cat /proc/cpuinfo?

Sorry to nag, Rudolf, but has there been any progress on this issue?

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Jean Delvare]

Hi Alistair,

On Mon, 8 Oct 2007 00:53:25 +0100, Alistair John Strachan wrote:
> On Thursday 09 August 2007 07:38:29 Alistair John Strachan wrote:
> > On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
> > > Hi,
> > >
> > > Sorry for the delay. I'm CCing the list too please do too.
> > >
> > > Alistair John Strachan wrote:
> > > > Hi,
> > > >
> > > > I've noticed a problem with the k8temp driver on a new BE-2350
> > > > processor. It seems the sensors report bogus values on this CPU. This
> > > > is when it is idling:
> > > >
> > > > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > > > -5000
> > > > -5000
> > > > -3000
> > > > 1000
> > > >
> > > > And this is under load:
> > > >
> > > > root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> > > > 7000
> > > > 12000
> > > > 11000
> > > > 17000
> > > >
> > > > This is a socket AM2 processor. Any idea what's wrong? Using kernel
> > > > 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
> > >
> > > Hmm perhaps the formula does not work anymore :/ Can you send me output
> > > of cat /proc/cpuinfo?
> 
> Sorry to nag, Rudolf, but has there been any progress on this issue?

My understanding is that some K8 CPU series simply have broken thermal
sensors and there's not much we can do about it. In some cases you may
try applying arbitrary offsets to get somewhat realistic (yet
incorrect) values, in others even that won't work.

Maybe we will have to blacklist some CPU series from the k8temp driver
to avoid the confusion.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Moebius]

For me (AMD Athlon x2 64 4400+ and a asus MNPV-VM motherboard) it gives :

cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
-9000
-11000
2000
-15000

and the sensors command seems to give a temp1 value (witch is supposed 
to be the cpu one) lower than the one given by bios when I reboot (don't 
know how to get the bios given temperature without rebooting and seeing 
it in the bios setup)

Welle that's strange and insecure to configure something confident

cordialement,


Jean Delvare a écrit :
> Hi Alistair,
> 
> On Mon, 8 Oct 2007 00:53:25 +0100, Alistair John Strachan wrote:
>> On Thursday 09 August 2007 07:38:29 Alistair John Strachan wrote:
>>> On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
>>>> Hi,
>>>>
>>>> Sorry for the delay. I'm CCing the list too please do too.
>>>>
>>>> Alistair John Strachan wrote:
>>>>> Hi,
>>>>>
>>>>> I've noticed a problem with the k8temp driver on a new BE-2350
>>>>> processor. It seems the sensors report bogus values on this CPU. This
>>>>> is when it is idling:
>>>>>
>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>> -5000
>>>>> -5000
>>>>> -3000
>>>>> 1000
>>>>>
>>>>> And this is under load:
>>>>>
>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>> 7000
>>>>> 12000
>>>>> 11000
>>>>> 17000
>>>>>
>>>>> This is a socket AM2 processor. Any idea what's wrong? Using kernel
>>>>> 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
>>>> Hmm perhaps the formula does not work anymore :/ Can you send me output
>>>> of cat /proc/cpuinfo?
>> Sorry to nag, Rudolf, but has there been any progress on this issue?
> 
> My understanding is that some K8 CPU series simply have broken thermal
> sensors and there's not much we can do about it. In some cases you may
> try applying arbitrary offsets to get somewhat realistic (yet
> incorrect) values, in others even that won't work.
> 
> Maybe we will have to blacklist some CPU series from the k8temp driver
> to avoid the confusion.
> 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Gerold Gruber]

seems I have such a CPU, too:
cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
16000
-6000
5000
5000

from /proc/cpuinfo:
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping        : 1

Board: Asrock AM2NF3-VSTA

regards


Moebius wrote:
> For me (AMD Athlon x2 64 4400+ and a asus MNPV-VM motherboard) it gives :
> 
> cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> -9000
> -11000
> 2000
> -15000
> 
> and the sensors command seems to give a temp1 value (witch is supposed 
> to be the cpu one) lower than the one given by bios when I reboot (don't 
> know how to get the bios given temperature without rebooting and seeing 
> it in the bios setup)
> 
> Welle that's strange and insecure to configure something confident
> 
> cordialement,
> 
> 
> Jean Delvare a écrit :
>> Hi Alistair,
>>
>> On Mon, 8 Oct 2007 00:53:25 +0100, Alistair John Strachan wrote:
>>> On Thursday 09 August 2007 07:38:29 Alistair John Strachan wrote:
>>>> On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
>>>>> Hi,
>>>>>
>>>>> Sorry for the delay. I'm CCing the list too please do too.
>>>>>
>>>>> Alistair John Strachan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've noticed a problem with the k8temp driver on a new BE-2350
>>>>>> processor. It seems the sensors report bogus values on this CPU. This
>>>>>> is when it is idling:
>>>>>>
>>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>>> -5000
>>>>>> -5000
>>>>>> -3000
>>>>>> 1000
>>>>>>
>>>>>> And this is under load:
>>>>>>
>>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>>> 7000
>>>>>> 12000
>>>>>> 11000
>>>>>> 17000
>>>>>>
>>>>>> This is a socket AM2 processor. Any idea what's wrong? Using kernel
>>>>>> 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
>>>>> Hmm perhaps the formula does not work anymore :/ Can you send me output
>>>>> of cat /proc/cpuinfo?
>>> Sorry to nag, Rudolf, but has there been any progress on this issue?
>> My understanding is that some K8 CPU series simply have broken thermal
>> sensors and there's not much we can do about it. In some cases you may
>> try applying arbitrary offsets to get somewhat realistic (yet
>> incorrect) values, in others even that won't work.
>>
>> Maybe we will have to blacklist some CPU series from the k8temp driver
>> to avoid the confusion.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] k8temp, BE-2350 CPU

[Moebius]

I precise with /proc/cpuinfo :

> cpu family      : 15
> model           : 107
> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> stepping        : 2

very similar....


Gerold Gruber a écrit :
> seems I have such a CPU, too:
> cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
> 16000
> -6000
> 5000
> 5000
> 
> from /proc/cpuinfo:
> cpu family      : 15
> model           : 107
> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
> stepping        : 1
> 
> Board: Asrock AM2NF3-VSTA
> 
> regards
> 
> 
> Moebius wrote:
>> For me (AMD Athlon x2 64 4400+ and a asus MNPV-VM motherboard) it gives :
>>
>> cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>> -9000
>> -11000
>> 2000
>> -15000
>>
>> and the sensors command seems to give a temp1 value (witch is supposed 
>> to be the cpu one) lower than the one given by bios when I reboot (don't 
>> know how to get the bios given temperature without rebooting and seeing 
>> it in the bios setup)
>>
>> Welle that's strange and insecure to configure something confident
>>
>> cordialement,
>>
>>
>> Jean Delvare a écrit :
>>> Hi Alistair,
>>>
>>> On Mon, 8 Oct 2007 00:53:25 +0100, Alistair John Strachan wrote:
>>>> On Thursday 09 August 2007 07:38:29 Alistair John Strachan wrote:
>>>>> On Thursday 09 August 2007 06:53:23 Rudolf Marek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for the delay. I'm CCing the list too please do too.
>>>>>>
>>>>>> Alistair John Strachan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've noticed a problem with the k8temp driver on a new BE-2350
>>>>>>> processor. It seems the sensors report bogus values on this CPU. This
>>>>>>> is when it is idling:
>>>>>>>
>>>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>>>> -5000
>>>>>>> -5000
>>>>>>> -3000
>>>>>>> 1000
>>>>>>>
>>>>>>> And this is under load:
>>>>>>>
>>>>>>> root@joyeuse:~# cat /sys/bus/pci/drivers/k8temp/0000\:00\:18.3/temp*
>>>>>>> 7000
>>>>>>> 12000
>>>>>>> 11000
>>>>>>> 17000
>>>>>>>
>>>>>>> This is a socket AM2 processor. Any idea what's wrong? Using kernel
>>>>>>> 2.6.23-rc1, but it's also broken on Debian's 2.6.22.
>>>>>> Hmm perhaps the formula does not work anymore :/ Can you send me output
>>>>>> of cat /proc/cpuinfo?
>>>> Sorry to nag, Rudolf, but has there been any progress on this issue?
>>> My understanding is that some K8 CPU series simply have broken thermal
>>> sensors and there's not much we can do about it. In some cases you may
>>> try applying arbitrary offsets to get somewhat realistic (yet
>>> incorrect) values, in others even that won't work.
>>>
>>> Maybe we will have to blacklist some CPU series from the k8temp driver
>>> to avoid the confusion.
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 
> 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors