[lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Alexander Stein]

Hello,

I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
(TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
degrees C and 110 degrees C. But these different model can't be detected by 
reading from hardware.
IMO there should be some support to adjust the temperature from userspace. 
Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
useable. But I think it is somewhat misleading (especially on multicores), 
because there must only be one offset.
What do you think about this?

Regards,
Alexander

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

coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Alexander Stein]

Hello,

I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
(TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
degrees C and 110 degrees C. But these different model can't be detected by 
reading from hardware.
IMO there should be some support to adjust the temperature from userspace. 
Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
useable. But I think it is somewhat misleading (especially on multicores), 
because there must only be one offset.
What do you think about this?

Regards,
Alexander

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Guenter Roeck]

On Mon, Jun 27, 2011 at 06:20:51AM -0400, Alexander Stein wrote:
> Hello,
> 
> I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> degrees C and 110 degrees C. But these different model can't be detected by 
> reading from hardware.
> IMO there should be some support to adjust the temperature from userspace. 
> Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
> useable. But I think it is somewhat misleading (especially on multicores), 
> because there must only be one offset.
> What do you think about this?
> 
You can adjust the reported temperature with an entry in sensors3.conf.

Guenter

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

Re: coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Guenter Roeck]

On Mon, Jun 27, 2011 at 06:20:51AM -0400, Alexander Stein wrote:
> Hello,
> 
> I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> degrees C and 110 degrees C. But these different model can't be detected by 
> reading from hardware.
> IMO there should be some support to adjust the temperature from userspace. 
> Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
> useable. But I think it is somewhat misleading (especially on multicores), 
> because there must only be one offset.
> What do you think about this?
> 
You can adjust the reported temperature with an entry in sensors3.conf.

Guenter

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Jean Delvare]

Hi Alexander,

On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.

You have a patch, great for you. What do you expect if you don't share
it with us?

I'm not quite sure what your patch would be doing anyway. Since kernel
2.6.35, supported CPU models are detected using the DTS feature flag
rather than the family and model numbers, so your Atom E6XX should be
detected just fine.

Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
TjMax guessing, which was fixed by Gunter Roeck with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hO5f71a7abe329bdad81ee6a8e4545054a7cc30a
You'll have to update to kernel version 2.6.39.2 to get this fix.

Do you happen to know what CPUs model number 0x26 covers? Do you know
if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
Atom (model 0x1c) did not.

> But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> degrees C and 110 degrees C. But these different model can't be detected by 
> reading from hardware.

I would appreciate a patch to Documentation/hwmon/coretemp adding the
known TjMax for these new Atom models.

BTW, is it really impossible to identify these models with a different
TjMax? Don't the strings "E660" and "E660T" appear in the respective
"model name" entries in /proc/cpuinfo?

> IMO there should be some support to adjust the temperature from userspace. 
> Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
> useable. But I think it is somewhat misleading (especially on multicores), 
> because there must only be one offset.

No, tempN_offset isn't suitable for this case, as it would only shift the
current temperature and not the limits.

Instead, we could detect the specific CPUs using the model name string
and adjust TjMax accordingly. And/or we could let the user override
TjMax through a module parameter (I doubt anyone runs a system with
CPUs with different TjMax values.)

-- 
Jean Delvare

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

Re: coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Jean Delvare]

Hi Alexander,

On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.

You have a patch, great for you. What do you expect if you don't share
it with us?

I'm not quite sure what your patch would be doing anyway. Since kernel
2.6.35, supported CPU models are detected using the DTS feature flag
rather than the family and model numbers, so your Atom E6XX should be
detected just fine.

Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
TjMax guessing, which was fixed by Gunter Roeck with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4f5f71a7abe329bdad81ee6a8e4545054a7cc30a
You'll have to update to kernel version 2.6.39.2 to get this fix.

Do you happen to know what CPUs model number 0x26 covers? Do you know
if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
Atom (model 0x1c) did not.

> But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> degrees C and 110 degrees C. But these different model can't be detected by 
> reading from hardware.

