Bug 896632

Created attachment 606278 [details]
dmesg

show us the output of

    ls -l /sys/devices/platform/

and

    ls -l /sys/devices/platform/coretemp.0/

as this is what xosview also does before trying to read the informations in the files below e.g. /sys/devices/platform/coretemp.0/

Beside this, what das happen if you try to do e.g.

    for x in /sys/devices/platform/coretemp.0/temp*_label ; do
        car $x
    done

also show the result of

    lscpu

Not `car' but `cat' indeed

(In reply to comment #2)
> show us the output of
> 
>     ls -l /sys/devices/platform/

drwxr-xr-x 3 root root    0 15. Sep 12:30 alarmtimer
drwxr-xr-x 4 root root    0 15. Sep 02:00 coretemp.0
drwxr-xr-x 4 root root    0 15. Sep 02:00 f71882fg.2560
drwxr-xr-x 4 root root    0 15. Sep 12:30 i8042
drwxr-xr-x 3 root root    0 15. Sep 12:30 microcode
drwxr-xr-x 4 root root    0 15. Sep 12:30 pcspkr
drwxr-xr-x 2 root root    0 15. Sep 12:53 power
drwxr-xr-x 4 root root    0 15. Sep 12:30 serial8250
-rw-r--r-- 1 root root 4096 15. Sep 12:53 uevent
drwxr-xr-x 4 root root    0 15. Sep 12:30 vesafb.0

> and
> 
>     ls -l /sys/devices/platform/coretemp.0/

lrwxrwxrwx 1 root root    0 15. Sep 12:30 driver -> ../../../bus/platform/drivers/coretemp
drwxr-xr-x 3 root root    0 15. Sep 02:00 hwmon
-r--r--r-- 1 root root 4096 15. Sep 12:53 modalias
-r--r--r-- 1 root root 4096 15. Sep 02:00 name
drwxr-xr-x 2 root root    0 15. Sep 12:53 power
lrwxrwxrwx 1 root root    0 15. Sep 02:00 subsystem -> ../../../bus/platform
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp2_crit
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp2_crit_alarm
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp2_input
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp2_label
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp2_max
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp4_crit
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp4_crit_alarm
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp4_input
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp4_label
-r--r--r-- 1 root root 4096 15. Sep 02:00 temp4_max
-rw-r--r-- 1 root root 4096 15. Sep 12:30 uevent

 
> as this is what xosview also does before trying to read the informations in the
> files below e.g. /sys/devices/platform/coretemp.0/
> 
> Beside this, what das happen if you try to do e.g.
> 
>     for x in /sys/devices/platform/coretemp.0/temp*_label ; do
>         car $x
>     done

Core 0
Core 2

> also show the result of
> 
>     lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 37
Model name:            Intel(R) Core(TM) i3 CPU         540  @ 3.07GHz
Stepping:              2
CPU MHz:               1200.000
BogoMIPS:              6117.98
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              4096K
NUMA node0 CPU(s):     0-3

Hmmmm ... in xosview wird via g++ der system call openat() mit O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC verwendet.  Woher kommen dann die vielen Unterdateien?  Wenn ich es hier starte, funktioniert es.

Created attachment 606371 [details]
Yet an other xosview binary with debug  code in

please save this as e.g. xosview.test and run

        ./xosview.test +coretemp

and report the output here

(In reply to comment #6)
> and report the output here

0 <-> 2
0 <-> 2

and it still hangs.

The problem seems to be that the numbers of cores jumps away

> > 
> >     for x in /sys/devices/platform/coretemp.0/temp*_label ; do
> >         car $x
> >     done
> 
> Core 0
> Core 2

... never seen that and I gues the author of xosview also never does ... where are the Core 1.  Is this a change in the kernels API?  Had this ever happen before?

(In reply to comment #8)
> The problem seems to be that the numbers of cores jumps away
> 
> > > 
> > >     for x in /sys/devices/platform/coretemp.0/temp*_label ; do
> > >         car $x
> > >     done
> > 
> > Core 0
> > Core 2
> 
> ... never seen that and I gues the author of xosview also never does ... where
> are the Core 1.  Is this a change in the kernels API?  Had this ever happen
> before?

Don't know; I've never tried coretemp before. But an i3 540 is not unusual...

btw, I have here on a openSUSE-12.3
# for x in /sys/devices/platform/coretemp.0/temp*_label ; do cat $x ; done
Core 9
Core 10
Core 0
Core 1

on a
> processor       : 7
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 44
> model name      : Intel(R) Xeon(R) CPU           E5630  @ 2.53GHz

so I guess it is related to hyper-threading on Intel CPUs.

12.3's xosview does ignore +coretemps, but using the one from X11:Utilities 
I can reproduce the bug there

Starting with "recent" Intel platforms, core numbering is no longer linear. Applications which expected core numbering linearity may break as a consequence - I think that's what is happening here. It's not a bug in the kernel, as the numbering is provided by the platform itself.

Libsensors is already fixed so monitoring applications which rely on libsensors are also fixed. xosview authors should seriously consider moving to libsensors to gather the information they need, in order to avoid that kind of problem in the future.

Bug is also present in latest 1.16 from upstream.
http://www.pogo.org.uk/~mark/xosview/

However, it is hard to find a place to report this upstream
so maybe you want to do the fix or porting to libsensors?

Wanted : A new maintainer with background in /proc and /sys layout and C++ experience not only programming but also debugging.

Reason : I do not have the time even if I use xosview ar my own

Try latest xosview from X11:Utilities/xosview on openSUSE 13.2

This is an autogenerated message for OBS integration:
This bug (896632) was mentioned in
https://build.opensuse.org/request/show/283896 Factory / xosview

The new version no more hangs on start and shows a temperature for CPU0

(In reply to Bernhard Wiedemann from comment #17)

Maybe I should rename CPU0 to SOCKET0 as the manual page states:

       xosview*coretempNPackage:   0
              The number of physical CPU for meter N on Linux. Currently only
              one physical CPU can be shown per meter.

that is this physical socket may four cores with eight logical cpus

(In reply to Dr. Werner Fink from comment #15)
> Try latest xosview from X11:Utilities/xosview on openSUSE 13.2

That shows me one bar (with CPU0) on my i3 540 (2 cores, 2HT cores).

(In reply to Martin Schröder from comment #19)
> (In reply to Dr. Werner Fink from comment #15)
> > Try latest xosview from X11:Utilities/xosview on openSUSE 13.2
> 
> That shows me one bar (with CPU0) on my i3 540 (2 cores, 2HT cores).

Btw: sensors knowns about two cores:

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +54.0°C  (high = +89.0°C, crit = +105.0°C)
Core 2:       +59.0°C  (high = +89.0°C, crit = +105.0°C)

(In reply to Martin Schröder from comment #20)

Do you read the manual page? ... At least the paragraph I've pasted:

       xosview*coretempNPackage:   0
              The number of physical CPU for meter N on Linux. Currently only
              one physical CPU can be shown per meter.

I'll not hack this away.  The xosview simply reads the link `device' and if this pints to coretemp.* it reads temp*_input below /sys/class/hwmon/hwmon*/ and i guess you have exactly one coretemp.0 hence one line.

If you think this should be changed then you are free to fork https://github.com/hills/xosview

(In reply to Werner Fink from comment #21)
> (In reply to Martin Schröder from comment #20)
> 
> Do you read the manual page? ... At least the paragraph I've pasted:
> 
>        xosview*coretempNPackage:   0
>               The number of physical CPU for meter N on Linux. Currently only
>               one physical CPU can be shown per meter.
> 
> I'll not hack this away.  The xosview simply reads the link `device' and if
> this pints to coretemp.* it reads temp*_input below /sys/class/hwmon/hwmon*/
> and i guess you have exactly one coretemp.0 hence one line.

Fair enough. But then the description should be changed: It's always the first core (my machine has only one physical CPU, but it has two cores).

Also, the documentation for xosview*coretempNDisplayType makes it sound like my machine should show two meters, so that option should probably also be removed.

This is an autogenerated message for OBS integration:
This bug (896632) was mentioned in
https://build.opensuse.org/request/show/546335 15.0 / xosview