Reprise du message précédent :
Va faloir que tu compiles une version 64 bit car là c'est clairement problématique. Je ne vois rien qui bloque. Cela dit un de mes programmes compilé en QT aussi me sors la même chose, je vais le recompiler sur cette machine voir si ça change si c'est le cas ça implique d'avoir deux versions, une 32 et l'autre 64 bit.

EDIT: c'est ça après recompilation sur une machine 64bit ça passe... Il te faudra donc compiler à la fois sur une machine 32bit pour du 32bit et une machine 64bit pour pouvoir couvrir tout le monde sinon y a risque de conflit. Peut-être un flag à mettre lors de la compilation vu que j'ai le même problème sur mes logs aussi.

Ce qui m'arrangerait c'est qu'on puisse compiler un binaire 32bit et 64bit sur un même OS. Ca devrait être faisable, non ? Même si j'ai une distrib 32bit ?

L'inverse doit l'être facilement réalisable vu que ça dépend d'option à la compilation, mais compiler du 64bit sur du 32, je sais pas trop.
Je pense qu'il vaut mieux avoir un noyau en 64bit et compiler en 32 si besoin est.  (voir cross-compilation dans google)
Cela dit je pense que ça doit être possible.
Cela dit je dois être dans les seuls à avoir des problèmes avec ton programme sous linux vu que personne n'a remonté le problème.
Le problème doit venir de suse en 64bit. Il doit se mélanger les pédales entre les deux versions 32 et 64.
Je vais voir si le binaire généré quand j'ai recompilé depuis le serveur est en 64bit ou 32...

Je sais que pour compiler du 32/64bit il faut utiliser une option du compilateur + les librairies qui vont avec (cad 32 ou 64bit). Si on peut installer les librairies 64bit sur un OS 32bit, en théorie ça devrait marcher. A moins que non ?

Aucune idée de la faisabilité. Je vais rechercher, mais déjà dans mes dépôt c'est clair que je n'ai rien vu pour compiler en 64bit depuis un noyau 32bit.
Je ne suis pas sûr que ça soit possible. L'inverse l'est par contre.
Sinon je confirme le fait que la compilation de mon prog est bien en 64bit maintenant.

Y a pas énormément d'information visiblement.
Faut chercher avec cross-compilation et target.
Tien voilà des infos:
http://doc.ubuntu-fr.org/tutoriel/compilation_croisee

Visiblement ça a l'air possible mais ça m'a l'air bien compliqué.
Vu qu'il y en a qui crosscompile un noyau 64bit depuis un 32Bit de cette manière:

Du coup je pense que tu peux faire ça toi aussi. Mais ça m'a l'air bien galère tout de même. Alors que depuis un noyau 64bit ça doit juste être une option à passer à g++

EDIT2: enfait si j'ai un truc dans les dépôt pour la crosscompilation visiblement:

Je tenterai ça pour la prochaine version de CSMT Linux. Ca me fait un peu chier de me réinstaller une distrib 64bit juste pour ça

C'est toi qui voit mais bon ça te faciliterais peut-être le futur après.
Mais bon si je suis le seul à avoir un pb sous une distrib 64bit, c'est peut-être juste parce que l'édition de lien vers les lib est foireuses pour la partie 32bit ou qu'il y a un truc qui cloche. (quoi je sais pas )

J'ai le même soucis que Burn2    sous debian 64 bits :
/home/alicia63/cpustress/cpustressmt: error while loading shared libraries: libQtCore.so.4: cannot open shared object file: No such file or directory
 
Le liveCD marche bien ?

Bah normalement il marche oui.

Fouge =>
 
le monitoring intégré (core temp) est pas jour dans ta version . le TJmax des core I7 est de 100+c, il me manque 10°c ^^ .
 
Pour la prochaine release .
 
Sinon les 8 threads sont bien lancés .

Bizarre, je n'utilise pas d'autres valeurs que 85 ou 100, donc soit c'est bon soit il manque 15°C
Peux-tu tester ceci ?
http://www.cpustressmt.com/CPU_Detect84.zip
Il va t'indiquer le Tjmax que je détecte.

 

 
Pourtant dans cpustressmt, tous mes cores sont en dessous de 20°c

Tu parles de CSMT 1.0.4 ou de la dernière beta ?
Si c'est de la beta, ce serait bien étrange
Ca me fait penser que sur Core i7, il n'y a que 4 sondes (Tcore0 à Tcore3, les autres sont dupliquées).

 
CSMT 1.0.4  

lmsensors est installé pour les températures ?

Je te conseille alors fortement de passer à la 1.1.0 beta 9, plus à jour niveau détection de matériel (CPU&Monitoring), affiche/gère jusqu'à 4 T° et est tout aussi stable que la 1.0.4

 
ok je testerai avec

T'avais des trucs qui tournait en // ? Ou c'est un bug ?
87.1% ça fait pas énorme.

priorite basse + progs derriere...

