lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110627164108.777c2e28@endymion.delvare>
Date:	Mon, 27 Jun 2011 16:41:08 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Alexander Stein <alexander.stein@...tec-electronic.com>
Cc:	Fenghua Yu <fenghua.yu@...el.com>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: coretemp: Support for Intel Atom E6XX CPU (TunnelCreek)?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