I would appreciate a patch to Documentation/hwmon/coretemp adding the
known TjMax for these new Atom models.

BTW, is it really impossible to identify these models with a different
TjMax? Don't the strings "E660" and "E660T" appear in the respective
"model name" entries in /proc/cpuinfo?

> IMO there should be some support to adjust the temperature from userspace. 
> Reading Documentation/hwmon/sysfs-interface only temp1_offset seems to be 
> useable. But I think it is somewhat misleading (especially on multicores), 
> because there must only be one offset.

No, tempN_offset isn't suitable for this case, as it would only shift the
current temperature and not the limits.

Instead, we could detect the specific CPUs using the model name string
and adjust TjMax accordingly. And/or we could let the user override
TjMax through a module parameter (I doubt anyone runs a system with
CPUs with different TjMax values.)

-- 
Jean Delvare

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Alexander Stein]

On Monday 27 June 2011 16:41:08 Jean Delvare wrote:
> Hi Alexander,
> 
> On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> > I have a patch (for v2.6.39) which adds support for Intel Atom E6XX
> > (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> 
> You have a patch, great for you. What do you expect if you don't share
> it with us?

If you insist on seeing that patch (for 2.6.39 btw):

diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 25568f8..8fc82b6 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -6,7 +6,8 @@ Supported chips:
     Prefix: 'coretemp'
     CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
                               0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
-                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
+                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
+                              0x26 (Tunnelcreek)
     Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
                Volume 3A: System Programming Guide
                http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 194ca0a..55f0fda 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -173,9 +173,9 @@ static int __devinit adjust_tjmax(struct cpuinfo_x86 *c, 
u32 id, struct device *
 		usemsr_ee = 0;
 	}
 
-	/* Atom CPUs */
+	/* Atom and TunnelCreek CPUs */
 
-	if (c->x86_model = 0x1c) {
+	if ((c->x86_model = 0x1c) || (c->x86_model = 0x26)) {
 		usemsr_ee = 0;
 
 		host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
@@ -283,6 +283,7 @@ static int __devinit get_tjmax(struct cpuinfo_x86 *c, u32 
id,
 		return 100000;
 	case 0x17:
 	case 0x1c:		/* Atom CPUs */
+	case 0x26:		/* TunnelCreek CPU */
 		return adjust_tjmax(c, id, dev);
 	default:
 		dev_warn(dev, "CPU (model=0x%x) is not supported yet,"
@@ -361,7 +362,8 @@ static int __devinit coretemp_probe(struct platform_device 
*pdev)
 	 * Atoms don't have it either.
 	 */
 
-	if ((c->x86_model > 0xe) && (c->x86_model != 0x1c)) {
+	if ((c->x86_model > 0xe) && (c->x86_model != 0x1c)
+	&& (c->x86_model != 0x26)) {
 		err = rdmsr_safe_on_cpu(data->id, MSR_IA32_TEMPERATURE_TARGET,
 		    &eax, &edx);
 		if (err) {

The patch without hunk 2 still stays valid to me for current git master.

> I'm not quite sure what your patch would be doing anyway. Since kernel
> 2.6.35, supported CPU models are detected using the DTS feature flag
> rather than the family and model numbers, so your Atom E6XX should be
> detected just fine.

Those 3 output lines don't seem like the mode is detected.
coretemp coretemp.0: Unable to read TjMax from CPU.
coretemp coretemp.0: CPU (model=0x26) is not supported yet, using default 
TjMax of 100C.
coretemp coretemp.0: Unable to read IA32_TEMPERATURE_TARGET MSR

> Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
> TjMax guessing, which was fixed by Gunter Roeck with:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
> O5f71a7abe329bdad81ee6a8e4545054a7cc30a You'll have to update to kernel
> version 2.6.39.2 to get this fix.

Cherry-picking this patch, only reduces the output to those two lines:
coretemp coretemp.0: Unable to read TjMax from CPU.
coretemp coretemp.0: Unable to read IA32_TEMPERATURE_TARGET MSR

> Do you happen to know what CPUs model number 0x26 covers? Do you know
> if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
> Atom (model 0x1c) did not.

Both the linux kernel (see above) and the bootloader can't use 
MSR_IA32_TEMPERATURE_TARGET, so I guess this model does not support this 
feature.
I don't know which models have number 0x26, despite the E6xx.

> > But there are models (e.g. E660 and E660T) with different TjMax, namely
> > 90 degrees C and 110 degrees C. But these different model can't be
> > detected by reading from hardware.
> 
> I would appreciate a patch to Documentation/hwmon/coretemp adding the
> known TjMax for these new Atom models.
> 
> BTW, is it really impossible to identify these models with a different
> TjMax? Don't the strings "E660" and "E660T" appear in the respective
> "model name" entries in /proc/cpuinfo?

Here's the cpuinfo output. I didnt find anything which would allow this 
distinction.

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1299.936
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 
cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2599.87
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1299.936
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 
cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2599.54
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

> > IMO there should be some support to adjust the temperature from
> > userspace. Reading Documentation/hwmon/sysfs-interface only temp1_offset
> > seems to be useable. But I think it is somewhat misleading (especially
> > on multicores), because there must only be one offset.
> 
> No, tempN_offset isn't suitable for this case, as it would only shift the
> current temperature and not the limits.
> 
> Instead, we could detect the specific CPUs using the model name string
> and adjust TjMax accordingly. And/or we could let the user override
> TjMax through a module parameter (I doubt anyone runs a system with
> CPUs with different TjMax values.)

As there seem to be no model string to distinct, only the module parameter 
seems valid to do this change.

Regards,
Alexander

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

Re: coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Alexander Stein]

On Monday 27 June 2011 16:41:08 Jean Delvare wrote:
> Hi Alexander,
> 
> On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> > I have a patch (for v2.6.39) which adds support for Intel Atom E6XX
> > (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> 
> You have a patch, great for you. What do you expect if you don't share
> it with us?

If you insist on seeing that patch (for 2.6.39 btw):

diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 25568f8..8fc82b6 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -6,7 +6,8 @@ Supported chips:
     Prefix: 'coretemp'
     CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
                               0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
-                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
+                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
+                              0x26 (Tunnelcreek)
     Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
                Volume 3A: System Programming Guide
                http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 194ca0a..55f0fda 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -173,9 +173,9 @@ static int __devinit adjust_tjmax(struct cpuinfo_x86 *c, 
u32 id, struct device *
 		usemsr_ee = 0;
 	}
 
-	/* Atom CPUs */
+	/* Atom and TunnelCreek CPUs */
 
-	if (c->x86_model == 0x1c) {
+	if ((c->x86_model == 0x1c) || (c->x86_model == 0x26)) {
 		usemsr_ee = 0;
 
 		host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
@@ -283,6 +283,7 @@ static int __devinit get_tjmax(struct cpuinfo_x86 *c, u32 
id,
 		return 100000;
 	case 0x17:
 	case 0x1c:		/* Atom CPUs */
+	case 0x26:		/* TunnelCreek CPU */
 		return adjust_tjmax(c, id, dev);
 	default:
 		dev_warn(dev, "CPU (model=0x%x) is not supported yet,"
@@ -361,7 +362,8 @@ static int __devinit coretemp_probe(struct platform_device 
*pdev)
 	 * Atoms don't have it either.
 	 */
 
-	if ((c->x86_model > 0xe) && (c->x86_model != 0x1c)) {
+	if ((c->x86_model > 0xe) && (c->x86_model != 0x1c)
+	&& (c->x86_model != 0x26)) {
 		err = rdmsr_safe_on_cpu(data->id, MSR_IA32_TEMPERATURE_TARGET,
 		    &eax, &edx);
 		if (err) {

The patch without hunk 2 still stays valid to me for current git master.

> I'm not quite sure what your patch would be doing anyway. Since kernel
> 2.6.35, supported CPU models are detected using the DTS feature flag
> rather than the family and model numbers, so your Atom E6XX should be
> detected just fine.

Those 3 output lines don't seem like the mode is detected.
coretemp coretemp.0: Unable to read TjMax from CPU.
coretemp coretemp.0: CPU (model=0x26) is not supported yet, using default 
TjMax of 100C.
coretemp coretemp.0: Unable to read IA32_TEMPERATURE_TARGET MSR

> Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
> TjMax guessing, which was fixed by Gunter Roeck with:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
> =4f5f71a7abe329bdad81ee6a8e4545054a7cc30a You'll have to update to kernel
> version 2.6.39.2 to get this fix.

Cherry-picking this patch, only reduces the output to those two lines:
coretemp coretemp.0: Unable to read TjMax from CPU.
coretemp coretemp.0: Unable to read IA32_TEMPERATURE_TARGET MSR

> Do you happen to know what CPUs model number 0x26 covers? Do you know
> if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
> Atom (model 0x1c) did not.

Both the linux kernel (see above) and the bootloader can't use 
MSR_IA32_TEMPERATURE_TARGET, so I guess this model does not support this 
feature.
I don't know which models have number 0x26, despite the E6xx.

> > But there are models (e.g. E660 and E660T) with different TjMax, namely
> > 90 degrees C and 110 degrees C. But these different model can't be
> > detected by reading from hardware.
> 
> I would appreciate a patch to Documentation/hwmon/coretemp adding the
> known TjMax for these new Atom models.
> 
> BTW, is it really impossible to identify these models with a different
> TjMax? Don't the strings "E660" and "E660T" appear in the respective
> "model name" entries in /proc/cpuinfo?

Here's the cpuinfo output. I didnt find anything which would allow this 
distinction.

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1299.936
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 
cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2599.87
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1299.936
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 
cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2599.54
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

> > IMO there should be some support to adjust the temperature from
> > userspace. Reading Documentation/hwmon/sysfs-interface only temp1_offset
> > seems to be useable. But I think it is somewhat misleading (especially
> > on multicores), because there must only be one offset.
> 
> No, tempN_offset isn't suitable for this case, as it would only shift the
> current temperature and not the limits.
> 
> Instead, we could detect the specific CPUs using the model name string
> and adjust TjMax accordingly. And/or we could let the user override
> TjMax through a module parameter (I doubt anyone runs a system with
> CPUs with different TjMax values.)

As there seem to be no model string to distinct, only the module parameter 
seems valid to do this change.

Regards,
Alexander

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Guenter Roeck]

On Mon, 2011-06-27 at 10:41 -0400, Jean Delvare wrote:
> Hi Alexander,
> 
> On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> > I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> > (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> 
> You have a patch, great for you. What do you expect if you don't share
> it with us?
> 
> I'm not quite sure what your patch would be doing anyway. Since kernel
> 2.6.35, supported CPU models are detected using the DTS feature flag
> rather than the family and model numbers, so your Atom E6XX should be
> detected just fine.
> 
Maybe it is for Tjmax detection ?

> Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
> TjMax guessing, which was fixed by Gunter Roeck with:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hO5f71a7abe329bdad81ee6a8e4545054a7cc30a
> You'll have to update to kernel version 2.6.39.2 to get this fix.
> 
> Do you happen to know what CPUs model number 0x26 covers? Do you know
> if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
> Atom (model 0x1c) did not.
> 
> > But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> > degrees C and 110 degrees C. But these different model can't be detected by 
> > reading from hardware.
> 
> I would appreciate a patch to Documentation/hwmon/coretemp adding the
> known TjMax for these new Atom models.
> 
> BTW, is it really impossible to identify these models with a different
> TjMax? Don't the strings "E660" and "E660T" appear in the respective
> "model name" entries in /proc/cpuinfo?

I thought about replacing the manual TjMax detection code with code
using the model string to take care of problems like this - essentially
by providing a table with entries { model string, Tjmax } for each CPU
with Tjmax other than 100 degrees C. This way we could get rid of some
of the odd code we have today. Would that make sense ?

Thanks,
Guenter



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

Re: coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Guenter Roeck]

On Mon, 2011-06-27 at 10:41 -0400, Jean Delvare wrote:
> Hi Alexander,
> 
> On Mon, 27 Jun 2011 12:20:51 +0200, Alexander Stein wrote:
> > I have a patch (for v2.6.39) which adds support for Intel Atom E6XX 
> > (TunnelCreek) to coretemp. It's merely only adding x86_model 0x26.
> 
> You have a patch, great for you. What do you expect if you don't share
> it with us?
> 
> I'm not quite sure what your patch would be doing anyway. Since kernel
> 2.6.35, supported CPU models are detected using the DTS feature flag
> rather than the family and model numbers, so your Atom E6XX should be
> detected just fine.
> 
Maybe it is for Tjmax detection ?

> Note that there was a bug in kernels 2.6.35 to 2.6.39 with regards to
> TjMax guessing, which was fixed by Gunter Roeck with:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4f5f71a7abe329bdad81ee6a8e4545054a7cc30a
> You'll have to update to kernel version 2.6.39.2 to get this fix.
> 
> Do you happen to know what CPUs model number 0x26 covers? Do you know
> if this model supports MSR_IA32_TEMPERATURE_TARGET or not? The original
> Atom (model 0x1c) did not.
> 
> > But there are models (e.g. E660 and E660T) with different TjMax, namely 90 
> > degrees C and 110 degrees C. But these different model can't be detected by 
> > reading from hardware.
> 
> I would appreciate a patch to Documentation/hwmon/coretemp adding the
> known TjMax for these new Atom models.
> 
> BTW, is it really impossible to identify these models with a different
> TjMax? Don't the strings "E660" and "E660T" appear in the respective
> "model name" entries in /proc/cpuinfo?

I thought about replacing the manual TjMax detection code with code
using the model string to take care of problems like this - essentially
by providing a table with entries { model string, Tjmax } for each CPU
with Tjmax other than 100 degrees C. This way we could get rid of some
of the odd code we have today. Would that make sense ?

Thanks,
Guenter

RE: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[R, Durgadoss]

Hi Guenter,

> I thought about replacing the manual TjMax detection code with code
> using the model string to take care of problems like this - essentially
> by providing a table with entries { model string, Tjmax } for each CPU
> with Tjmax other than 100 degrees C. This way we could get rid of some
> of the odd code we have today. Would that make sense ?

I completely agree with you here.
This way, a lot of code in get_tjmax will be reduced, by just
a search through some array.
 
Thanks,
Durga

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Guenter Roeck]

On Mon, 2011-06-27 at 12:40 -0400, R, Durgadoss wrote:
> Hi Guenter,
> 
> > I thought about replacing the manual TjMax detection code with code
> > using the model string to take care of problems like this - essentially
> > by providing a table with entries { model string, Tjmax } for each CPU
> > with Tjmax other than 100 degrees C. This way we could get rid of some
> > of the odd code we have today. Would that make sense ?
> 
> I completely agree with you here.
> This way, a lot of code in get_tjmax will be reduced, by just
> a search through some array.
>  
Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
like the E6xx chips have no mention of E6xx in the CPU ID string, which
unfortunately kills the idea. 

Do you know if there is _any_ means to distinguish E6xx from E6xxT ?

Thanks,
Guenter



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

RE: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Guenter Roeck]

On Mon, 2011-06-27 at 12:40 -0400, R, Durgadoss wrote:
> Hi Guenter,
> 
> > I thought about replacing the manual TjMax detection code with code
> > using the model string to take care of problems like this - essentially
> > by providing a table with entries { model string, Tjmax } for each CPU
> > with Tjmax other than 100 degrees C. This way we could get rid of some
> > of the odd code we have today. Would that make sense ?
> 
> I completely agree with you here.
> This way, a lot of code in get_tjmax will be reduced, by just
> a search through some array.
>  
Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
like the E6xx chips have no mention of E6xx in the CPU ID string, which
unfortunately kills the idea. 

Do you know if there is _any_ means to distinguish E6xx from E6xxT ?

Thanks,
Guenter

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX

[R, Durgadoss]

Hi Guenter,

> I thought about replacing the manual TjMax detection code with code
> using the model string to take care of problems like this - essentially
> by providing a table with entries { model string, Tjmax } for each CPU
> with Tjmax other than 100 degrees C. This way we could get rid of some
> of the odd code we have today. Would that make sense ?

I completely agree with you here.
This way, a lot of code in get_tjmax will be reduced, by just
a search through some array.
 
Thanks,
Durga


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

RE: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[R, Durgadoss]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 592 bytes --]

Hi Guenter,

> Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> like the E6xx chips have no mention of E6xx in the CPU ID string, which
> unfortunately kills the idea.
> 
> Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> 

Sorry I do not know. But I can ask some folks here and get back
to you guys. Should not take more time, once I identify the right
person to ask :-)

Thanks,
Durga

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[R, Durgadoss]

Hi Guenter,

> Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> like the E6xx chips have no mention of E6xx in the CPU ID string, which
> unfortunately kills the idea.
> 
> Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> 

Sorry I do not know. But I can ask some folks here and get back
to you guys. Should not take more time, once I identify the right
person to ask :-)

Thanks,
Durga

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

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Alexander Stein]

Hello,

On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > like the E6xx chips have no mention of E6xx in the CPU ID string, which
> > unfortunately kills the idea.
> > 
> > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> 
> Sorry I do not know. But I can ask some folks here and get back
> to you guys. Should not take more time, once I identify the right
> person to ask :-)

Any news on this topic?

Regards,
Alexander

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

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Alexander Stein]

Hello,

On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > like the E6xx chips have no mention of E6xx in the CPU ID string, which
> > unfortunately kills the idea.
> > 
> > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> 
> Sorry I do not know. But I can ask some folks here and get back
> to you guys. Should not take more time, once I identify the right
> person to ask :-)

Any news on this topic?

Regards,
Alexander

RE: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[R, Durgadoss]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1208 bytes --]

Hi All,

Yes I checked with some Atom Guys here.
Apparently there is no way to know it from the OS Level.

Sorry,
Durga

> -----Original Message-----
> From: Alexander Stein [mailto:alexander.stein@systec-electronic.com]
> Sent: Wednesday, August 03, 2011 6:28 PM
> To: R, Durgadoss
> Cc: guenter.roeck@ericsson.com; Jean Delvare; Yu, Fenghua; lm-sensors@lm-
> sensors.org; linux-kernel@vger.kernel.org
> Subject: Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU
> (TunnelCreek)?
> 
> Hello,
> 
> On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > like the E6xx chips have no mention of E6xx in the CPU ID string, which
> > > unfortunately kills the idea.
> > >
> > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> >
> > Sorry I do not know. But I can ask some folks here and get back
> > to you guys. Should not take more time, once I identify the right
> > person to ask :-)
> 
> Any news on this topic?
> 
> Regards,
> Alexander
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[R, Durgadoss]

Hi All,

Yes I checked with some Atom Guys here.
Apparently there is no way to know it from the OS Level.

Sorry,
Durga

> -----Original Message-----
> From: Alexander Stein [mailto:alexander.stein@systec-electronic.com]
> Sent: Wednesday, August 03, 2011 6:28 PM
> To: R, Durgadoss
> Cc: guenter.roeck@ericsson.com; Jean Delvare; Yu, Fenghua; lm-sensors@lm-
> sensors.org; linux-kernel@vger.kernel.org
> Subject: Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU
> (TunnelCreek)?
> 
> Hello,
> 
> On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > like the E6xx chips have no mention of E6xx in the CPU ID string, which
> > > unfortunately kills the idea.
> > >
> > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> >
> > Sorry I do not know. But I can ask some folks here and get back
> > to you guys. Should not take more time, once I identify the right
> > person to ask :-)
> 
> Any news on this topic?
> 
> Regards,
> Alexander
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Alexander Stein]

Hi,

On Wednesday 03 August 2011 15:26:53 R, Durgadoss wrote:
> Yes I checked with some Atom Guys here.
> Apparently there is no way to know it from the OS Level.
> 
> > On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > > like the E6xx chips have no mention of E6xx in the CPU ID string,
> > > > which unfortunately kills the idea.
> > > > 
> > > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> > > 
> > > Sorry I do not know. But I can ask some folks here and get back
> > > to you guys. Should not take more time, once I identify the right
> > > person to ask :-)

