[CPU-X] Une outil similaire à CPU-Z, pour GNU/Linux

[BlondVador]

Je ne connais que la solution lm_sensors pour les CPU malheureusement, mais nul doute qu'il en existe d'autres.

Pour les GPU, je sais que pour le pilote proprio de nvidia, on peut la récupérer avec (le paquet nvidia-settings étant une dépendance obligatoire de nvidia) :
nvidia-settings -q gpucoretemp
En utilisant des parsers ça devrait être récupérable.

Pour ATI et son pilote proprio :
aticonfig --odgt

Aucune idée concernant les pilotes libres malheureusement mais avec une grosse condition il devrait être possible de faire un support partiel de cette fonctionnalité.

J'espère que ça pourra t'aider.

Merci en tout cas .

[Xorg]

Le gros problème avec lm_sensors, c'est qu'on a des sondes mais on ne sait pas à quoi elles correspondent ; on peut renommer les sondes, ce qui fait que ça devient plus compliqué de se baser sur quelque chose. Toutes les machines n'utilisent pas coretemp pour donner la température du CPU, et c'est un autre problème. Lm_sensors ne fonctionne qu'avec Linux il me semble.

Comme j'ai dis, pour la température et la tension, je préfère me tourner vers libcpuid. Je suis en train de faire des patchs, pour l'instant j'ai réussi à porter du code d'i7z sans difficulté à libcpuid. Un exemple de la sortie que j'obtiens :

Code : Tout sélectionner

$ sensors
coretemp-isa-0000
Physical id 0:  +45.0°C  (high = +80.0°C, crit = +98.0°C)
Core 0:         +41.0°C  (high = +80.0°C, crit = +98.0°C)
Core 1:         +38.0°C  (high = +80.0°C, crit = +98.0°C)
Core 2:         +43.0°C  (high = +80.0°C, crit = +98.0°C)
Core 3:         +42.0°C  (high = +80.0°C, crit = +98.0°C)

nct6776-isa-0290
Vcore:                +1.16 V  (min =  +0.80 V, max =  +1.38 V)

$ cpu-x
(DEVEL) Core 0 : 1,34V 41,0°c
(DEVEL) Core 1 : 1,34V 40,0°c
(DEVEL) Core 2 : 1,34V 44,0°c
(DEVEL) Core 3 : 1,34V 43,0°c

