[lm-sensors] Sandy Bridge support?

[lm-sensors] Sandy Bridge support?

[DarkNovaNick]

[-- Attachment #1.1: Type: text/plain, Size: 7526 bytes --]

I recently bought the new Intel Sandy Bridge processor, i5-2500k, along  
with a Gigabyte GA-H67A-UD3H motherboard. I've used lm_sensors in the past  
and am trying to get it to work with my new setup (on Ubuntu 10.10 kernel  
2.6.35-24). I downloaded the latest version of the sensors-detect script  
from the website and it was not able to find any sensors. Here is the  
output:

---------

# sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
# System: Gigabyte Technology Co., Ltd. H67A-UD3H

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
Intel Core family thermal sensor... No
Intel Atom thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... Yes
Found unknown chip with ID 0x8728
(logical device 4 has address 0x290, could be sensors)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel Cougar Point (PCH)
Module i2c-i801 loaded successfully.
Module i2c-dev loaded successfully.

Next adapter: saa7133[0] (i2c-0)
Do you want to scan it? (yes/NO/selectively):

Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-3)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-4)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-5)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)

Next adapter: NVIDIA i2c adapter (i2c-6)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-7)
Do you want to scan it? (YES/no/selectively):

Next adapter: NVIDIA i2c adapter (i2c-8)
Do you want to scan it? (YES/no/selectively):

