* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
@ 2011-02-02 1:23 ` Guenter Roeck
2011-02-02 7:31 ` 4ernov
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2011-02-02 1:23 UTC (permalink / raw)
To: lm-sensors
On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
> Hello,
>
> I have two socket motherboard with two Xeon's 5345 installed on them, so
> overall it's 8 cores. Using lm_sensors all of them are detected correctly out
> of the box, but the problem is that after certain Linux kernel upgrade (I
> believe it's somewhere around 2.6.32) matching kernel on both processors
> started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
> it drives mad many applications which use lm_sensors. Here's the output of
> 'sensors' command:
> sensors
> radeon-pci-0700
> Adapter: PCI adapter
> temp1: +77.0°C
>
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0001
> Adapter: ISA adapter
> Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0002
> Adapter: ISA adapter
> Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0003
> Adapter: ISA adapter
> Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0004
> Adapter: ISA adapter
> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0005
> Adapter: ISA adapter
> Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0006
> Adapter: ISA adapter
> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0007
> Adapter: ISA adapter
> Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
>
> I try to fix the KDE sensors applet as it shows only 4 cores and ignores
> remaining ones due to name collision. But I really don't know how to
> distinguish the certain cores of the processors. Could you please give me a
> reference how can I tell, for instance one 'Core 0' from another? The ideal
> case is if they can be addressed as 'Processor 1/Core 0' but I can't find the
> right way.
>
No idea.
I added the driver maintainer to this e-mail; maybe your problem helps to explain
why Jean and I believe that the driver should instantiate itself per CPU, not per core.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
2011-02-02 1:23 ` [lm-sensors] How to distinguish sensors on Xeon multi-socket Guenter Roeck
@ 2011-02-02 7:31 ` 4ernov
2011-02-02 7:36 ` 4ernov
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 4ernov @ 2011-02-02 7:31 UTC (permalink / raw)
To: lm-sensors
No, they're don't support HyperThread but the sensors apparently not
duplicated, i.e. there're sensor 'Core 0' for 1st processor and 'Core
0' for 2nd and that's right as these are separate cores. What is
similar is their labels and that's the problem.
2011/2/2 David Anderson <davea42@gmail.com>:
> On 02/01/2011 12:23 PM, Alexey Chernov wrote:
>>
>> Hello,
>>
>> I have two socket motherboard with two Xeon's 5345 installed on them, so
>> overall it's 8 cores. Using lm_sensors all of them are detected correctly
>> out
>> of the box, but the problem is that after certain Linux kernel upgrade (I
>> believe it's somewhere around 2.6.32) matching kernel on both processors
>> started to be called identically. I have two 'Core 0', two 'Core 1' etc.
>> and
>> it drives mad many applications which use lm_sensors. Here's the output of
>> 'sensors' command:
>>
> If your Xeon's support HyperThread and you have that turned on in your BIOS
> then that doubles the CPU count Linux sees (try 'cat /proc/cpuinfo').
>
> But that does not double the sensors count for me (2 Xeon 5670's with
> HyperThread on in BIOS).
> I'm no lm-sensors expert...
>
> david anderson
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
2011-02-02 1:23 ` [lm-sensors] How to distinguish sensors on Xeon multi-socket Guenter Roeck
2011-02-02 7:31 ` 4ernov
@ 2011-02-02 7:36 ` 4ernov
2011-02-02 7:47 ` Jean Delvare
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 4ernov @ 2011-02-02 7:36 UTC (permalink / raw)
To: lm-sensors
Thanks, Guenter.
Before the problem appeared (I think, pre-2.6.32 kernels or so) there
were sensors for every core, too, but as I remember they used to have
labels 'Core 0' to 'Core 7', so without similar ones.
2011/2/2 Guenter Roeck <guenter.roeck@ericsson.com>:
> On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
>> Hello,
>>
>> I have two socket motherboard with two Xeon's 5345 installed on them, so
>> overall it's 8 cores. Using lm_sensors all of them are detected correctly out
>> of the box, but the problem is that after certain Linux kernel upgrade (I
>> believe it's somewhere around 2.6.32) matching kernel on both processors
>> started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
>> it drives mad many applications which use lm_sensors. Here's the output of
>> 'sensors' command:
>> sensors
>> radeon-pci-0700
>> Adapter: PCI adapter
>> temp1: +77.0°C
>>
>> coretemp-isa-0000
>> Adapter: ISA adapter
>> Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0001
>> Adapter: ISA adapter
>> Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0002
>> Adapter: ISA adapter
>> Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0003
>> Adapter: ISA adapter
>> Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0004
>> Adapter: ISA adapter
>> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0005
>> Adapter: ISA adapter
>> Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0006
>> Adapter: ISA adapter
>> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> coretemp-isa-0007
>> Adapter: ISA adapter
>> Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
>>
>> I try to fix the KDE sensors applet as it shows only 4 cores and ignores
>> remaining ones due to name collision. But I really don't know how to
>> distinguish the certain cores of the processors. Could you please give me a
>> reference how can I tell, for instance one 'Core 0' from another? The ideal
>> case is if they can be addressed as 'Processor 1/Core 0' but I can't find the
>> right way.
>>
> No idea.
>
> I added the driver maintainer to this e-mail; maybe your problem helps to explain
> why Jean and I believe that the driver should instantiate itself per CPU, not per core.
>
> Guenter
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (2 preceding siblings ...)
2011-02-02 7:36 ` 4ernov
@ 2011-02-02 7:47 ` Jean Delvare
2011-02-02 7:56 ` Jean Delvare
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2011-02-02 7:47 UTC (permalink / raw)
To: lm-sensors
On Tue, 1 Feb 2011 17:23:04 -0800, Guenter Roeck wrote:
> On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
> > Hello,
> >
> > I have two socket motherboard with two Xeon's 5345 installed on them, so
> > overall it's 8 cores. Using lm_sensors all of them are detected correctly out
> > of the box, but the problem is that after certain Linux kernel upgrade (I
> > believe it's somewhere around 2.6.32) matching kernel on both processors
> > started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
> > it drives mad many applications which use lm_sensors. Here's the output of
These are badly written applications, which need to be fixed
regardless of what the coretemp did, does, or will do. Label uniqueness
across multiple sensor devices isn't and has never been guaranteed. We
only guarantee uniqueness of symbols within each given chip.
Application which needs unique keys must use the combination of the
chip name + the symbol name; definitely not the label.
> > 'sensors' command:
> > sensors
> > radeon-pci-0700
> > Adapter: PCI adapter
> > temp1: +77.0°C
> >
> > coretemp-isa-0000
> > Adapter: ISA adapter
> > Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0001
> > Adapter: ISA adapter
> > Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0002
> > Adapter: ISA adapter
> > Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0003
> > Adapter: ISA adapter
> > Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0004
> > Adapter: ISA adapter
> > Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0005
> > Adapter: ISA adapter
> > Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0006
> > Adapter: ISA adapter
> > Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > coretemp-isa-0007
> > Adapter: ISA adapter
> > Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
> >
> > I try to fix the KDE sensors applet as it shows only 4 cores and ignores
> > remaining ones due to name collision. But I really don't know how to
> > distinguish the certain cores of the processors. Could you please give me a
> > reference how can I tell, for instance one 'Core 0' from another? The ideal
> > case is if they can be addressed as 'Processor 1/Core 0' but I can't find the
> > right way.
>
> No idea.
Currently, you can't.
> I added the driver maintainer to this e-mail; maybe your problem helps to explain
> why Jean and I believe that the driver should instantiate itself per CPU, not per core.
Yes, definitely. The above output should really look like:
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0001
Adapter: ISA adapter
Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
where 0000 and 0001 would be the CPU numbers. This would be much easier
for users to figure out what they're seeing. We're waiting for the
coretemp driver maintainer to implement this.
In the meantime, a workaround would be to align the hwmon device
numbers with the CPU number, so that the user can at least look-up
in /proc/cpuinfo to find out who is who. But there is no guarantee for
the CPU enumeration order to stay the same across reboots, so the
interest would be limited in practice.
--
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] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (3 preceding siblings ...)
2011-02-02 7:47 ` Jean Delvare
@ 2011-02-02 7:56 ` Jean Delvare
2011-02-02 9:15 ` 4ernov
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2011-02-02 7:56 UTC (permalink / raw)
To: lm-sensors
On Wed, 2 Feb 2011 10:36:09 +0300, 4ernov wrote:
> Before the problem appeared (I think, pre-2.6.32 kernels or so) there
> were sensors for every core, too, but as I remember they used to have
> labels 'Core 0' to 'Core 7', so without similar ones.
Please don't top-post.
Yes, the driver used to do this and it was a bug (it presented two
4-core CPUs as if it was a single 8-core CPU), and it was fixed. What
you call "a problem" is actually a bug fix. The fact that poorly written
applications can't cope with the change is unfortunate, but this is a
bug you have to report to their authors, not to us.
--
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] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (4 preceding siblings ...)
2011-02-02 7:56 ` Jean Delvare
@ 2011-02-02 9:15 ` 4ernov
2011-02-02 9:34 ` 4ernov
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 4ernov @ 2011-02-02 9:15 UTC (permalink / raw)
To: lm-sensors
2011/2/2 Jean Delvare <khali@linux-fr.org>:
> On Wed, 2 Feb 2011 10:36:09 +0300, 4ernov wrote:
>> Before the problem appeared (I think, pre-2.6.32 kernels or so) there
>> were sensors for every core, too, but as I remember they used to have
>> labels 'Core 0' to 'Core 7', so without similar ones.
>
> Please don't top-post.
>
> Yes, the driver used to do this and it was a bug (it presented two
> 4-core CPUs as if it was a single 8-core CPU), and it was fixed. What
> you call "a problem" is actually a bug fix. The fact that poorly written
> applications can't cope with the change is unfortunate, but this is a
> bug you have to report to their authors, not to us.
>
> --
> Jean Delvare
>
Thanks for description. I just called "a problem" the bug in the
application (it is ksysguardd, to be more exact), which currently
relies on label uniqueness and after the fix in driver fails to work
properly (it simply doesn't add sensor if there's already one with the
same name). I posted a bug months ago but nobody seems to care or they
tend to consider it upstream as it worked before due to the bug in
driver you mentioned. So I decided to fix it by myself there. So I
just wanted to know how to fix the application code properly.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (5 preceding siblings ...)
2011-02-02 9:15 ` 4ernov
@ 2011-02-02 9:34 ` 4ernov
2011-02-02 11:08 ` Jean Delvare
2011-02-02 11:33 ` 4ernov
8 siblings, 0 replies; 10+ messages in thread
From: 4ernov @ 2011-02-02 9:34 UTC (permalink / raw)
To: lm-sensors
2011/2/2 Jean Delvare <khali@linux-fr.org>:
> On Tue, 1 Feb 2011 17:23:04 -0800, Guenter Roeck wrote:
>> On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
>> > Hello,
>> >
>> > I have two socket motherboard with two Xeon's 5345 installed on them, so
>> > overall it's 8 cores. Using lm_sensors all of them are detected correctly out
>> > of the box, but the problem is that after certain Linux kernel upgrade (I
>> > believe it's somewhere around 2.6.32) matching kernel on both processors
>> > started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
>> > it drives mad many applications which use lm_sensors. Here's the output of
>
> These are badly written applications, which need to be fixed
> regardless of what the coretemp did, does, or will do. Label uniqueness
> across multiple sensor devices isn't and has never been guaranteed. We
> only guarantee uniqueness of symbols within each given chip.
> Application which needs unique keys must use the combination of the
> chip name + the symbol name; definitely not the label.
That's right and this is what I want to do with one of them but the
question is how to do it properly. Thank you for suggestion on unique
keys. What is "symbol name"? Does it stand for sensors_feature struct
or label?
>> > 'sensors' command:
>> > sensors
>> > radeon-pci-0700
>> > Adapter: PCI adapter
>> > temp1: +77.0°C
>> >
>> > coretemp-isa-0000
>> > Adapter: ISA adapter
>> > Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0001
>> > Adapter: ISA adapter
>> > Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0002
>> > Adapter: ISA adapter
>> > Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0003
>> > Adapter: ISA adapter
>> > Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0004
>> > Adapter: ISA adapter
>> > Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0005
>> > Adapter: ISA adapter
>> > Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0006
>> > Adapter: ISA adapter
>> > Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > coretemp-isa-0007
>> > Adapter: ISA adapter
>> > Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
>> >
>> > I try to fix the KDE sensors applet as it shows only 4 cores and ignores
>> > remaining ones due to name collision. But I really don't know how to
>> > distinguish the certain cores of the processors. Could you please give me a
>> > reference how can I tell, for instance one 'Core 0' from another? The ideal
>> > case is if they can be addressed as 'Processor 1/Core 0' but I can't find the
>> > right way.
>>
>> No idea.
>
> Currently, you can't.
>
>> I added the driver maintainer to this e-mail; maybe your problem helps to explain
>> why Jean and I believe that the driver should instantiate itself per CPU, not per core.
>
> Yes, definitely. The above output should really look like:
>
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
> Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
> Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
>
> coretemp-isa-0001
> Adapter: ISA adapter
> Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
> Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
> Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
> Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
>
> where 0000 and 0001 would be the CPU numbers. This would be much easier
> for users to figure out what they're seeing. We're waiting for the
> coretemp driver maintainer to implement this.
>
> In the meantime, a workaround would be to align the hwmon device
> numbers with the CPU number, so that the user can at least look-up
> in /proc/cpuinfo to find out who is who. But there is no guarantee for
> the CPU enumeration order to stay the same across reboots, so the
> interest would be limited in practice.
Is it about lm-sensors or the applications? As for the applications I
think it's the possible solution because the list of sensors could be
generated on every startup of the app and if there were some mapping
between hwmon and, say, 'core id' in /proc/cpuinfo, the processors can
be recognized.
>
> --
> Jean Delvare
>
Jean, thank you very much for detailed information. I hope it helps a
lot to fix my problem.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (6 preceding siblings ...)
2011-02-02 9:34 ` 4ernov
@ 2011-02-02 11:08 ` Jean Delvare
2011-02-02 11:33 ` 4ernov
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2011-02-02 11:08 UTC (permalink / raw)
To: lm-sensors
On Wed, 2 Feb 2011 12:34:44 +0300, 4ernov wrote:
> 2011/2/2 Jean Delvare <khali@linux-fr.org>:
> > On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
> > > Hello,
> > >
> > > I have two socket motherboard with two Xeon's 5345 installed on them, so
> > > overall it's 8 cores. Using lm_sensors all of them are detected correctly out
> > > of the box, but the problem is that after certain Linux kernel upgrade (I
> > > believe it's somewhere around 2.6.32) matching kernel on both processors
> > > started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
> > > it drives mad many applications which use lm_sensors. Here's the output of
> >
> > These are badly written applications, which need to be fixed
> > regardless of what the coretemp did, does, or will do. Label uniqueness
> > across multiple sensor devices isn't and has never been guaranteed. We
> > only guarantee uniqueness of symbols within each given chip.
> > Application which needs unique keys must use the combination of the
> > chip name + the symbol name; definitely not the label.
>
> That's right and this is what I want to do with one of them but the
> question is how to do it properly. Thank you for suggestion on unique
> keys. What is "symbol name"? Does it stand for sensors_feature struct
> or label?
Symbol names are things like "in0" or "temp1". Which in libsensors
indeed corresponds to sensors_feature structure.
> > (...)
> > In the meantime, a workaround would be to align the hwmon device
> > numbers with the CPU number, so that the user can at least look-up
> > in /proc/cpuinfo to find out who is who. But there is no guarantee for
> > the CPU enumeration order to stay the same across reboots, so the
> > interest would be limited in practice.
>
> Is it about lm-sensors or the applications? As for the applications I
The workaround would be in the coretemp driver. But it would only let
you look-up manually which coretemp entry corresponds to which physical
CPU. It wouldn't help with bogus applications which rely on label
uniqueness.
> think it's the possible solution because the list of sensors could be
> generated on every startup of the app and if there were some mapping
> between hwmon and, say, 'core id' in /proc/cpuinfo, the processors can
> be recognized.
Really, I don't think we want to invest any development time in this.
Applications shouldn't have to do this, the coretemp driver should
simply group sensors together when they belong to the same CPU.
--
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] 10+ messages in thread* Re: [lm-sensors] How to distinguish sensors on Xeon multi-socket
2011-02-01 20:23 [lm-sensors] How to distinguish sensors on Xeon multi-socket system Alexey Chernov
` (7 preceding siblings ...)
2011-02-02 11:08 ` Jean Delvare
@ 2011-02-02 11:33 ` 4ernov
8 siblings, 0 replies; 10+ messages in thread
From: 4ernov @ 2011-02-02 11:33 UTC (permalink / raw)
To: lm-sensors
2011/2/2 Jean Delvare <khali@linux-fr.org>:
> On Wed, 2 Feb 2011 12:34:44 +0300, 4ernov wrote:
>> 2011/2/2 Jean Delvare <khali@linux-fr.org>:
>> > On Tue, Feb 01, 2011 at 03:23:13PM -0500, Alexey Chernov wrote:
>> > > Hello,
>> > >
>> > > I have two socket motherboard with two Xeon's 5345 installed on them, so
>> > > overall it's 8 cores. Using lm_sensors all of them are detected correctly out
>> > > of the box, but the problem is that after certain Linux kernel upgrade (I
>> > > believe it's somewhere around 2.6.32) matching kernel on both processors
>> > > started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
>> > > it drives mad many applications which use lm_sensors. Here's the output of
>> >
>> > These are badly written applications, which need to be fixed
>> > regardless of what the coretemp did, does, or will do. Label uniqueness
>> > across multiple sensor devices isn't and has never been guaranteed. We
>> > only guarantee uniqueness of symbols within each given chip.
>> > Application which needs unique keys must use the combination of the
>> > chip name + the symbol name; definitely not the label.
>>
>> That's right and this is what I want to do with one of them but the
>> question is how to do it properly. Thank you for suggestion on unique
>> keys. What is "symbol name"? Does it stand for sensors_feature struct
>> or label?
>
> Symbol names are things like "in0" or "temp1". Which in libsensors
> indeed corresponds to sensors_feature structure.
>
>> > (...)
>> > In the meantime, a workaround would be to align the hwmon device
>> > numbers with the CPU number, so that the user can at least look-up
>> > in /proc/cpuinfo to find out who is who. But there is no guarantee for
>> > the CPU enumeration order to stay the same across reboots, so the
>> > interest would be limited in practice.
>>
>> Is it about lm-sensors or the applications? As for the applications I
>
> The workaround would be in the coretemp driver. But it would only let
> you look-up manually which coretemp entry corresponds to which physical
> CPU. It wouldn't help with bogus applications which rely on label
> uniqueness.
>
>> think it's the possible solution because the list of sensors could be
>> generated on every startup of the app and if there were some mapping
>> between hwmon and, say, 'core id' in /proc/cpuinfo, the processors can
>> be recognized.
>
> Really, I don't think we want to invest any development time in this.
> Applications shouldn't have to do this, the coretemp driver should
> simply group sensors together when they belong to the same CPU.
Ok, so I'll simply use "the chip name + the symbol name" as you
suggested for now without any hints on what the sensor is. I believe
correct enumeration of sensors is better anyway than ignoring some of
sensors because of relying on unique labels.
Thank you all very much for help and detailed information!
> --
> 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] 10+ messages in thread