So, is there a possibility to add a module parameter to force a either 
specific tjmax or the T model for E6xx?

Regards,
Alexander

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

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Alexander Stein]

Hi,

On Wednesday 03 August 2011 15:26:53 R, Durgadoss wrote:
> Yes I checked with some Atom Guys here.
> Apparently there is no way to know it from the OS Level.
> 
> > On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > > like the E6xx chips have no mention of E6xx in the CPU ID string,
> > > > which unfortunately kills the idea.
> > > > 
> > > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> > > 
> > > Sorry I do not know. But I can ask some folks here and get back
> > > to you guys. Should not take more time, once I identify the right
> > > person to ask :-)

So, is there a possibility to add a module parameter to force a either 
specific tjmax or the T model for E6xx?

Regards,
Alexander

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU

[Jean Delvare]

Hi Alexander,

On Wed, 3 Aug 2011 16:40:30 +0200, Alexander Stein wrote:
> On Wednesday 03 August 2011 15:26:53 R, Durgadoss wrote:
> > Yes I checked with some Atom Guys here.
> > Apparently there is no way to know it from the OS Level.
> > 
> > > On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > > > like the E6xx chips have no mention of E6xx in the CPU ID string,
> > > > > which unfortunately kills the idea.
> > > > > 
> > > > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> > > > 
> > > > Sorry I do not know. But I can ask some folks here and get back
> > > > to you guys. Should not take more time, once I identify the right
> > > > person to ask :-)
> 
> So, is there a possibility to add a module parameter to force a either 
> specific tjmax or the T model for E6xx?

