[lm-sensors] k8temp

[lm-sensors] k8temp

[Tom Weichmann]

Does anyone know anything about this kernal module?  imsensors-detect 
recommended that I modprobe it, but it is not included with SuSE 10.2 on 
kernal 2.6.18.8.  I can't seem to find anything definateive on the web, is 
this kernal too old to include this module?

Thanks,

Tom Weichmann

[lm-sensors] k8temp

[Curt Blank]

Tom Weichmann wrote:
> Does anyone know anything about this kernal module?  imsensors-detect 
> recommended that I modprobe it, but it is not included with SuSE 10.2 on 
> kernal 2.6.18.8.  I can't seem to find anything definateive on the web, is 
> this kernal too old to include this module?
> 
> Thanks,
> 
> Tom Weichmann
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Hi Tom,

Good timing. I just backported it from 2.6.21 to SuSE 10.1 2.6.16 
yesterday (Wednesday). I would guess that it be the same for you on 10.2 
or you might have to tweak it a bit. I tar'd it up and put it here:

http://www.curtronics.com/patches/
	k8temp_2.6.21_backport_to_SuSE_10.1_2.6.16.tar.gz

It was extremely easy, complied right up once the change was made to the 
pci_ids.h file.

-Curt Blank

Re: [lm-sensors] k8temp

[Rudolf Marek]

Hello John,

Sorry for the delay. I will CC the mailing list.

> I may well be mistaken but it is my belief that K8temp cannot report
> correct on-die temperatures because of a design fault with the 0Fh
> series of Athlon64x2 chip. (See the end of this email for possible
> evidence)

Yes I know about that, so far only one case was spotted by me.

> If you already know this, please do not bother to read on,  though if
> you could tell me of a fix I would very much like to know!!

Well I think this is HW bug.

> 
> Here's what my system does under Ubuntu 7.04
> 
> 
> K8temp correctly reports the four 'temperatures' as
> 
> Register 0xe4=		K8temp reports
> 
> 3a			Core0 Temp:              +4째C
> 7a			Core0 Temp:              -9째C
> 3e			Core1 Temp:              +9째C
> 7e			Core1 Temp:              +1째C
> 
> raw data drawn from a PCI inspection .....
> 
> $ sudo setpci -s 00:18.3 e4.Bz

So you are not setting this as the reg value but this  is just a result (7a)

> $ sudo lspci -s 00:18.3 -xxx
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> e0: 00 00 00 00 7a 20 28 00 19 17 00 00 00 00 00 00
> 
> $ sudo setpci -s 00:18.3 e4.B~
> $ sudo lspci -s 00:18.3 -xxx
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> e0: 00 00 00 00 7e 20 32 00 19 17 00 00 00 00 00 00
> 
> $ sudo setpci -s 00:18.3 e4.B>
> $ sudo lspci -s 00:18.3 -xxx
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> e0: 00 00 00 00 3e 20 3a 00 19 17 00 00 00 00 00 00
> 
> $ sudo setpci -s 00:18.3 e4.B:
> $ sudo lspci -s 00:18.3 -xxx
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> e0: 00 00 00 00 3a 20 35 00 19 17 00 00 00 00 00 00
> 
> 
> And here is the CPU ID data
> 
> $ cpuid
>  eax in    eax      ebx      ecx      edx
> 00000000 00000001 68747541 444d4163 69746e65
> 00000001 00060fb1 01020800 00002001 178bfbff
> 80000000 80000018 68747541 444d4163 69746e65
> 80000001 00060fb1 000008cb 0000011f ebd3fbff
> 80000002 20444d41 6c687441 74286e6f 3620296d
> 80000003 32582034 61754420 6f43206c 50206572
> 80000004 65636f72 726f7373 30363320 00002b30
> 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

Well did sensors-detect found any other sensors?
Does this bogus temperature change and when you load CPU?

Thanks for the information,

Rudolf

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

Re: [lm-sensors] k8temp

[Philip Pokorny]

>>raw data drawn from a PCI inspection .....
>>
>>$ sudo setpci -s 00:18.3 e4.Bz
>>    
>>
>
>So you are not setting this as the reg value but this  is just a result (7a)
>  
>
No, that command *writes* 7A to PCI space register offset E4.

>>$ sudo lspci -s 00:18.3 -xxx
>>00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
>>e0: 00 00 00 00 7a 20 28 00 19 17 00 00 00 00 00 00
>>    
>>

Which values are of interest here?

Do you know that you can read PCI space using setpci like so:

[root@beluga ~]# setpci -v -s 00:18.3 e4.b e4.w e6.w
00:18.3:e4 = 20
00:18.3:e4 = 0f20
00:18.3:e6 = 164c

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

Re: [lm-sensors] k8temp

[John Tindle]

Philip and Rudolf

Thanks for your swift replies, much appreciated.

Just to clarify, the 32 bit register at 0xE4 of the AMD64x2 is the
thermotrip status register:- 
	
Bits   Function                                         R/W    Reset
31     Software Thermtrip  	                         W      0
30–29  reserved                                          R      0
28-24  Tj Offset                                         R      0
23-14  Current Temperature                               R
13–8   Diode Offset                                      R
7	reserved                                         R      0
6      Thermal Sensor Select                           R/W      0
5      Thermtrip Enabled                                 R
4      Thermtrip Sense 1                                 R
3      Thermtrip Sense 0                                 R
2      Thermal Sensor Core Select                      R/W      0
1      Thermtrip    					 R
0	reserved	   				 R      0

So reading 0xE6 gets the current temperature from one of the four
sensors  selected by setting or clearing bits 2 and 6 in 0xe4
(the bottom two bits of the temperature, which are the high two bits in
0xE5 represent fractions of a degree, but can be ignored by K8temp
without a problem)  

As K8temp correctly implements, the temperature is given by: (Snipped
from AMD documentation), 

       Revision F encodings bits 23-16 (ignore bits 15-14)
       00h = -49C
       01h = -48C
       ...
       ffh = 206C


       Revision G encodings bits 23-14
       000h = -49.00C
       001h = -48.75C
       002h = -48.50C
       003h = -48.25C
       004h = -48.00C
       ...
       0C4h = 0.00C
       ...
       3ffh = 206.75C



So the examples I gave show K8temp reporting temperatures at or below
0C. Examining the register at 0xE6 confirms that K8temp is working
correctly.

Rudolph, you mention having seen this problem before.  It would
certainly be a hardware bug and my reason for mentioning it is so that
k8temp does not get a bad name with the community.
Have you heard whether AMD are proposing to do something about it?

In summary, there will be nothing that you can do about such a problem,
except perhaps record the issue in the snag list.



Again, thanks for your time and attention.  If I can do more to help,
just ask

Regards

John






On Wed, 2007-05-16 at 14:16 -0700, Philip Pokorny wrote:
> >>raw data drawn from a PCI inspection .....
> >>
> >>$ sudo setpci -s 00:18.3 e4.Bz
> >>    
> >>
> >
> >So you are not setting this as the reg value but this  is just a result (7a)
> >  
> >
> No, that command *writes* 7A to PCI space register offset E4.
> 
> >>$ sudo lspci -s 00:18.3 -xxx
> >>00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> >>e0: 00 00 00 00 7a 20 28 00 19 17 00 00 00 00 00 00
> >>    
> >>
> 
> Which values are of interest here?
> 
> Do you know that you can read PCI space using setpci like so:
> 
> [root@beluga ~]# setpci -v -s 00:18.3 e4.b e4.w e6.w
> 00:18.3:e4 = 20
> 00:18.3:e4 = 0f20
> 00:18.3:e6 = 164c
> .
> 



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

Re: [lm-sensors] k8temp

[Rudolf Marek]

Hello all,

For Philip :
>No, that command *writes* 7A to PCI space register offset E4.

Yeah of course. I was half sleeping when I wrote the mail.
> 
> Just to clarify, the 32 bit register at 0xE4 of the AMD64x2 is the
> thermotrip status register:- 
> 	
> Bits   Function                                         R/W    Reset
> 31     Software Thermtrip  	                         W      0
> 30–29  reserved                                          R      0
> 28-24  Tj Offset                                         R      0
> 23-14  Current Temperature                               R
> 13–8   Diode Offset                                      R
> 7	reserved                                         R      0
> 6      Thermal Sensor Select                           R/W      0
> 5      Thermtrip Enabled                                 R
> 4      Thermtrip Sense 1                                 R
> 3      Thermtrip Sense 0                                 R
> 2      Thermal Sensor Core Select                      R/W      0
> 1      Thermtrip    					 R
> 0	reserved	   				 R      0
> 
> So reading 0xE6 gets the current temperature from one of the four
> sensors  selected by setting or clearing bits 2 and 6 in 0xe4
> (the bottom two bits of the temperature, which are the high two bits in
> 0xE5 represent fractions of a degree, but can be ignored by K8temp
> without a problem)  

Yes this was not added yet.