Next adapter: SMBus I801 adapter at 0500 (i2c-9)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x4e
Probing for `National Semiconductor LM75'... No
Probing for `Dallas Semiconductor DS75'... No
Probing for `Dallas Semiconductor DS1621/DS1631'... No
Probing for `Analog Devices ADM1021'... No
Probing for `Analog Devices ADM1021A/ADM1023'... No
Probing for `Maxim MAX1617'... No
Probing for `Maxim MAX1617A'... No
Probing for `Maxim MAX1668'... No
Probing for `Maxim MAX1805'... No
Probing for `Maxim MAX1989'... No
Probing for `Maxim MAX6655/MAX6656'... No
Probing for `TI THMC10'... No
Probing for `National Semiconductor LM84'... No
Probing for `Genesys Logic GL523SM'... No
Probing for `Onsemi MC1066'... No
Probing for `Maxim MAX1618'... No
Probing for `Maxim MAX1619'... No
Probing for `National Semiconductor LM82/LM83'... No
Probing for `Maxim MAX6654'... No
Probing for `Maxim MAX6690'... No
Probing for `Maxim MAX6659'... No
Probing for `Maxim MAX6647'... No
Probing for `Maxim MAX6680/MAX6681'... No
Probing for `Maxim MAX6695/MAX6696'... No
Probing for `Texas Instruments TMP411'... No
Probing for `Texas Instruments TMP421'... No
Probing for `Texas Instruments TMP422'... No
Probing for `Texas Instruments AMC6821'... No
Probing for `National Semiconductor LM64'... No
Probing for `National Semiconductor LM73'... No
Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
Probing for `Fintek F75121R/F75122R/RG (VID+GPIO)'... No
Probing for `Fintek F75111R/RG/N (GPIO)'... No
Probing for `ITE IT8201R/IT8203R/IT8206R/IT8266R'... Yes
(confidence 6, not a hardware monitoring chip)
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No

Sorry, no sensors were detected.
Either your system has no sensors, or they are not supported, or
they are connected to an I2C or SMBus adapter that is not
supported. If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.

----------------

I also tried running i2c-detect on "SMBus I801 adapter at 0500", here is  
the output:

-------------

0 1 2 3 4 5 6 7 8 9 abcdef
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: 10 11 -- 13 14 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- 4e --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

------------

Is there anything else I can do to get this working, or help by providing  
some more info, or is just a matter of waiting until there is support for  
Sandy Bridge? Or am I doing something wrong? Thanks,

Nick

[-- Attachment #1.2: Type: text/html, Size: 10547 bytes --]

[-- Attachment #2: 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] Sandy Bridge support?

[Guenter Roeck]

On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:
> I recently bought the new Intel Sandy Bridge processor, i5-2500k,
> along with a Gigabyte GA-H67A-UD3H motherboard. I've used lm_sensors
> in the past and am trying to get it to work with my new setup (on
> Ubuntu 10.10 kernel 2.6.35-24). I downloaded the latest version of the
> sensors-detect script from the website and it was not able to find any
> sensors. Here is the output:
> 
> ---------
> 
> # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
> # System: Gigabyte Technology Co., Ltd. H67A-UD3H
> 
> This program will help you determine which kernel modules you need
> to load to use lm_sensors most effectively. It is generally safe
> and recommended to accept the default answers to all questions,
> unless you know what you're doing.
> 
> Some south bridges, CPUs or memory controllers contain embedded
> sensors.
> Do you want to scan for them? This is totally safe. (YES/no): 
> Silicon Integrated Systems SIS5595... No
> VIA VT82C686 Integrated Sensors... No
> VIA VT8231 Integrated Sensors... No
> AMD K8 thermal sensors... No
> AMD Family 10h thermal sensors... No
> AMD Family 11h thermal sensors... No
> Intel Core family thermal sensor... No
> Intel Atom thermal sensor... No
> Intel AMB FB-DIMM thermal sensor... No
> VIA C7 thermal sensor... No
> VIA Nano thermal sensor... No
> 
> Some Super I/O chips contain embedded sensors. We have to write to
> standard I/O ports to probe them. This is usually safe.
> Do you want to scan for Super I/O sensors? (YES/no): 
> Probing for Super-I/O at 0x2e/0x2f
> Trying family `National Semiconductor'... No
> Trying family `SMSC'... No
> Trying family `VIA/Winbond/Nuvoton/Fintek'... No
> Trying family `ITE'... Yes
> Found unknown chip with ID 0x8728
> (logical device 4 has address 0x290, could be sensors)

The problem is more likely that the SuperIO chip used in your system is
not supported. If so, your problem doesn't have anything to do with
SandyBridge.

Guenter



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

Re: [lm-sensors] Sandy Bridge support?

[Anish Patel]

On 01/17/11 16:54, Guenter Roeck wrote:
> On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:
>> I recently bought the new Intel Sandy Bridge processor, i5-2500k,
>> along with a Gigabyte GA-H67A-UD3H motherboard. I've used lm_sensors
>> in the past and am trying to get it to work with my new setup (on
>> Ubuntu 10.10 kernel 2.6.35-24). I downloaded the latest version of the
>> sensors-detect script from the website and it was not able to find any
>> sensors. Here is the output:
>>
>> ---------
>>
>> # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
>> # System: Gigabyte Technology Co., Ltd. H67A-UD3H
>>
>> This program will help you determine which kernel modules you need
>> to load to use lm_sensors most effectively. It is generally safe
>> and recommended to accept the default answers to all questions,
>> unless you know what you're doing.
>>
>> Some south bridges, CPUs or memory controllers contain embedded
>> sensors.
>> Do you want to scan for them? This is totally safe. (YES/no):
>> Silicon Integrated Systems SIS5595... No
>> VIA VT82C686 Integrated Sensors... No
>> VIA VT8231 Integrated Sensors... No
>> AMD K8 thermal sensors... No
>> AMD Family 10h thermal sensors... No
>> AMD Family 11h thermal sensors... No
>> Intel Core family thermal sensor... No
>> Intel Atom thermal sensor... No
>> Intel AMB FB-DIMM thermal sensor... No
>> VIA C7 thermal sensor... No
>> VIA Nano thermal sensor... No
>>
>> Some Super I/O chips contain embedded sensors. We have to write to
>> standard I/O ports to probe them. This is usually safe.
>> Do you want to scan for Super I/O sensors? (YES/no):
>> Probing for Super-I/O at 0x2e/0x2f
>> Trying family `National Semiconductor'... No
>> Trying family `SMSC'... No
>> Trying family `VIA/Winbond/Nuvoton/Fintek'... No
>> Trying family `ITE'... Yes
>> Found unknown chip with ID 0x8728
>> (logical device 4 has address 0x290, could be sensors)
> The problem is more likely that the SuperIO chip used in your system is
> not supported. If so, your problem doesn't have anything to do with
> SandyBridge.
>
> Guenter
>
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
i think the more likely problem is that his kernel doesn't know about 
the sandy bridge thermal diode.
the coretemp module probably needs an update.


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

Re: [lm-sensors] Sandy Bridge support?

[Guenter Roeck]

On Mon, 2011-01-17 at 17:26 -0500, Anish Patel wrote:
> On 01/17/11 16:54, Guenter Roeck wrote:
> > On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:
> >> I recently bought the new Intel Sandy Bridge processor, i5-2500k,
> >> along with a Gigabyte GA-H67A-UD3H motherboard. I've used lm_sensors
> >> in the past and am trying to get it to work with my new setup (on
> >> Ubuntu 10.10 kernel 2.6.35-24). I downloaded the latest version of the
> >> sensors-detect script from the website and it was not able to find any
> >> sensors. Here is the output:
> >>
> >> ---------
> >>
> >> # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
> >> # System: Gigabyte Technology Co., Ltd. H67A-UD3H
> >>
> >> This program will help you determine which kernel modules you need
> >> to load to use lm_sensors most effectively. It is generally safe
> >> and recommended to accept the default answers to all questions,
> >> unless you know what you're doing.
> >>
> >> Some south bridges, CPUs or memory controllers contain embedded
> >> sensors.
> >> Do you want to scan for them? This is totally safe. (YES/no):
> >> Silicon Integrated Systems SIS5595... No
> >> VIA VT82C686 Integrated Sensors... No
> >> VIA VT8231 Integrated Sensors... No
> >> AMD K8 thermal sensors... No
> >> AMD Family 10h thermal sensors... No
> >> AMD Family 11h thermal sensors... No
> >> Intel Core family thermal sensor... No
> >> Intel Atom thermal sensor... No
> >> Intel AMB FB-DIMM thermal sensor... No
> >> VIA C7 thermal sensor... No
> >> VIA Nano thermal sensor... No
> >>
> >> Some Super I/O chips contain embedded sensors. We have to write to
> >> standard I/O ports to probe them. This is usually safe.
> >> Do you want to scan for Super I/O sensors? (YES/no):
> >> Probing for Super-I/O at 0x2e/0x2f
> >> Trying family `National Semiconductor'... No
> >> Trying family `SMSC'... No
> >> Trying family `VIA/Winbond/Nuvoton/Fintek'... No
> >> Trying family `ITE'... Yes
> >> Found unknown chip with ID 0x8728
> >> (logical device 4 has address 0x290, could be sensors)
> > The problem is more likely that the SuperIO chip used in your system is
> > not supported. If so, your problem doesn't have anything to do with
> > SandyBridge.
> >
> > Guenter
> >
> >
> >
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >
> i think the more likely problem is that his kernel doesn't know about 
> the sandy bridge thermal diode.
> the coretemp module probably needs an update.
> 
The coretemp driver checks CPU registers to determine if the CPU
supports thermal sensors or not; Sandy Bridge specific changes should
not be necessary for this to work. Maybe it would help to simply enter
"modprobe coretemp".

Guenter



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

Re: [lm-sensors] Sandy Bridge support?

[DarkNovaNick]

[-- Attachment #1.1: Type: text/plain, Size: 3375 bytes --]

On Jan 17, 2011 4:53pm, Guenter Roeck <guenter.roeck@ericsson.com> wrote:
> On Mon, 2011-01-17 at 17:26 -0500, Anish Patel wrote:

> > On 01/17/11 16:54, Guenter Roeck wrote:

> > > On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:

> > >> I recently bought the new Intel Sandy Bridge processor, i5-2500k,

> > >> along with a Gigabyte GA-H67A-UD3H motherboard. I've used lm_sensors

> > >> in the past and am trying to get it to work with my new setup (on

> > >> Ubuntu 10.10 kernel 2.6.35-24). I downloaded the latest version of  
> the

> > >> sensors-detect script from the website and it was not able to find  
> any

> > >> sensors. Here is the output:

> > >>

> > >> ---------

> > >>

> > >> # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)

> > >> # System: Gigabyte Technology Co., Ltd. H67A-UD3H

> > >>

> > >> This program will help you determine which kernel modules you need

> > >> to load to use lm_sensors most effectively. It is generally safe

> > >> and recommended to accept the default answers to all questions,

> > >> unless you know what you're doing.

> > >>

> > >> Some south bridges, CPUs or memory controllers contain embedded

> > >> sensors.

> > >> Do you want to scan for them? This is totally safe. (YES/no):

> > >> Silicon Integrated Systems SIS5595... No

> > >> VIA VT82C686 Integrated Sensors... No

> > >> VIA VT8231 Integrated Sensors... No

> > >> AMD K8 thermal sensors... No

> > >> AMD Family 10h thermal sensors... No

> > >> AMD Family 11h thermal sensors... No

> > >> Intel Core family thermal sensor... No

> > >> Intel Atom thermal sensor... No

> > >> Intel AMB FB-DIMM thermal sensor... No

> > >> VIA C7 thermal sensor... No

> > >> VIA Nano thermal sensor... No

> > >>

> > >> Some Super I/O chips contain embedded sensors. We have to write to

> > >> standard I/O ports to probe them. This is usually safe.

> > >> Do you want to scan for Super I/O sensors? (YES/no):

> > >> Probing for Super-I/O at 0x2e/0x2f

> > >> Trying family `National Semiconductor'... No