A parameter to force the T model for E6xx would be very very specific,
while the problem at hand is much broader: the heuristics in
adjust_tjmax() are best effort but largely insufficient in many (most?)
cases. So, as we have been enable to provide a relative temperature
scale interface in the past 2 years, a module parameter letting the
user set TjMax as needed seems the best approach to me. I'll submit a
patch doing this in a moment.

-- 
Jean Delvare

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

Re: [lm-sensors] coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

[Jean Delvare]

Hi Alexander,

On Wed, 3 Aug 2011 16:40:30 +0200, Alexander Stein wrote:
> On Wednesday 03 August 2011 15:26:53 R, Durgadoss wrote:
> > Yes I checked with some Atom Guys here.
> > Apparently there is no way to know it from the OS Level.
> > 
> > > On Monday 27 June 2011 18:54:44 R, Durgadoss wrote:
> > > > > Unfortunately, looking at Alexander's /proc/cpuinfo output, it looks
> > > > > like the E6xx chips have no mention of E6xx in the CPU ID string,
> > > > > which unfortunately kills the idea.
> > > > > 
> > > > > Do you know if there is _any_ means to distinguish E6xx from E6xxT ?
> > > > 
> > > > Sorry I do not know. But I can ask some folks here and get back
> > > > to you guys. Should not take more time, once I identify the right
> > > > person to ask :-)
> 
> So, is there a possibility to add a module parameter to force a either 
> specific tjmax or the T model for E6xx?

A parameter to force the T model for E6xx would be very very specific,
while the problem at hand is much broader: the heuristics in
adjust_tjmax() are best effort but largely insufficient in many (most?)
cases. So, as we have been enable to provide a relative temperature
scale interface in the past 2 years, a module parameter letting the
user set TjMax as needed seems the best approach to me. I'll submit a
patch doing this in a moment.

-- 
Jean Delvare