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@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