> > >> Trying family `SMSC'... No

> > >> Trying family `VIA/Winbond/Nuvoton/Fintek'... No

> > >> Trying family `ITE'... Yes

> > >> Found unknown chip with ID 0x8728

> > >> (logical device 4 has address 0x290, could be sensors)

> > > The problem is more likely that the SuperIO chip used in your system  
> is

> > > not supported. If so, your problem doesn't have anything to do with

> > > SandyBridge.

> > >

> > > Guenter

> > >

> > >

> > >

> > > _______________________________________________

> > > lm-sensors mailing list

> > > lm-sensors@lm-sensors.org

> > > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

> > >

> > i think the more likely problem is that his kernel doesn't know about

> > the sandy bridge thermal diode.

> > the coretemp module probably needs an update.

> >

> The coretemp driver checks CPU registers to determine if the CPU

> supports thermal sensors or not; Sandy Bridge specific changes should

> not be necessary for this to work. Maybe it would help to simply enter

> "modprobe coretemp".



> Guenter








I just tried doing "modprobe coretemp" and then when I did "sensors" it  
seemed to output correctly. I'm not sure why I didn't think of that --  
thanks. sensors-detect still does not suggest coretemp or any other modules  
to load though. Thanks,

Nick

[-- Attachment #1.2: Type: text/html, Size: 5210 bytes --]

[-- Attachment #2: 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] Sandy Bridge support?

[Jean Delvare]

On Mon, 17 Jan 2011 13:54:30 -0800, Guenter Roeck wrote:
> On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:
> > # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
> > # System: Gigabyte Technology Co., Ltd. H67A-UD3H
> > (...)
> > Some Super I/O chips contain embedded sensors. We have to write to
> > standard I/O ports to probe them. This is usually safe.
> > Do you want to scan for Super I/O sensors? (YES/no): 
> > Probing for Super-I/O at 0x2e/0x2f
> > Trying family `National Semiconductor'... No
> > Trying family `SMSC'... No
> > Trying family `VIA/Winbond/Nuvoton/Fintek'... No
> > Trying family `ITE'... Yes
> > Found unknown chip with ID 0x8728
> > (logical device 4 has address 0x290, could be sensors)
> 
> The problem is more likely that the SuperIO chip used in your system is
> not supported. If so, your problem doesn't have anything to do with
> SandyBridge.

This would be an ITE8728F, ITE's latest Super-I/O chip. Nick, can you
confirm this by visual inspection? The chip should look like this:
http://img713.imageshack.us/img713/3831/it8728fsmall.jpg

-- 
Jean Delvare

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

Re: [lm-sensors] Sandy Bridge support?

[Jean Delvare]

On Mon, 17 Jan 2011 23:26:03 +0000, DarkNovaNick@gmail.com wrote:
> I just tried doing "modprobe coretemp" and then when I did "sensors" it  
> seemed to output correctly. I'm not sure why I didn't think of that --  
> thanks. sensors-detect still does not suggest coretemp or any other modules  
> to load though. Thanks,

The problem is that sensors-detect and coretemp don't agree on the
detection method. The coretemp driver now checks CPU flags, while
sensors-detect still uses the old method of checking the CPU model. And
list of supported CPU models hasn't been updated for quite a while.

Unfortunately, the kernel detection method seems difficult to implement
in user-space. One would have to mess with binary access
to /dev/cpu/*/cpuid, which may not even be available on all systems.

-- 
Jean Delvare

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

Re: [lm-sensors] Sandy Bridge support?

[Nick Hall]

[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]

On Tue, Jan 18, 2011 at 2:46 AM, Jean Delvare <khali@linux-fr.org> wrote:

> On Mon, 17 Jan 2011 13:54:30 -0800, Guenter Roeck wrote:
> > On Mon, 2011-01-17 at 15:26 -0500, DarkNovaNick@gmail.com wrote:
> > > # sensors-detect revision 5901 (2011-01-14 17:11:54 +0100)
> > > # System: Gigabyte Technology Co., Ltd. H67A-UD3H
> > > (...)
> > > Some Super I/O chips contain embedded sensors. We have to write to
> > > standard I/O ports to probe them. This is usually safe.
> > > Do you want to scan for Super I/O sensors? (YES/no):
> > > Probing for Super-I/O at 0x2e/0x2f
> > > Trying family `National Semiconductor'... No
> > > Trying family `SMSC'... No
> > > Trying family `VIA/Winbond/Nuvoton/Fintek'... No
> > > Trying family `ITE'... Yes
> > > Found unknown chip with ID 0x8728
> > > (logical device 4 has address 0x290, could be sensors)
> >
> > The problem is more likely that the SuperIO chip used in your system is
> > not supported. If so, your problem doesn't have anything to do with
> > SandyBridge.
>
> This would be an ITE8728F, ITE's latest Super-I/O chip. Nick, can you
> confirm this by visual inspection? The chip should look like this:
> http://img713.imageshack.us/img713/3831/it8728fsmall.jpg
>
> --
> Jean Delvare
>

Thanks, I checked and my motherboard did indeed have that chip. The only
difference, if it matters, is that under the "IT8728F" mine had "1039-CXS"
and "ZC46FBGB".

And regarding the sensors-detect script, I understand now. If anyone is
interested, my Sandy Bridge processor would be model "0x2A" according to how
that script does things.

Nick

[-- Attachment #1.2: Type: text/html, Size: 2333 bytes --]

[-- Attachment #2: 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] Sandy Bridge support?

[Jean Delvare]

Hi Nick,

On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:
> Thanks, I checked and my motherboard did indeed have that chip. The only
> difference, if it matters, is that under the "IT8728F" mine had "1039-CXS"
> and "ZC46FBGB".

OK, thanks. If you feel lucky, you may try to load the it87 driver with
parameter force_id, to force the driver to consider your chip as one it
supports. Given the name of your device, the first values to try would
be 0x8721 and 0x8720 (the two most recent chips) or 0x8718 (in case the
IT8728F is an evolution of the IT8718F - I remember the IT8716F and
IT8726F were compatible.) If you give this a try, please let us know
the results.

Or you can wait for us to get a datasheet for the IT8728F. We currently
don't have it. The device isnt' even listed on ITE's website.

> And regarding the sensors-detect script, I understand now. If anyone is
> interested, my Sandy Bridge processor would be model "0x2A" according to how
> that script does things.

This is an option, yes, but it would be better if we could implement
the same detection logic as the coretemp driver has. For one thing, this
would guarantee that the two are always in sync. For another, it would
lower the maintenance effort from our side, as the new detection logic
is universal and doesn't need to be updated with every new CPU model.
I'm looking into it but this is non-trivial.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

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

Re: [lm-sensors] Sandy Bridge support?

[DarkNovaNick]

[-- Attachment #1.1: Type: text/plain, Size: 1764 bytes --]

On Jan 18, 2011 10:32am, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Nick,



> On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:

> > Thanks, I checked and my motherboard did indeed have that chip. The only

> > difference, if it matters, is that under the "IT8728F" mine  
> had "1039-CXS"

> > and "ZC46FBGB".



> OK, thanks. If you feel lucky, you may try to load the it87 driver with

> parameter force_id, to force the driver to consider your chip as one it

> supports. Given the name of your device, the first values to try would

> be 0x8721 and 0x8720 (the two most recent chips) or 0x8718 (in case the

> IT8728F is an evolution of the IT8718F - I remember the IT8716F and

> IT8726F were compatible.) If you give this a try, please let us know

> the results.



> Or you can wait for us to get a datasheet for the IT8728F. We currently

> don't have it. The device isnt' even listed on ITE's website.



> > And regarding the sensors-detect script, I understand now. If anyone is

> > interested, my Sandy Bridge processor would be model "0x2A" according  
> to how

> > that script does things.



> This is an option, yes, but it would be better if we could implement

> the same detection logic as the coretemp driver has. For one thing, this

> would guarantee that the two are always in sync. For another, it would

> lower the maintenance effort from our side, as the new detection logic

> is universal and doesn't need to be updated with every new CPU model.

> I'm looking into it but this is non-trivial.



> --

> Jean Delvare

> http://khali.linux-fr.org/wishlist.html



Thanks very much for your help, I was able to load the it87 driver with  
0x8720 and now running "sensors" gives data that at first glance makes  
sense.

Nick

[-- Attachment #1.2: Type: text/html, Size: 2463 bytes --]

[-- Attachment #2: 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] Sandy Bridge support?

[Jean Delvare]

On Tue, 18 Jan 2011 17:32:46 +0100, Jean Delvare wrote:
> On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:
> > And regarding the sensors-detect script, I understand now. If anyone is
> > interested, my Sandy Bridge processor would be model "0x2A" according to how
> > that script does things.
> 
> This is an option, yes, but it would be better if we could implement
> the same detection logic as the coretemp driver has. For one thing, this
> would guarantee that the two are always in sync. For another, it would
> lower the maintenance effort from our side, as the new detection logic
> is universal and doesn't need to be updated with every new CPU model.
> I'm looking into it but this is non-trivial.

I have come up with the following patch:

Index: prog/detect/sensors-detect
=================================--- prog/detect/sensors-detect	(révision 5904)
+++ prog/detect/sensors-detect	(copie de travail)
@@ -23,7 +23,7 @@
 require 5.004;
 
 use strict;
-use Fcntl;
+use Fcntl qw(:DEFAULT :seek);
 use File::Basename;
 
 # We will call modprobe, which typically lives in either /sbin,
@@ -2046,14 +2046,10 @@
 		driver => "k10temp",
 		detect => \&fam11h_pci_detect,
 	}, {
-		name => "Intel Core family thermal sensor",
+		name => "Intel digital thermal sensor",
 		driver => "coretemp",
-		detect => sub { coretemp_detect(0); },
+		detect => \&coretemp_detect,
 	}, {
-		name => "Intel Atom thermal sensor",
-		driver => "coretemp",
-		detect => sub { coretemp_detect(1); },
-	}, {
 		name => "Intel AMB FB-DIMM thermal sensor",
 		driver => "i5k_amb",
 		detect => \&intel_amb_detect,
@@ -2314,10 +2310,10 @@
 	while (<INPUTFILE>) {
 		if (m/^processor\s*:\s*(\d+)/) {
 			push @cpu, $entry if scalar keys(%{$entry}); # Previous entry
-			$entry = {}; # New entry
+			$entry = { nr => $1 }; # New entry
 			next;
 		}
-		if (m/^(vendor_id|cpu family|model|model name|stepping)\s*:\s*(.+)$/) {
+		if (m/^(vendor_id|cpu family|model|model name|stepping|cpuid level)\s*:\s*(.+)$/) {
 			my $k = $1;
 			my $v = $2;
 			$v =~ s/\s+/ /g;	# Merge multiple spaces
@@ -2486,6 +2482,15 @@
 	$modules_list{$normalized} = 1;
 }
 
+# udev may take some time to create device nodes when loading modules
+sub udev_settle
+{
+	if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") = 0)
+	 && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") = 0)) {
+		sleep(1);
+	}
+}
+
 sub initialize_modules_supported
 {
 	foreach my $chip (@chip_ids) {
@@ -5833,23 +5838,33 @@
 	return;
 }
 
+sub cpuid
+{
+	my ($cpu_nr, $eax) = @_;
+
+	sysopen(CPUID, "/dev/cpu/$cpu_nr/cpuid", O_RDONLY) or return;
+	binmode CPUID;
+	sysseek(CPUID, $eax, SEEK_SET)
+		or die "Cannot seek /dev/cpu/$cpu_nr/cpuid";
+	sysread(CPUID, my $data, 16)
+		or die "Cannot read /dev/cpu/$cpu_nr/cpuid";
+	close CPUID;
+
+	return unpack("L4", $data);
+}
+
 sub coretemp_detect
 {
-	my $chip = shift;
 	my $probecpu;
 
 	foreach $probecpu (@cpu) {
 		next unless $probecpu->{vendor_id} eq 'GenuineIntel' &&
-			    $probecpu->{'cpu family'} = 6;
-		return 9 if $chip = 0 &&
-			($probecpu->{model} = 14 ||	# Pentium M DC
-			 $probecpu->{model} = 15 ||	# Core 2 DC 65nm
-			 $probecpu->{model} = 0x16 ||	# Core 2 SC 65nm
-			 $probecpu->{model} = 0x17 ||	# Penryn 45nm
-			 $probecpu->{model} = 0x1a ||	# Nehalem
-			 $probecpu->{model} = 0x1e);	# Lynnfield
-		return 9 if $chip = 1 &&
-			($probecpu->{model} = 0x1c);	# Atom
+			    $probecpu->{'cpuid level'} >= 6;
+
+		# Now we check for the DTS flag
+		my @regs = cpuid($probecpu->{nr}, 0x06);
+		return unless @regs = 4;
+		return 9 if ($regs[0] & (1 << 0));	# eax, bit 0
 	}
 	return;
 }
@@ -6203,6 +6218,12 @@
 	print "Some south bridges, CPUs or memory controllers contain embedded sensors.\n".
 	      "Do you want to scan for them? This is totally safe. (YES/no): ";
 	unless (<STDIN> =~ /^\s*n/i) {
+		# Load the cpuid driver if needed
+		if (@cpu >= 1 && ! -e "/dev/cpu/$cpu[0]->{nr}/cpuid") {
+			load_module("cpuid");
+			udev_settle();
+		}
+
 		$| = 1;
 		foreach my $entry (@cpu_ids) {
 			scan_cpu($entry);
@@ -6278,12 +6299,7 @@
 		$by_default = 1 if dmi_match('board_vendor', 'asustek', 'tyan',
 					     'supermicro');
 
-		# udev may take some time to create the device node
-		if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") = 0)
-		 && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") = 0)) {
-			sleep(1);
-		}
-
+		udev_settle();
 		for (my $dev_nr = 0; $dev_nr < @i2c_adapters; $dev_nr++) {
 			next unless exists $i2c_adapters[$dev_nr];
 			scan_i2c_adapter($dev_nr, $by_default);

This seems to do the trick for me. Obviously it assumes that the cpuid
kernel driver is available. All my systems have it available as a
module, but I don't know if we can reasonably assume that it will be
available on all x86 systems where sensors-detect is used.

I would like this change to get as wide a test coverage as possible.
To make testing easier, I've made the full script available for
download at:
  http://khali.linux-fr.org/devel/misc/sensors-detect
(It's exactly equivalent to sensors-detect SVN + the patch above.) In
particular, this needs testing on Intel CPUs with cpuid level >= 6 but
without DTS support... if such systems exist (I don't have any here,
for sure.)

If this appears to work for everyone and nobody comes up with a major
objection, then we have our fix.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Sandy Bridge support?

[Guenter Roeck]

On Tue, Jan 18, 2011 at 05:35:13PM -0500, Jean Delvare wrote:
> On Tue, 18 Jan 2011 17:32:46 +0100, Jean Delvare wrote:
> > On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:
> > > And regarding the sensors-detect script, I understand now. If anyone is
> > > interested, my Sandy Bridge processor would be model "0x2A" according to how
> > > that script does things.
> > 
> > This is an option, yes, but it would be better if we could implement
> > the same detection logic as the coretemp driver has. For one thing, this
> > would guarantee that the two are always in sync. For another, it would
> > lower the maintenance effort from our side, as the new detection logic
> > is universal and doesn't need to be updated with every new CPU model.
> > I'm looking into it but this is non-trivial.
> 
> I have come up with the following patch:
> 
> Index: prog/detect/sensors-detect
> =================================> --- prog/detect/sensors-detect	(révision 5904)
> +++ prog/detect/sensors-detect	(copie de travail)
> @@ -23,7 +23,7 @@
>  require 5.004;
>  
>  use strict;
> -use Fcntl;
> +use Fcntl qw(:DEFAULT :seek);
>  use File::Basename;
>  
>  # We will call modprobe, which typically lives in either /sbin,
> @@ -2046,14 +2046,10 @@
>  		driver => "k10temp",
>  		detect => \&fam11h_pci_detect,
>  	}, {
> -		name => "Intel Core family thermal sensor",
> +		name => "Intel digital thermal sensor",
>  		driver => "coretemp",
> -		detect => sub { coretemp_detect(0); },
> +		detect => \&coretemp_detect,
>  	}, {
> -		name => "Intel Atom thermal sensor",
> -		driver => "coretemp",
> -		detect => sub { coretemp_detect(1); },
> -	}, {
>  		name => "Intel AMB FB-DIMM thermal sensor",
>  		driver => "i5k_amb",
>  		detect => \&intel_amb_detect,
> @@ -2314,10 +2310,10 @@
>  	while (<INPUTFILE>) {
>  		if (m/^processor\s*:\s*(\d+)/) {
>  			push @cpu, $entry if scalar keys(%{$entry}); # Previous entry
> -			$entry = {}; # New entry
> +			$entry = { nr => $1 }; # New entry
>  			next;
>  		}
> -		if (m/^(vendor_id|cpu family|model|model name|stepping)\s*:\s*(.+)$/) {
> +		if (m/^(vendor_id|cpu family|model|model name|stepping|cpuid level)\s*:\s*(.+)$/) {
>  			my $k = $1;
>  			my $v = $2;
>  			$v =~ s/\s+/ /g;	# Merge multiple spaces
> @@ -2486,6 +2482,15 @@
>  	$modules_list{$normalized} = 1;
>  }
>  
> +# udev may take some time to create device nodes when loading modules
> +sub udev_settle
> +{
> +	if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") = 0)
> +	 && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") = 0)) {
> +		sleep(1);
> +	}
> +}
> +
>  sub initialize_modules_supported
>  {
>  	foreach my $chip (@chip_ids) {
> @@ -5833,23 +5838,33 @@
>  	return;
>  }
>  
> +sub cpuid
> +{
> +	my ($cpu_nr, $eax) = @_;
> +
> +	sysopen(CPUID, "/dev/cpu/$cpu_nr/cpuid", O_RDONLY) or return;
> +	binmode CPUID;
> +	sysseek(CPUID, $eax, SEEK_SET)
> +		or die "Cannot seek /dev/cpu/$cpu_nr/cpuid";
> +	sysread(CPUID, my $data, 16)
> +		or die "Cannot read /dev/cpu/$cpu_nr/cpuid";
> +	close CPUID;
> +
> +	return unpack("L4", $data);
> +}
> +
>  sub coretemp_detect
>  {
> -	my $chip = shift;
>  	my $probecpu;
>  
>  	foreach $probecpu (@cpu) {
>  		next unless $probecpu->{vendor_id} eq 'GenuineIntel' &&
> -			    $probecpu->{'cpu family'} = 6;
> -		return 9 if $chip = 0 &&
> -			($probecpu->{model} = 14 ||	# Pentium M DC
> -			 $probecpu->{model} = 15 ||	# Core 2 DC 65nm
> -			 $probecpu->{model} = 0x16 ||	# Core 2 SC 65nm
> -			 $probecpu->{model} = 0x17 ||	# Penryn 45nm
> -			 $probecpu->{model} = 0x1a ||	# Nehalem
> -			 $probecpu->{model} = 0x1e);	# Lynnfield
> -		return 9 if $chip = 1 &&
> -			($probecpu->{model} = 0x1c);	# Atom
> +			    $probecpu->{'cpuid level'} >= 6;
> +
> +		# Now we check for the DTS flag
> +		my @regs = cpuid($probecpu->{nr}, 0x06);
> +		return unless @regs = 4;
> +		return 9 if ($regs[0] & (1 << 0));	# eax, bit 0
>  	}
>  	return;
>  }
> @@ -6203,6 +6218,12 @@
>  	print "Some south bridges, CPUs or memory controllers contain embedded sensors.\n".
>  	      "Do you want to scan for them? This is totally safe. (YES/no): ";
>  	unless (<STDIN> =~ /^\s*n/i) {
> +		# Load the cpuid driver if needed
> +		if (@cpu >= 1 && ! -e "/dev/cpu/$cpu[0]->{nr}/cpuid") {
> +			load_module("cpuid");
> +			udev_settle();
> +		}
> +
>  		$| = 1;
>  		foreach my $entry (@cpu_ids) {
>  			scan_cpu($entry);
> @@ -6278,12 +6299,7 @@
>  		$by_default = 1 if dmi_match('board_vendor', 'asustek', 'tyan',
>  					     'supermicro');
>  
> -		# udev may take some time to create the device node
> -		if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") = 0)
> -		 && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") = 0)) {
> -			sleep(1);
> -		}
> -
> +		udev_settle();
>  		for (my $dev_nr = 0; $dev_nr < @i2c_adapters; $dev_nr++) {
>  			next unless exists $i2c_adapters[$dev_nr];
>  			scan_i2c_adapter($dev_nr, $by_default);
> 
> This seems to do the trick for me. Obviously it assumes that the cpuid
> kernel driver is available. All my systems have it available as a
> module, but I don't know if we can reasonably assume that it will be
> available on all x86 systems where sensors-detect is used.
> 
> I would like this change to get as wide a test coverage as possible.
> To make testing easier, I've made the full script available for
> download at:
>   http://khali.linux-fr.org/devel/misc/sensors-detect
> (It's exactly equivalent to sensors-detect SVN + the patch above.) In
> particular, this needs testing on Intel CPUs with cpuid level >= 6 but
> without DTS support... if such systems exist (I don't have any here,
> for sure.)
> 
> If this appears to work for everyone and nobody comes up with a major
> objection, then we have our fix.
> 
Works for me as expected on three systems. One has AMD CPUs and doesn't detect
anything, the other two report as expected that CPU sensors exist. 

CPUs:	Intel(R) Core(TM)2 Duo CPU     T9300  @ 2.50GHz
	Intel(R) Xeon(R) CPU           C5528  @ 2.13GHz

Kernel versions 2.6.32-26 (Ubuntu) and 2.6.35.10 (generic)

Guenter


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

Re: [lm-sensors] Sandy Bridge support?

[DarkNovaNick]

[-- Attachment #1.1: Type: text/plain, Size: 6106 bytes --]

On Jan 18, 2011 4:35pm, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 18 Jan 2011 17:32:46 +0100, Jean Delvare wrote:

> > On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:

> > > And regarding the sensors-detect script, I understand now. If anyone  
> is

> > > interested, my Sandy Bridge processor would be model "0x2A" according  
> to how

> > > that script does things.

> >

> > This is an option, yes, but it would be better if we could implement

> > the same detection logic as the coretemp driver has. For one thing, this

> > would guarantee that the two are always in sync. For another, it would

> > lower the maintenance effort from our side, as the new detection logic

> > is universal and doesn't need to be updated with every new CPU model.

> > I'm looking into it but this is non-trivial.



> I have come up with the following patch:



> Index: prog/detect/sensors-detect

> ===================================================================

> --- prog/detect/sensors-detect (révision 5904)

> +++ prog/detect/sensors-detect (copie de travail)

> @@ -23,7 +23,7 @@

> require 5.004;



> use strict;

> -use Fcntl;

> +use Fcntl qw(:DEFAULT :seek);

> use File::Basename;



> # We will call modprobe, which typically lives in either /sbin,

> @@ -2046,14 +2046,10 @@

> driver => "k10temp",

> detect => \&fam11h_pci_detect,

> }, {

> - name => "Intel Core family thermal sensor",

> + name => "Intel digital thermal sensor",

> driver => "coretemp",

> - detect => sub { coretemp_detect(0); },

> + detect => \&coretemp_detect,

> }, {

> - name => "Intel Atom thermal sensor",

> - driver => "coretemp",

> - detect => sub { coretemp_detect(1); },

> - }, {

> name => "Intel AMB FB-DIMM thermal sensor",

> driver => "i5k_amb",

> detect => \&intel_amb_detect,

> @@ -2314,10 +2310,10 @@

> while () {

> if (m/^processor\s*:\s*(\d+)/) {

> push @cpu, $entry if scalar keys(%{$entry}); # Previous entry

> - $entry = {}; # New entry

> + $entry = { nr => $1 }; # New entry

> next;

> }

> - if (m/^(vendor_id|cpu family|model|model name|stepping)\s*:\s*(.+)$/) {

> + if (m/^(vendor_id|cpu family|model|model name|stepping|cpuid  
> level)\s*:\s*(.+)$/) {

> my $k = $1;

> my $v = $2;

> $v =~ s/\s+/ /g; # Merge multiple spaces

> @@ -2486,6 +2482,15 @@

> $modules_list{$normalized} = 1;

> }



> +# udev may take some time to create device nodes when loading modules

> +sub udev_settle

> +{

> + if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") == 0)

> + && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") == 0)) {

> + sleep(1);

> + }

> +}

> +

> sub initialize_modules_supported

> {

> foreach my $chip (@chip_ids) {

> @@ -5833,23 +5838,33 @@

> return;

> }



> +sub cpuid

> +{

> + my ($cpu_nr, $eax) = @_;

> +

> + sysopen(CPUID, "/dev/cpu/$cpu_nr/cpuid", O_RDONLY) or return;

> + binmode CPUID;

> + sysseek(CPUID, $eax, SEEK_SET)

> + or die "Cannot seek /dev/cpu/$cpu_nr/cpuid";

> + sysread(CPUID, my $data, 16)

> + or die "Cannot read /dev/cpu/$cpu_nr/cpuid";

> + close CPUID;

> +

> + return unpack("L4", $data);

> +}

> +

> sub coretemp_detect

> {

> - my $chip = shift;

> my $probecpu;



> foreach $probecpu (@cpu) {

> next unless $probecpu->{vendor_id} eq 'GenuineIntel' &&

> - $probecpu->{'cpu family'} == 6;

> - return 9 if $chip == 0 &&

> - ($probecpu->{model} == 14 || # Pentium M DC

> - $probecpu->{model} == 15 || # Core 2 DC 65nm

> - $probecpu->{model} == 0x16 || # Core 2 SC 65nm

> - $probecpu->{model} == 0x17 || # Penryn 45nm

> - $probecpu->{model} == 0x1a || # Nehalem

> - $probecpu->{model} == 0x1e); # Lynnfield

> - return 9 if $chip == 1 &&

> - ($probecpu->{model} == 0x1c); # Atom

> + $probecpu->{'cpuid level'} >= 6;

> +

> + # Now we check for the DTS flag

> + my @regs = cpuid($probecpu->{nr}, 0x06);

> + return unless @regs == 4;

> + return 9 if ($regs[0] & (1
> }

> return;

> }

> @@ -6203,6 +6218,12 @@

> print "Some south bridges, CPUs or memory controllers contain embedded  
> sensors.\n".

> "Do you want to scan for them? This is totally safe. (YES/no): ";

> unless ( =~ /^\s*n/i) {

> + # Load the cpuid driver if needed

> + if (@cpu >= 1 && ! -e "/dev/cpu/$cpu[0]->{nr}/cpuid") {

> + load_module("cpuid");

> + udev_settle();

> + }

> +

> $| = 1;

> foreach my $entry (@cpu_ids) {

> scan_cpu($entry);

> @@ -6278,12 +6299,7 @@

> $by_default = 1 if dmi_match('board_vendor', 'asustek', 'tyan',

> 'supermicro');



> - # udev may take some time to create the device node

> - if (!(-x "/sbin/udevadm" && system("/sbin/udevadm settle") == 0)

> - && !(-x "/sbin/udevsettle" && system("/sbin/udevsettle") == 0)) {

> - sleep(1);

> - }

> -

> + udev_settle();

> for (my $dev_nr = 0; $dev_nr
> next unless exists $i2c_adapters[$dev_nr];

> scan_i2c_adapter($dev_nr, $by_default);



> This seems to do the trick for me. Obviously it assumes that the cpuid

> kernel driver is available. All my systems have it available as a

> module, but I don't know if we can reasonably assume that it will be

> available on all x86 systems where sensors-detect is used.



> I would like this change to get as wide a test coverage as possible.

> To make testing easier, I've made the full script available for

> download at:

> http://khali.linux-fr.org/devel/misc/sensors-detect

> (It's exactly equivalent to sensors-detect SVN + the patch above.) In

> particular, this needs testing on Intel CPUs with cpuid level >= 6 but

> without DTS support... if such systems exist (I don't have any here,

> for sure.)



> If this appears to work for everyone and nobody comes up with a major

> objection, then we have our fix.



> Thanks,

> --

> Jean Delvare



Worked for me on my Intel i5-2500k (Sandy Bridge). Thanks!

Nick

[-- Attachment #1.2: Type: text/html, Size: 10605 bytes --]

[-- Attachment #2: 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] Sandy Bridge support?

[Jeff Rickman]

On 1/18/2011 4:35 PM, Jean Delvare wrote:
> On Tue, 18 Jan 2011 17:32:46 +0100, Jean Delvare wrote:
>> On Tue, 18 Jan 2011 10:03:23 -0600, Nick Hall wrote:
>>> And regarding the sensors-detect script, I understand now. If anyone is
>>> interested, my Sandy Bridge processor would be model "0x2A" according to how
>>> that script does things.
>>
>> This is an option, yes, but it would be better if we could implement
>> the same detection logic as the coretemp driver has. For one thing, this
>> would guarantee that the two are always in sync. For another, it would
>> lower the maintenance effort from our side, as the new detection logic
>> is universal and doesn't need to be updated with every new CPU model.
>> I'm looking into it but this is non-trivial.
>
> I have come up with the following patch:
>
> Index: prog/detect/sensors-detect
> =================================> --- prog/detect/sensors-detect	(révision 5904)
> +++ prog/detect/sensors-detect	(copie de travail)
> @@ -23,7 +23,7 @@
>   require 5.004;
>
>   use strict;
> -use Fcntl;
> +use Fcntl qw(:DEFAULT :seek);
>   use File::Basename;
>
>   # We will call modprobe, which typically lives in either /sbin,
> @@ -2046,14 +2046,10 @@
>   		driver =>  "k10temp",
>   		detect =>  \&fam11h_pci_detect,
>   	}, {
> -		name =>  "Intel Core family thermal sensor",
> +		name =>  "Intel digital thermal sensor",
>   		driver =>  "coretemp",
> -		detect =>  sub { coretemp_detect(0); },
> +		detect =>  \&coretemp_detect,
>   	}, {
> -		name =>  "Intel Atom thermal sensor",
> -		driver =>  "coretemp",
> -		detect =>  sub { coretemp_detect(1); },
> -	}, {
>   		name =>  "Intel AMB FB-DIMM thermal sensor",
>   		driver =>  "i5k_amb",
>   		detect =>  \&intel_amb_detect,
> @@ -2314,10 +2310,10 @@
>   	while (<INPUTFILE>) {
>   		if (m/^processor\s*:\s*(\d+)/) {
>   			push @cpu, $entry if scalar keys(%{$entry}); # Previous entry
> -			$entry = {}; # New entry
> +			$entry = { nr =>  $1 }; # New entry
>   			next;
>   		}
> -		if (m/^(vendor_id|cpu family|model|model name|stepping)\s*:\s*(.+)$/) {
> +		if (m/^(vendor_id|cpu family|model|model name|stepping|cpuid level)\s*:\s*(.+)$/) {
>   			my $k = $1;
>   			my $v = $2;
>   			$v =~ s/\s+/ /g;	# Merge multiple spaces
> @@ -2486,6 +2482,15 @@
>   	$modules_list{$normalized} = 1;
>   }
>
> +# udev may take some time to create device nodes when loading modules
> +sub udev_settle
> +{
> +	if (!(-x "/sbin/udevadm"&&  system("/sbin/udevadm settle") = 0)
> +	&&  !(-x "/sbin/udevsettle"&&  system("/sbin/udevsettle") = 0)) {
> +		sleep(1);
> +	}
> +}
> +
>   sub initialize_modules_supported
>   {
>   	foreach my $chip (@chip_ids) {
> @@ -5833,23 +5838,33 @@
>   	return;
>   }
>
> +sub cpuid
> +{
> +	my ($cpu_nr, $eax) = @_;
> +
> +	sysopen(CPUID, "/dev/cpu/$cpu_nr/cpuid", O_RDONLY) or return;
> +	binmode CPUID;
> +	sysseek(CPUID, $eax, SEEK_SET)
> +		or die "Cannot seek /dev/cpu/$cpu_nr/cpuid";
> +	sysread(CPUID, my $data, 16)
> +		or die "Cannot read /dev/cpu/$cpu_nr/cpuid";
> +	close CPUID;
> +
> +	return unpack("L4", $data);
> +}
> +
>   sub coretemp_detect
>   {
> -	my $chip = shift;
>   	my $probecpu;
>
>   	foreach $probecpu (@cpu) {
>   		next unless $probecpu->{vendor_id} eq 'GenuineIntel'&&
> -			    $probecpu->{'cpu family'} = 6;
> -		return 9 if $chip = 0&&
> -			($probecpu->{model} = 14 ||	# Pentium M DC
> -			 $probecpu->{model} = 15 ||	# Core 2 DC 65nm
> -			 $probecpu->{model} = 0x16 ||	# Core 2 SC 65nm
> -			 $probecpu->{model} = 0x17 ||	# Penryn 45nm
> -			 $probecpu->{model} = 0x1a ||	# Nehalem
> -			 $probecpu->{model} = 0x1e);	# Lynnfield
> -		return 9 if $chip = 1&&
> -			($probecpu->{model} = 0x1c);	# Atom
> +			    $probecpu->{'cpuid level'}>= 6;
> +
> +		# Now we check for the DTS flag
> +		my @regs = cpuid($probecpu->{nr}, 0x06);
> +		return unless @regs = 4;
> +		return 9 if ($regs[0]&  (1<<  0));	# eax, bit 0
>   	}
>   	return;
>   }
> @@ -6203,6 +6218,12 @@
>   	print "Some south bridges, CPUs or memory controllers contain embedded sensors.\n".
>   	      "Do you want to scan for them? This is totally safe. (YES/no): ";
>   	unless (<STDIN>  =~ /^\s*n/i) {
> +		# Load the cpuid driver if needed
> +		if (@cpu>= 1&&  ! -e "/dev/cpu/$cpu[0]->{nr}/cpuid") {
> +			load_module("cpuid");
> +			udev_settle();
> +		}
> +
>   		$| = 1;
>   		foreach my $entry (@cpu_ids) {
>   			scan_cpu($entry);
> @@ -6278,12 +6299,7 @@
>   		$by_default = 1 if dmi_match('board_vendor', 'asustek', 'tyan',
>   					     'supermicro');
>
> -		# udev may take some time to create the device node
> -		if (!(-x "/sbin/udevadm"&&  system("/sbin/udevadm settle") = 0)
> -		&&  !(-x "/sbin/udevsettle"&&  system("/sbin/udevsettle") = 0)) {
> -			sleep(1);
> -		}
> -
> +		udev_settle();
>   		for (my $dev_nr = 0; $dev_nr<  @i2c_adapters; $dev_nr++) {
>   			next unless exists $i2c_adapters[$dev_nr];
>   			scan_i2c_adapter($dev_nr, $by_default);
>
> This seems to do the trick for me. Obviously it assumes that the cpuid
> kernel driver is available. All my systems have it available as a
> module, but I don't know if we can reasonably assume that it will be
> available on all x86 systems where sensors-detect is used.
>
> I would like this change to get as wide a test coverage as possible.
> To make testing easier, I've made the full script available for
> download at:
>    http://khali.linux-fr.org/devel/misc/sensors-detect
> (It's exactly equivalent to sensors-detect SVN + the patch above.) In
> particular, this needs testing on Intel CPUs with cpuid level>= 6 but
> without DTS support... if such systems exist (I don't have any here,
> for sure.)
>
> If this appears to work for everyone and nobody comes up with a major
> objection, then we have our fix.
>
> Thanks,

Tested on Intel Atom 230, Intel Atom 330, Intel Atom 510. CPU sensors 
correctly detected in all 3 tests.

Tested on AMD Athlon 64 X2 5400+. AMD K8 sensors were correctly 
detected. As expected, no Intel sensors were detected.

Tested on VIA C7-D CPU 1500MHz. VIA C7 CPU sensors were detected. As 
expected, no Intel sensors were detected.

Fedora Core 14 i386 or x86_64 used. Kernel 2.6.35.10-74 in all cases.


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

Re: [lm-sensors] Sandy Bridge support?

[Jean Delvare]

On Wed, 19 Jan 2011 03:22:14 +0000, DarkNovaNick@gmail.com wrote:
> Worked for me on my Intel i5-2500k (Sandy Bridge). Thanks!

Thanks Guenter and Nick for testing and reporting. I've committed the
fix.

-- 
Jean Delvare

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

Re: [lm-sensors] Sandy Bridge support?

[Jean Delvare]

Hi Nick,

On Tue, 18 Jan 2011 16:47:44 +0000, DarkNovaNick@gmail.com wrote:
> On Jan 18, 2011 10:32am, Jean Delvare <khali@linux-fr.org> wrote:
> > OK, thanks. If you feel lucky, you may try to load the it87 driver with
> > parameter force_id, to force the driver to consider your chip as one it
> > supports. Given the name of your device, the first values to try would
> > be 0x8721 and 0x8720 (the two most recent chips) or 0x8718 (in case the
> > IT8728F is an evolution of the IT8718F - I remember the IT8716F and
> > IT8726F were compatible.) If you give this a try, please let us know
> > the results.
> 
> Thanks very much for your help, I was able to load the it87 driver with  
> 0x8720 and now running "sensors" gives data that at first glance makes  
> sense.

It turns our that the I8728F is rather compatible with the IT8721F.
Proper support was just added, you can use the standalone it87 driver
if you want:
  http://khali.linux-fr.org/devel/misc/it87/

-- 
Jean Delvare

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