> As K8temp correctly implements, the temperature is given by: (Snipped
> from AMD documentation), 
> 
>        Revision F encodings bits 23-16 (ignore bits 15-14)
>        00h = -49C
>        01h = -48C
>        ...
>        ffh = 206C
> 
> 
>        Revision G encodings bits 23-14
>        000h = -49.00C
>        001h = -48.75C
>        002h = -48.50C
>        003h = -48.25C
>        004h = -48.00C
>        ...
>        0C4h = 0.00C
>        ...
>        3ffh = 206.75C
> 
> 
> 
> So the examples I gave show K8temp reporting temperatures at or below
> 0C. Examining the register at 0xE6 confirms that K8temp is working
> correctly.
> 
> Rudolph, you mention having seen this problem before.  It would
> certainly be a hardware bug and my reason for mentioning it is so that
> k8temp does not get a bad name with the community.
> Have you heard whether AMD are proposing to do something about it?

Well I'm in touch with author of "coretemp" utility for windows. It seems all
brisbane processors (same cpuid as yours) are affected. Some have offset 15-20
(compared to diode measured temp with ext sensor) some have even more, like yours.

As for the diode offset. Your CPU has set this to 0x20 so it is
10000 and complement of 011111 -52+31 offset is -21C if I count correctly
(probably not ;)  This is quite interesting because my CPU has offset 0x3 (but
have revE must check if the bits are same)

Question is how to apply the offset? They say TMax = diode + offset;
I still think that the offset field is for real diode only, however here it
indicates that something went wrong...

I will think about it later, gotta go now.

Rudolf

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

Re: [lm-sensors] k8temp

[John Tindle]

Rudolph et al

Yeah,  I've finally found a thread 

http://www.silentpcreview.com/forums/viewtopic.php?t@290

which shows lots of people with the same problem with Brisbane cores.  

The only solution would be to set custom offsets for each CPU.

On the diode offset, Rudolph you are right this offset applies to an off
die sensor

Regards

John




On Fri, 2007-05-18 at 11:10 +0200, Rudolf Marek wrote:
> Hello all,
> 
> For Philip :
> >No, that command *writes* 7A to PCI space register offset E4.
> 
> Yeah of course. I was half sleeping when I wrote the mail.
> > 
> > Just to clarify, the 32 bit register at 0xE4 of the AMD64x2 is the
> > thermotrip status register:- 
> > 	
> > Bits   Function                                         R/W    Reset
> > 31     Software Thermtrip  	                         W      0
> > 30–29  reserved                                          R      0
> > 28-24  Tj Offset                                         R      0
> > 23-14  Current Temperature                               R
> > 13–8   Diode Offset                                      R
> > 7	reserved                                         R      0
> > 6      Thermal Sensor Select                           R/W      0
> > 5      Thermtrip Enabled                                 R
> > 4      Thermtrip Sense 1                                 R
> > 3      Thermtrip Sense 0                                 R
> > 2      Thermal Sensor Core Select                      R/W      0
> > 1      Thermtrip    					 R
> > 0	reserved	   				 R      0
> > 
> > So reading 0xE6 gets the current temperature from one of the four
> > sensors  selected by setting or clearing bits 2 and 6 in 0xe4
> > (the bottom two bits of the temperature, which are the high two bits in
> > 0xE5 represent fractions of a degree, but can be ignored by K8temp
> > without a problem)  
> 
> Yes this was not added yet.
> 
> > As K8temp correctly implements, the temperature is given by: (Snipped
> > from AMD documentation), 
> > 
> >        Revision F encodings bits 23-16 (ignore bits 15-14)
> >        00h = -49C
> >        01h = -48C
> >        ...
> >        ffh = 206C
> > 
> > 
> >        Revision G encodings bits 23-14
> >        000h = -49.00C
> >        001h = -48.75C
> >        002h = -48.50C
> >        003h = -48.25C
> >        004h = -48.00C
> >        ...
> >        0C4h = 0.00C
> >        ...
> >        3ffh = 206.75C
> > 
> > 
> > 
> > So the examples I gave show K8temp reporting temperatures at or below
> > 0C. Examining the register at 0xE6 confirms that K8temp is working
> > correctly.
> > 
> > Rudolph, you mention having seen this problem before.  It would
> > certainly be a hardware bug and my reason for mentioning it is so that
> > k8temp does not get a bad name with the community.
> > Have you heard whether AMD are proposing to do something about it?
> 
> Well I'm in touch with author of "coretemp" utility for windows. It seems all
> brisbane processors (same cpuid as yours) are affected. Some have offset 15-20
> (compared to diode measured temp with ext sensor) some have even more, like yours.
> 
> As for the diode offset. Your CPU has set this to 0x20 so it is
> 10000 and complement of 011111 -52+31 offset is -21C if I count correctly
> (probably not ;)  This is quite interesting because my CPU has offset 0x3 (but
> have revE must check if the bits are same)
> 
> Question is how to apply the offset? They say TMax = diode + offset;
> I still think that the offset field is for real diode only, however here it
> indicates that something went wrong...
> 
> I will think about it later, gotta go now.
> 
> Rudolf
> .
> 



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

