* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
@ 2011-01-17 21:54 ` Guenter Roeck
2011-01-17 22:26 ` Anish Patel
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Guenter Roeck @ 2011-01-17 21:54 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
2011-01-17 21:54 ` Guenter Roeck
@ 2011-01-17 22:26 ` Anish Patel
2011-01-17 22:53 ` Guenter Roeck
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Anish Patel @ 2011-01-17 22:26 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
2011-01-17 21:54 ` Guenter Roeck
2011-01-17 22:26 ` Anish Patel
@ 2011-01-17 22:53 ` Guenter Roeck
2011-01-17 23:26 ` DarkNovaNick
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Guenter Roeck @ 2011-01-17 22:53 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (2 preceding siblings ...)
2011-01-17 22:53 ` Guenter Roeck
@ 2011-01-17 23:26 ` DarkNovaNick
2011-01-18 8:46 ` Jean Delvare
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: DarkNovaNick @ 2011-01-17 23:26 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (3 preceding siblings ...)
2011-01-17 23:26 ` DarkNovaNick
@ 2011-01-18 8:46 ` Jean Delvare
2011-01-18 12:59 ` Jean Delvare
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-01-18 8:46 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (4 preceding siblings ...)
2011-01-18 8:46 ` Jean Delvare
@ 2011-01-18 12:59 ` Jean Delvare
2011-01-18 16:03 ` Nick Hall
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-01-18 12:59 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (5 preceding siblings ...)
2011-01-18 12:59 ` Jean Delvare
@ 2011-01-18 16:03 ` Nick Hall
2011-01-18 16:32 ` Jean Delvare
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Nick Hall @ 2011-01-18 16:03 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (6 preceding siblings ...)
2011-01-18 16:03 ` Nick Hall
@ 2011-01-18 16:32 ` Jean Delvare
2011-01-18 16:47 ` DarkNovaNick
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-01-18 16:32 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (7 preceding siblings ...)
2011-01-18 16:32 ` Jean Delvare
@ 2011-01-18 16:47 ` DarkNovaNick
2011-01-18 22:35 ` Jean Delvare
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: DarkNovaNick @ 2011-01-18 16:47 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (8 preceding siblings ...)
2011-01-18 16:47 ` DarkNovaNick
@ 2011-01-18 22:35 ` Jean Delvare
2011-01-18 23:24 ` Guenter Roeck
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-01-18 22:35 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (9 preceding siblings ...)
2011-01-18 22:35 ` Jean Delvare
@ 2011-01-18 23:24 ` Guenter Roeck
2011-01-19 3:22 ` DarkNovaNick
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: Guenter Roeck @ 2011-01-18 23:24 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (10 preceding siblings ...)
2011-01-18 23:24 ` Guenter Roeck
@ 2011-01-19 3:22 ` DarkNovaNick
2011-01-19 5:50 ` Jeff Rickman
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: DarkNovaNick @ 2011-01-19 3:22 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (11 preceding siblings ...)
2011-01-19 3:22 ` DarkNovaNick
@ 2011-01-19 5:50 ` Jeff Rickman
2011-01-19 10:01 ` Jean Delvare
2011-11-22 10:14 ` Jean Delvare
14 siblings, 0 replies; 16+ messages in thread
From: Jeff Rickman @ 2011-01-19 5:50 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (12 preceding siblings ...)
2011-01-19 5:50 ` Jeff Rickman
@ 2011-01-19 10:01 ` Jean Delvare
2011-11-22 10:14 ` Jean Delvare
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-01-19 10:01 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [lm-sensors] Sandy Bridge support?
2011-01-17 20:26 [lm-sensors] Sandy Bridge support? DarkNovaNick
` (13 preceding siblings ...)
2011-01-19 10:01 ` Jean Delvare
@ 2011-11-22 10:14 ` Jean Delvare
14 siblings, 0 replies; 16+ messages in thread
From: Jean Delvare @ 2011-11-22 10:14 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 16+ messages in thread