sinon ras sur un autre q6600, le test c est temine normalement sans erreur utilisation + 90%...

je testerais la rev avec le monitoring...

J'ai laissé tourner au bout d'1/2 heure et je l'ai retrouvé comme ça à mon retour
Ça prenait environ 94% sinon...
 
EDIT: doit y avoir un lien avec l'économiseur d'écran (qui n'économise + rien à l'heure des LCD mébon ...)
La gestion de l'énergie est corrompue sur mon Vista on dirait

Si c'est un économiseur 3D (ou autre truc qui bouffe du CPU) c'est possible

Ah
Ça doit être ça alors
Mais c'était bien stable durant 1/2 heure au moins @>94% donc...
 
PS: puis le orange c'est beau fils

Personne a Win7 (Seven) par hasard ? Ca devrait marcher, mais on sait jamais.

J'ai en machine virtuelle sans aero si ça peut t'aider....

Sans aéro ce n'est pas un problème. Par contre, avec la virtualisation, le monitoring risque de ne pas marcher.
Tout test est bon à prendre

Bon alors:
Machine de test: X2 4850E:  
Nb de cores vu par Seven virtualisé: 1
 

 
Mais pour le % je viens de voir que c'est l'indexation qui bouffe pas mal de cpu visiblement... Je vais retenter et voir si tout se passe mieux sur une minute...
C'est peut-être le pb avec l'écran de veille plus haut aussi...
 
EDIT: par contre la détection de la fréquence ne semble pas se mettre à jour.
 
EDIT2: c'est ça, si je force mon cpu à 1GHZ cpustress me le détecte toujours à 2.5ghz
Je pense que ça vient de la machine virtuelle vu que seven le voit aussi à 2.5ghz dans le paneau de contrôle. Sans doute un mauvais retour de virtualbox.
Je vais comparer avec cpu-z

Bon je confirme ça vient bien de la virtualisation:
cpu-z voit aussi 2.5ghz même si je force à 1ghz.
 
Sinon c'est marrant de voir dans cpu-z un X2 à un core et une mainboard intel i440 comme support lol

Et faudrait que je MAJ la détection de l'OS (il voit Vista).

Version Windows 1.1.0 RC1  
 
Changements :
- correction du % CPU > à 100% (cas rare)
- meilleure détection des caches L2 des CPU Intel 45nm
- meilleure détection de la fréquence des CPU Intel Penryn
- ajout de la terminologie 'hexacore' et 'octocore' pour les CPU à 6 et 8 cores
- meilleur gestion du N° des cores (pour le monitoring)
 
Télécharger CPU Stress MT 1.1.0 RC1 : Format ZIP
 
Tests qu'il y a à faire :
Vérifier la détection du matériel et le monitoring sur XP/Vista/Seven.
Vérifier le bon support d'Everest 5 sorti il y a 2 jours.
 
En cas de problème :
http://www.cpustressmt.com/CPU_Detect85.zip
 
 

je test sur mon core i7 , et sur seven si j'ai le temps demain .

Erreur détecté avec mon proc non O/C et un Rad de 360
Aucun pb sous OCCT.

Sur le i7, tu auras toujours des petits pb de détection.
Le support complet de ce CPU est prévu dans la version qui suit, dès que celle-ci est stable.
 

Un rad de 360 ?
Il te détecte l'erreur au bout de combien de temps ? Erreur sur fond rouge ? Quelle T° ?

je prends et je teste çà dès que je peux.
je viens de récupérer la v5 d'everest justement.
@+  

 
ok pour le monitoring.
en ce qui concerne everest, j'ai dû ouvrir everest en premier au premier lancement de CSMT pour qu'il "capte" qu'everest était installé et que je puisse modifier les valeurs à monitorer.
 
au 2° lancement, no soucis.
 
everest se lance automatiquement au lancement de CSMT.
 
je ferais un test d'une heure demain pour voir
 
edit : ras
 

 
testé 15min a priori je n'ai pas vu de bug . Je testerai plus longtemps dans la semaine sur XP et Seven .

Merci pour les retours

Pour Everest 5, tout comme les versions précédentes, il faut penser à activer le partage mémoire (c'est dans les options d'Ecerest). Et seule une "vraie" installation (version EXE et non ZIP) permet à CSMT de le lancer automatiquement. Pour la configuration, la 1ère fois, tout doit être effectivement fait à la main.

Retours d'avec Q9550 en cours de semaine prochaine

Ras pour la nouvelle version, je n'ai pas détecté de "bugs"
 
Merci Fouge.

c'est normal que ça ne détecte pas le cache L3?
 
hé oui, je suis de retour  
 
EDIT: ben en fait il me trouve 8x256Ko au lieu de 4x256Kb pour mon L2 aussi
je précise que c'est l'i7 920 de ma config avec la 1.1.0RC1
 
j'irais voir si c'est pareil sous linux mais comme les méchants de superpi ils veulent cpu-z à côté pour bencher ben j'me retrouve sous vista...