Re: [lm-sensors] k8temp

[John Tindle]

Sorry premature click syndrome:-  I should have added that my sensors
seem to rise and fall in reasonable accord with the off die sensor.  So
I've added compute lines to sensors.conf.  I'll let you know

On Sat, 2007-05-19 at 01:25 +0200, John Tindle wrote:
> Rudolph et al
> 
> Yeah,  I've finally found a thread 
> 
> http://www.silentpcreview.com/forums/viewtopic.php?t@290
> 
> which shows lots of people with the same problem with Brisbane cores.  
> 
> The only solution would be to set custom offsets for each CPU.
> 
> On the diode offset, Rudolph you are right this offset applies to an off
> die sensor
> 
> Regards
> 
> John
> 
> 
> 
> 
> On Fri, 2007-05-18 at 11:10 +0200, Rudolf Marek wrote:
> > Hello all,
> > 
> > For Philip :
> > >No, that command *writes* 7A to PCI space register offset E4.
> > 
> > Yeah of course. I was half sleeping when I wrote the mail.
> > > 
> > > Just to clarify, the 32 bit register at 0xE4 of the AMD64x2 is the
> > > thermotrip status register:- 
> > > 	
> > > Bits   Function                                         R/W    Reset
> > > 31     Software Thermtrip  	                         W      0
> > > 30–29  reserved                                          R      0
> > > 28-24  Tj Offset                                         R      0
> > > 23-14  Current Temperature                               R
> > > 13–8   Diode Offset                                      R
> > > 7	reserved                                         R      0
> > > 6      Thermal Sensor Select                           R/W      0
> > > 5      Thermtrip Enabled                                 R
> > > 4      Thermtrip Sense 1                                 R
> > > 3      Thermtrip Sense 0                                 R
> > > 2      Thermal Sensor Core Select                      R/W      0
> > > 1      Thermtrip    					 R
> > > 0	reserved	   				 R      0
> > > 
> > > So reading 0xE6 gets the current temperature from one of the four
> > > sensors  selected by setting or clearing bits 2 and 6 in 0xe4
> > > (the bottom two bits of the temperature, which are the high two bits in
> > > 0xE5 represent fractions of a degree, but can be ignored by K8temp
> > > without a problem)  
> > 
> > Yes this was not added yet.
> > 
> > > As K8temp correctly implements, the temperature is given by: (Snipped
> > > from AMD documentation), 
> > > 
> > >        Revision F encodings bits 23-16 (ignore bits 15-14)
> > >        00h = -49C
> > >        01h = -48C
> > >        ...
> > >        ffh = 206C
> > > 
> > > 
> > >        Revision G encodings bits 23-14
> > >        000h = -49.00C
> > >        001h = -48.75C
> > >        002h = -48.50C
> > >        003h = -48.25C
> > >        004h = -48.00C
> > >        ...
> > >        0C4h = 0.00C
> > >        ...
> > >        3ffh = 206.75C
> > > 
> > > 
> > > 
> > > So the examples I gave show K8temp reporting temperatures at or below
> > > 0C. Examining the register at 0xE6 confirms that K8temp is working
> > > correctly.
> > > 
> > > Rudolph, you mention having seen this problem before.  It would
> > > certainly be a hardware bug and my reason for mentioning it is so that
> > > k8temp does not get a bad name with the community.
> > > Have you heard whether AMD are proposing to do something about it?
> > 
> > Well I'm in touch with author of "coretemp" utility for windows. It seems all
> > brisbane processors (same cpuid as yours) are affected. Some have offset 15-20
> > (compared to diode measured temp with ext sensor) some have even more, like yours.
> > 
> > As for the diode offset. Your CPU has set this to 0x20 so it is
> > 10000 and complement of 011111 -52+31 offset is -21C if I count correctly
> > (probably not ;)  This is quite interesting because my CPU has offset 0x3 (but
> > have revE must check if the bits are same)
> > 
> > Question is how to apply the offset? They say TMax = diode + offset;
> > I still think that the offset field is for real diode only, however here it
> > indicates that something went wrong...
> > 
> > I will think about it later, gotta go now.
> > 
> > Rudolf
> > .
> > 



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