From: Guenter Roeck <guenter.roeck@ericsson.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] adjusting /etc/sensors.conf for a dual processor
Date: Sat, 24 Sep 2011 18:04:13 +0000 [thread overview]
Message-ID: <20110924180413.GA24687@ericsson.com> (raw)
In-Reply-To: <1316867250.1306.YahooMailNeo@web36606.mail.mud.yahoo.com>
On Sat, Sep 24, 2011 at 01:01:51PM -0400, Jean Delvare wrote:
> On Sat, 24 Sep 2011 09:10:17 -0700 (PDT), Audio Phile wrote:
> > Ah! I didn't read the output carefully. If you notice, the "core id" is what is causing this, nothing wrong with lm-sensors here.
>
> Indeed, the unexpected core IDs come straight from /proc/cpuinfo.
>
> > We can I think blame HP. Next question would be how to get this on to the lm-sensors wiki so that other HP Z600 users can make this addition to their configs if necessary.
>
> What makes you think the system vendor has anything to do with this? I
> would expect the core IDs to be reported by the CPU itself (someone
> please correct me if I'm wrong.)
>
> > $ grep "core id" cpuinfo.txt
> > core id : 0
> > core id : 1
> > core id : 9
> > core id : 10
> > core id : 0
> > core id : 1
> > core id : 9
> > core id : 10
> > core id : 0
> > core id : 1
> > core id : 9
> > core id : 10
> > core id : 0
> > core id : 1
> > core id : 9
> > core id : 10
>
> I have no idea if the CPU is just reporting strange values or if the
> kernel is somehow misbehaving.
>
I suspect it is the CPU ... for each CPU model I have been testing with, I have seen
different yet consistent CPU numbers for the "real" cores if the CPU supports
hyperthreading. Sometimes the siblings are the odd numbers, sometimes the real cores
come first followed by the siblings, and sometimes the real cores have the lower
and upper numbers and the siblings are in the center. Seems like real core numbering
may be inconsistent across CPU models.
My guess may be wrong, of course, but I don't immediately see how the kernel
would manage to assign consistent CPU numbers for each model across boots,
yet just as consistently different numbers for other CPU models.
The above is really a strange one, though. So far the gaps I have seen were always
the hyperthreading siblings.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2011-09-24 18:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-24 12:27 [lm-sensors] adjusting /etc/sensors.conf for a dual processor Audio Phile
2011-09-24 14:51 ` Guenter Roeck
2011-09-24 15:19 ` Audio Phile
2011-09-24 15:51 ` Jean Delvare
2011-09-24 16:07 ` Audio Phile
2011-09-24 16:10 ` Audio Phile
2011-09-24 17:01 ` Jean Delvare
2011-09-24 17:42 ` Audio Phile
2011-09-24 18:04 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110924180413.GA24687@ericsson.com \
--to=guenter.roeck@ericsson.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.