Les températures sont similaires avec celles de coretemp, mais les tensions sont peu trop élevées (j'ai demandé une explication aux développeurs sur ces tensions élevées).

Pour la température des GPU, le plus simple serait effectivement d'utiliser des parsers je pense. Je sais que Radeon-profile s'occupe de lire températures et tensions des cartes AMD (pilote libre ou proprio), et pour le pilote libre on peut trouver la température dans le fichier /sys/class/drm/card0/device/hwmon/hwmon0/temp1_input.

Ça peut m'être utile en effet, merci.

[kozaki]

cpu-x m'intéresse, pour un projet de tests applicatifs en cours.
Mais sur la machine i686 (Atom) il dit

Code : Tout sélectionner

*** Error in `cpu-x': free(): invalid next size (normal): 0x0890c2e8 ***

avec le bactrace & Co : https://defuse.ca/b/c8a5jNZR17vMnmBQ66IoNK

Pour les températures et la partie GPU, tu as jeté un oeil à https://aur.archlinux.org/packages/i-nex/ ?

[Xorg]

cpu-x m'intéresse, pour un projet de tests applicatifs en cours.
Mais sur la machine i686 (Atom) il dit

Code : Tout sélectionner

*** Error in `cpu-x': free(): invalid next size (normal): 0x0890c2e8 ***

avec le bactrace & Co : https://defuse.ca/b/c8a5jNZR17vMnmBQ66IoNK

Tu peux me donner la sortie de cpu-x -v sinon ? J'ai l'impression que ça vient de libdmi_fallback();

Pour les températures et la partie GPU, tu as jeté un oeil à https://aur.archlinux.org/packages/i-nex/ ?

Oui, je connais. I-Nex lit beaucoup de fichiers, alors que j'ai opté pour des fonctions provenant de bibliothèques existantes moi.
Je pourrai jeter un œil.

[kozaki]

Bien vu Xorg

Code : Tout sélectionner

...
Recherche des instructions du CPU
Remplissage des labels (étape libdmi, mode de secours)
*** Error in `cpu-x': free(): invalid next size (normal): 0x083842e8 ***

La sortie complète https://defuse.ca/b/DKq1zwvuD5ZB0mkpE53t4o

Oui, je connais. I-Nex lit beaucoup de fichiers, alors que j'ai opté pour des fonctions provenant de bibliothèques existantes moi.

C'est une autre dif intéressante avec les dépendances )

À propos 2 petites questions :
cpu-x se compile sur bien sur d'autres distros ?
C'est quoi les versions requises des dépendances ? pour des distros qu'ont de la bouteille (celle qui me vient à l'esprit a cpuid 20120601, ncurses 5.9, pciutils 3.1.7, procps 3.2.8 ).
Si ça coince je garde ce vache de bon script psinfo sous le coude.

[benjarobin]

@kozaki Si tu veux rapporter un bug il est bien plus intéressant de compiler avec les symboles de debug et de désactiver le strip
Pour cela il suffit de rajouter dans le PKGBUILD cette ligne avant la fonction prepare

Code : Tout sélectionner

options=('!strip' 'debug')

Pas le temps de creuser mais j'ai ceci :

Code : Tout sélectionner

==19156== Memcheck, a memory error detector
==19156== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==19156== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==19156== Command: cpu-x
==19156== 
==19156== Invalid write of size 4
==19156==    at 0x57A50BB: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57A5840: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5746B4F: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57C090F: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5791D46: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x574F66B: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5748548: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5741444: cairo_fill (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x4FA3D96: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==    by 0x4FA4EAF: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==    by 0x4FA2DD8: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==    by 0x50AB3F3: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==  Address 0xffeffca78 is on thread 1's stack
==19156== 
==19156== Invalid read of size 4
==19156==    at 0x57A26DF: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57A42C7: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57A50EB: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57A5840: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5746B4F: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x57C090F: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5791D46: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x574F66B: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5748548: ??? (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x5741444: cairo_fill (in /usr/lib/libcairo.so.2.11400.2)
==19156==    by 0x4FA3D96: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==    by 0x4FA4EAF: ??? (in /usr/lib/libgtk-3.so.0.1600.7)
==19156==  Address 0xffeffca78 is on thread 1's stack
==19156== 
==19156== 
==19156== Process terminating with default action of signal 11 (SIGSEGV)
==19156==  General Protection Fault
==19156==    at 0x92D67E3: __lll_unlock_elision (in /usr/lib/libpthread-2.22.so)
==19156==    by 0x9ADB26B: ??? (in /usr/lib/nvidia/libEGL.so.352.41)
==19156==    by 0x9A6BA21: ??? (in /usr/lib/nvidia/libEGL.so.352.41)
==19156==    by 0x9AEFEA0: ??? (in /usr/lib/nvidia/libEGL.so.352.41)
==19156==    by 0x6F0BF87: __run_exit_handlers (in /usr/lib/libc-2.22.so)
==19156==    by 0x6F0BFD4: exit (in /usr/lib/libc-2.22.so)
==19156==    by 0x6EF6616: (below main) (in /usr/lib/libc-2.22.so)
==19156== 
==19156== HEAP SUMMARY:
==19156==     in use at exit: 4,029,720 bytes in 44,333 blocks
==19156==   total heap usage: 338,931 allocs, 294,598 frees, 471,969,350 bytes allocated
==19156== 
==19156== LEAK SUMMARY:
==19156==    definitely lost: 14,230 bytes in 241 blocks
==19156==    indirectly lost: 40,424 bytes in 1,648 blocks
==19156==      possibly lost: 188,856 bytes in 2,678 blocks
==19156==    still reachable: 3,451,826 bytes in 38,285 blocks
==19156==         suppressed: 0 bytes in 0 blocks

[kozaki]

options=('!strip' 'debug')

Bien reçu. Par contre la sortie est la même que sans, il me manque un truc ?
https://defuse.ca/b/UoAsNvfHgP2sZkgHEs8fZz

@Xorg : question ci-dessus quand tu passes
J'espère pouvoir tester avec les temp et infos GPU.

[benjarobin]

@kozaki Peux tu donne la sortie de :

Code : Tout sélectionner

grep -Ev "^ *#|^ *$" /etc/makepkg.conf
ls -l /usr/bin/cpu-x
nm -a /usr/bin/cpu-x

[benjarobin]

Après relecture vite fait, la fonction libdmi_fallback devrait être totalement être réécrite, il y a plein de débordement de buffer possible.
De plus tabmb n'est pas totalement initialisé

[Xorg]

À propos 2 petites questions :
cpu-x se compile sur bien sur d'autres distros ?
C'est quoi les versions requises des dépendances ? pour des distros qu'ont de la bouteille (celle qui me vient à l'esprit a cpuid 20120601, ncurses 5.9, pciutils 3.1.7, procps 3.2.8 ).
Si ça coince je garde ce vache de bon script psinfo sous le coude.

Oui, bien sûr, j'ai ouvert un dépôt sur OBS : https://build.opensuse.org/package/show/home:X0rg/cpu-x
Ou tu peux trouver la liste des paquets ici.
Concrètement, on doit pouvoir le faire tourner sur toutes les distros GNU/Linux récentes (je peux pas compiler sur les plus vieilles car je n'arrive pas à satisfaire CMake 3.0). J'ai fait plusieurs tests sur GhostBSD et ça tournait, de même sur OS X (mais c'est passé aussi complet que la version Linux).

Je n'ai pas définit de version minimale, hormis GTK qui doit être en version 3.8 au moins. Pour libcpuid, la dernière release remontant à très loin, c'est pour ça que j'utilise la version git.

Après relecture vite fait, la fonction libdmi_fallback devrait être totalement être réécrite, il y a plein de débordement de buffer possible.
De plus tabmb n'est pas totalement initialisé

Normalement libdmi_fallback() est lancé quand on lance le programme sans privilèges. Mais cette fonction ne remplace pas totalement ce que sais faire Dmidecode.
Ça fait longtemps que je n'ai pas touché cette fonction, il faudrait en effet que je la révise (avec d'autres d'ailleurs).
Ça m'étonnerait que tabmb ne soit pas totalement initialisé, j'ai labels_setnull() qui met tous les pointeurs à NULL.

[benjarobin]

my bad alors... De plus je me suis planté, pour libdmi_fallback il n'y pas de débordement possible dans les cas nominaux... Par contre tu devrait faire plus de vérification d'erreur (fgets surtout)

[Xorg]

my bad alors... De plus je me suis planté, pour libdmi_fallback il n'y pas de débordement possible...

Tu dis qu'il y a plein de débordement de buffer possible. J'ai un snprintf() qui utilise une taille maximum de PATH_MAX, le fgets() lui MAXSTR, mais je vois bien la ligne data->tabmb[VALUE][i][ strlen(data->tabmb[VALUE][i]) - 1 ] = '\0'; qui peut être problématique si tabmb[VALUE] est nulle.

Mais l'erreur avec le free(), je vois pas vu qu'il n'y en a pas à cet endroit. J'ignore comment utiliser une backtrace.

[benjarobin]

fgets peut échouer et donc ton buffer n'est même pas remplit. strdup pourrait copier plus que PATH_MAX si aucun caractère nul n'est trouvé.
strdupnullok pourrait retourner NULL, il est préférable d'utiliser xstrdup, qui crash l'application si paramètre invalide ou allocation impossible en expliquant la raison. Pour une application graphique il est bien plus simple, voir c'est la seule solution, dans le cas d'une allocation impossible de planter l'application mais en affichant un message d'erreur avant, c'est le but des fonctions : xmalloc, xstrdup, ...
snprintf peut aussi échouer, mais dans ton cas cela ne devrait pas, mais c'est toujours plus propre de vérifier le retour de toutes les fonctions...
Pour utiliser une backtrace sans les symboles de debug c'est un peu hard

[Xorg]

Bien vu, je ne m'étais pas dit que strdup() risquait de dupliquer n'importe quoi. J'ai rajouté le caractère nulle dans buff avant de dupliquer la chaîne (strdupnullok() permet juste de ne pas dupliquer un NULL).
Normalement je n'ai pas besoin de crasher le programme si une erreur intervient, je préfère qu'il manque une chaîne de caractères plutôt que le programme ne se lance pas du tout.

Si le snprintf() échoue, le fopen() va échouer lui aussi, donc je pense que c'est bon à ce niveau là.

J'ai envoyé 2 patchs, mais une backtrace avec les symboles de debug m'en dirait plus en effet. En tout cas merci pour votre aide.

[benjarobin]

Ta vision des choses n'est pas bonne, si tu ne peux plus allouer de mémoire (cas très rare), il n'y a pas 36 solutions, soit tu peux en libérer et retenter l'allocation, c'est complexe à gérer, soit tu crash l'application car sinon c'est source de bug et d’incompréhension, voir pire une faille de sécurité : débordement de buffer...
Par exemple openssl/libressl gère tous les échecs d'allocations et c'est très complexe à faire et laisse après l'application décider de comment gérer la chose.
Un peu de lecture : http://eli.thegreenplace.net/2009/10/30 ... tions-in-c

[kozaki]

@Xorg

@kozaki Peux tu donne la sortie de :

Code : Tout sélectionner

grep -Ev "^ *#|^ *$" /etc/makepkg.conf
ls -l /usr/bin/cpu-x
nm -a /usr/bin/cpu-x

http://pastebin.archlinux.fr/1593306
-rwxr-xr-x 1 root root 153576 sept. 23 00:43 /usr/bin/cpu-x
nm: /usr/bin/cpu-x: no symbols

Je ne connais que la solution lm_sensors pour les CPU malheureusement, mais nul doute qu'il en existe d'autres.

En cherchant pas trop loin y-a :

Code : Tout sélectionner

cat /sys/class/hwmon/hwmon?/temp?_input

gtk3>=3.8 (cmake >=3.0 si compil), les autres deps sont embarquées (ncurses libcpuid-git pciutils procps-ng)
OK donc chaud avec les "vielles" distros. Normal pour un outil plutôt Desktop.

on doit pouvoir le faire tourner sur toutes les distros GNU/Linux récentes (je peux pas compiler sur les plus vieilles car je n'arrive pas à satisfaire CMake 3.0).

"récentes" = ? (cmake 2.8 sur une Porteus de déc 2014 que j'avais sous la main).

[benjarobin]

@kozaki Attention une partie de ton makepkg.conf ne va pas du tout, l'ordre est important (c'est du bash)
En gros remplace

Code : Tout sélectionner

CPPFLAGS="-D_FORTIFY_SOURCE=2"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
CXXFLAGS="${CFLAGS}"
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

J'ai gardé ton native...

Code : Tout sélectionner

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

Sinon es tu sûre de bien avoir compilé avec !strip debug ?

[Xorg]

gtk3>=3.8 (cmake >=3.0 si compil), les autres deps sont embarquées (ncurses libcpuid-git pciutils procps-ng)

Je ne peux pas descendre en dessous de CMake 3.0, j'ai testé et des variables requises ne sont apparues que dans cette version, donc ça échoue avec CMake < 3.0.

OK donc chaud avec les "vielles" distros. Normal pour un outil plutôt Desktop.

Certes. Mais la version portable étant prête à être exécutée et les dépendances étant incluses dans le binaire (sauf GTK), normalement il doit y avoir moyen de le lancer sur des vieilles "distros". Après je dis ça mais je n'ai pas testé.

"récentes" = ? (cmake 2.8 sur une Porteus de déc 2014 que j'avais sous la main).

Récentes, je ne peux pas donner de date. Je sais que CMake 3.0 n'est pas bien vieux, mais il le faut pour compiler. D'autant plus que si la version de GTK est inférieure à la 3.8, l'interface GTK ne sera pas disponible, mais il reste toujours possible d'utiliser CPU-X avec l'option --ncurses ou --dump.

On insiste : il faudrait que tu nous redonnes la backtrace sans strip avec avec les symboles de debug comme te l'a expliqué Benjarobin.

[kozaki]

@kozaki Attention une partie de ton makepkg.conf ne va pas du tout, l'ordre est important (c'est du bash)
<SNIP>
Sinon es tu sûre de bien avoir compilé avec !strip debug ?

Oh purée! Bien vu et merci benjarobin. Je l(avais éditée pour comparer avec le makepkg.pacnew et... sauvée comme ça, dans la foulée
La suite plus bas

<SNIP>
Certes. Mais la version portable étant prête à être exécutée et les dépendances étant incluses dans le binaire (sauf GTK), normalement il doit y avoir moyen de le lancer sur des vieilles "distros". Après je dis ça mais je n'ai pas testé.

"récentes" = ? (cmake 2.8 sur une Porteus de déc 2014 que j'avais sous la main).

Récentes, je ne peux pas donner de date. Je sais que CMake 3.0 n'est pas bien vieux, mais il le faut pour compiler. D'autant plus que si la version de GTK est inférieure à la 3.8, l'interface GTK ne sera pas disponible, mais il reste toujours possible d'utiliser CPU-X avec l'option --ncurses ou --dump.

On insiste : il faudrait que tu nous redonnes la backtrace sans strip avec avec les symboles de debug comme te l'a expliqué Benjarobin.

GTK3.8 et sinon ncurses, OK.
Ouaip avec

Code : Tout sélectionner

# Usefull debug                                                                  
options=('!strip' 'debug')

maintenant une fois recompilée (mon édition avortée de makepkg.conf remonte qu'à 10 jours mais ça mange pas de pain) même backtrace / core dumped que précédemment.
Il manque peut-être un autre paramètre sur ce système, comme suggéré plus haut.

[Xorg]

Même backtrace avec options=('!strip' 'debug') ? Normalement ça ne devrait pas être le cas.
Où est-ce que tu as mis ça ? options=('!strip' 'debug') ça se met dans le PKGBUILD, à ne pas confondre avec le makepkg.conf qui ressemble à ça (par défaut) :

Code : Tout sélectionner

OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !upx !debug)

Sinon pour en revenir à certaines fonctionnalités qui vous voulez voir dans CPU-X, certaines ont été implémentées via libcpuid (voir la requête 22). J'attends que le développeur s'occupe de fusionner mes patchs, après ça je pourrai m'occuper d'y intégrer complètement dans CPU-X.