Reprise du message précédent :
http://images2.hiboox.com/images/4707/afg8osdm.png

J'avais une beta 5 en préparation, mais j'ai dû partir tout le WE précipitamment (j'avais complètement oublié ).
C'est donc prévu demain soir.
 

Bizarre, t'as un screen avec la version 'a' ou 'e' par ex ?
 

Ok, tu confirmes certains feedback. La prochaine beta de CSMT intègrera la dernière version de WinRing0 (bug d'erreur de chargement corrigé).
 

Pour info, la T° donnée est la T° moyenne au cours du test, et entre parenthèses les valeurs min/max.

euh non, mais il me semble qu'il y avait la temp

Si j'ai le courage je change le proco et je boot sur 2003 pour voir stu veux (le soucis c'est surtout d'arriver a booter avec le quad)

Sortie de la version 1.1.0 beta 5  
- passage de Code::Blocks à la build 4630
- driver WinRing0 qui passe en version 1.0.10 (bug de l'erreur de chargement résolu)
- modules de monitoring SpeedFan, Everest, MBM5 et Systool plus fiables
- correction de la détection du Tjmax des CPU LGA771 (Xeon)
- ajout de la durée "30 minutes" (avec message prévenant qu'1h minimum est conseillé)
- compatibilité avec l'UAC de Windows Vista (plus besoin de faire "Run as administrator" )
- taille de l'executable réduit de 25%
 
Télécharger CPU Stress MT 1.1.0 beta 5 : Format ZIP
 
Tests qu'il y a à faire :
- tester un peu tout, surtout ce qui est indiqué dans le changelog
- en cas de pb de chargement de Winring0 ou de T° invalide avec Intel Core Temp / K8 Thermal Sensor, veuillez tester ceci :
http://olivier.fouge.free.fr/CPUSt [...] tect78.zip
 
Toutes les config (CPU/OS) sont les bienvenues

comme d'hab, je prends.

Test lancé sur Xeon Woodcrest sous XP64 (au passage detecté comme Windows 2003 )
Contrairement aux precedentes versions, le 1.1.0 b5 se plante au bout d'un petit laps de temps, aleatoire, generalement entre 2 et 10 min
 

 
 
Et j'en profite pour poser une question.
Sur ce lien, comment interpreter la valeur Max Temp ?
Il est marqué 49-65°C. Est-ce une fourchette de valeurs, ou est-ce la valeur max admissible pour le core 0 d'une part, et le core 1 d'autre part ?
 
Je pose la question surtout parceque sur les dualcore Intel que j'ai eu en main, la temp de chaque core est identique, et sur ma plateforme X2 (celui du lien), le core 1 est toujours beaucoup plus chaud que le core 0 lors d'une charge soutenue. Parfois la difference est de 7°

Merci pour ton feedback
T'es sûr qu'avec la beta 4 ça n'arrive pas du tout ? T'as juste fait 1 essai ou plusieurs ?
Si tu tests la beta 5 en désactivant le monitoring (dans les options), ça plante toujours ?
Es-tu sûr de la stabilité de ta machine (avec CSMT 1.0.4 par ex) ?

edit: XP64 est basé sur le noyau de 2003 (NT 5.2) d'où la confusion
Pour ton autre question je ne sais pas.

Je parlais par rapport à CSMT 1.0.4 (pas testé les betas) qui tourne comme un charme sur la becane (elle a pris un 12 heures d'affilé sans broncher la derniere fois que je n'avais rien de mieux à lui faire faire   )
 
Le plantage de la b5 est survenu lors de toutes mes tentatives, mais à des stades differents, pour le moment entre 2 et 10 min.
Je vais essayer sans le monitoring
EDIT : deja 40min sans pb, sans le monitoring. Je vais le laisser encore plusieurs heures et referais une session avec monitoring

Et je suppose que le monitoring choisi est "Intel Core Temp", celui qui est automatiquement sélectionné lors du 1er démarrage.
Je vais faire une version de debug pour voir d'où ça vient...

edit: "Exporter les valeurs dans un tichier TXT" n'était pas coché ?

Ca marche parfaitement chez moi  

 
idem

jovial> J'ai pas pu reproduire ton problème sur un C2D avec monitoring. J'ai fait un test d'1h puis un test de 20min et RAS.
Je vais essayer de faire une version de "debug" qui me permettra (je l'espère !) de découvrir d'où vient ton plantage. La bonne nouvelle c'est que t'arrives a reproduire le problème assez facilement

Impossible de reproduire le pb aujourd'hui ...
Ca devait etre un process en memoire qui causait le soucis

j'attends que ça de le tester sous Linux    
Burn2 aussi d'ailleur

"Oué c'est pas faux!"
 
et non c'est pas linux que je n'ai pas compris, mais plus attendre  

J'aurais dû préciser "toutes les versions de Windows"  
 
Sinon, pour la version Linux, là où j'ai bloqué, c'est au niveau de la compilation de l'algo de Prime95 avec GCC.
Et depuis je m'y suis pas remis...

Tu veux que je tente de le compiler? Si on peut t'aider t'hésites pas!

Si tu veux
Le code source est dispo ici : http://www.mersenne.org/source.htm

Oki je testerais ça dès que je peux.

Ah oui effectivement c'est hard pour compiler Y a po de makefile ni rien Avec une partie du code en assembleur
Je retesterais.
Je retente je pense que j'ai une croutade j'ai rien dans le code mais vu que j'étais sous windows en ssh avec putty et que j'ai fais un wget le problème venait peut-être de là. je retente.
Bon j'ai le code cette fois. C'est bien chaud quand même pour compiler et y a po d'info
La seule info que j'ai trouvé c'est ça:
http://www.mersenneforum.org/showthread.php?t=3500

Moi j'ai pas mal avancé par rapport à la dernière fois.

Jusqu'ici j'utilisais VS2003 pour compiler la DLL de test (basée sur l'algo de Prime95) et tout le reste du projet sous Code::Blocks (avec GNU GCC). Pour faire cette DLL, je faisais un "nmake /f compile" dans le répertoire gwnum pour obtenir le fichier gwnum.lib. Et j'ajoutais ce fichier dans un projet DLL classique de Visual Studio. Cette DLL n'a pas changé depuis la 1ère version officielle de CSMT.

Là, j'essaie de créer cette DLL sous Code::Blocks (avec GNU GCC) ce qui me permettra d'unifier mon environnement de programmation, d'autant plus que je l'utilise aussi sous Linux
J'arrive à obtenir le fichier gwnum.lib via la commande "make -f makefile" dans le répertoire gwnum (ce que je n'avais jamais fait jusqu'ici). Mais impossible de créer une DLL à partir de ça. J'ai 34 erreurs (identiques) dont j'ai aucune idée du comment les corriger
Quand j'aurais terminé ça, le portage sous Linux se fera simplement (enfin j'espère).

edit: si ça peut t'aider à m'aider...

Tu aurais l'erreur particulière?
Heu je lance make pour voir

EDIT: make réalisé sans problème chez moi pour cette librairie...

Je t'envoie la lib compilée si tu veux?

EDIT: j'ai du mal comprendre ou est ton problème. En gros tu as la lib après avoir fait le make  (comme moi quoi) et tu voudrais en faire une dll??

EDIT2: une simple .lib ne te suffit pas? quel est le problème en gros?

La lib je l'ai déjà. Mais cette lib toute seule ça fait pas grand chose
Il y a donc la "boucle principale de calcul" qui utilise cette lib. Et moi, cette boucle de calcul, je la met dans une DLL qui est appelée par CSMT.
Avec Visual Studio, tout va bien : je fais ma p'tite DLL avec la fonction de test, en ajoutant gwnum.lib dans les dépendances (éditeur de lien).
Sous Code:Blocks (GCC), je fais la même chose (enfin, son équivalant) mais j'ai 34 erreurs de ce type :
gwnum\gwnum.lib(gwnum.o):gwnum.c: (.text+0x152b)||undefined reference to `_gwinfo1'
Erreur banale, mais aucune idée d'où ça vient et comment corriger ça. Normalement, ça aurait dû marcher

http://www.developpez.net/forums/s [...] p?t=423892
il faut que tu link vers _gwinfo1 après après j'espère que ça pourra t'aider

donc en rajoutant -L vers la lib en question ça devrait être bon
Donne nous des nouvelles

La lib, je l'ai déjà ajouté. C'est pour ça que je comprend pas ce qu'il lui manque.

En rajoutant exactement la même? un peu comme l'exemple quoi.

Il y en a pas 36, j'utilise celle créée par le makefile. Et je fais confiance au makefile.

Oui mais le truc c'est qu'il se peut que cette lib utilise d'autre lib du système (à priori une autre) et qui soit du genre _gwinfo1.lib.

Exactement comme dans l'exemple que je t'ai passé dans le lien.

Sauf que gwinfo1 (et les autres) c'est dans la lib créée.

Effectivement c'est plus problématique

Vire tous les fichiers .o et lances la commande "make -f makefile".
Et là, la création du fichier lib échoue. Apparemment, il faut que objcopy supporte le format coff.  
Après ça, la création du fichier lib devra se faire et être valide pour la suite.

Oui j'avais remarqué ce problème. Quand j'ai fais make clean, je pouvais plus refaire un coup de make

Faut recompiler le objcopy pour ajouter le support du format Coff
Pour les fichiers .o ils sont peut-être valides sous Linux. En tout cas, sous Windows, avec MinGW ça passe pas. J'aurais bien voulu me débarasser de Visual Studio sur ce projet...

Tu me parlerais en Biélorusse sur le début je comprendrais pas plus
 
En tout cas si je prend les sources linux que je fais un make ça marche. Pis si je fais un coup de make clean ça veut plus recompiler car doit manquer le objcopy oui.

En fait le "objcopy" fait partie des binutils de GCC. De base il ne supporte pas le format coff (nécessaire pour transformer les fichier .obj en .o). Faut donc recompiler le "objcopy" en y ajoutant le support du format Coff.
Mais bon, j'sais pas comment on fait

Je sais pas non plus alors je t'offre une pause déconnade en mp

EDIT: en relation avec l'info bien sur

youhou !!
enfin

   On peu aider???

ouaip, j'testerai bien sur ma ubuntu toute neuve !

La release! la release !

Je ne sais pas si ça gère bien le multithread (1 seul thread de test, ça marche ).
Le calcul du % CPU est fictif : 0% quand ça tourne pas, 100% quand ça tourne.
Je n'ai pas (encore) réussi à récupérer le code retour des thread : donc j'ai aucun détail sur le pourquoi de l'arrêt du test. Du coup, c'est une gestion assez binaire : ça tourne = ok, ça tourne pas (alors que ça devrait) = erreur de calcul (même si en fait j'en sais rien du tout, ça peut être pas mal de choses).
Et également, pas de monitoring, pas de son, pas de shutdown, etc.

Juste l'algo de test basique, théoriquement multithread.
Je mettrai à dispo la version ce soir. Par contre faut une version récente de Qt4 (celle de Ubuntu 7.10, cad 4.3.2 ?).