Reprise du message précédent :

En soit, ce n'est pas forcément vrai.
 
Si le précedent algorithme/code est plus laxiste que le nouveau, il peut ne pas générer le problème.
(Je ne dis pas que c'est le cas pour ton soucis mais je pense que ca reste plausible).
 
Sinon suivre ton soucis m'a donné la malchance, maintenant je suis aussi en train de débogger du code, Mesa pour moi, pour trouver ce qui ne fonctionne pas chez moi

un souci de quel ordre avec mesa ?
 
j'ai eu aussi des problèmes avec mesa, ce que je fais en général c'est un git bisect puis un rapport de bug sur le site de mesa3d en précisant le "first bad commit", en espérant que ça suffira pour que les développeurs corrigent le bug,  
 
en identifiant le commit qui a généré le problème tu peux alors tenter de créer un patch "workaround" de manière a annuler ce qu'a fait le commit quand c'est possible

J'ai des soucis avec nine, et apres avoir longuement parler avec un dev, il manque une fonction dans leur code, et on m'a gentillement proposer de le faire moi-meme
 
Le bisect avec nine n'est hélas pas aussi simple qu'avec le reste, je l'ai appris hier

j'ai finalement trouvé le fin mot de l'histoire pour mon problème de blocage aléatoire au boot avec le noyau 3.17,

la méthode utilisée :

j'ai enlevé tous les disques dur et le graveur de DVD, puis je branche un à un les élements jusqu'à ce que le bug apparaisse :

1) je commence avec un seul disque dur sata connecté sur la carte mère,  celui où est installé archlinux : pas de bug

2) je branche ensuite un second disque dur sata : toujours pas de bug ( nous avons donc à ce stade 2 disques dur sata connectés sur les 4 ports sata de la carte mère )

3) je branche un troisième disque sata : toujours pas de bug

4) je branche un disque dur IDE sur le port IDE de la carte mère : pas de bug, nous avons maintenant 4 disques dur connectés ( 3 sata et 1 IDE, tous sur les connecteurs de la carte mère )

5) je branche un autre disque IDE sur le port IDE du contrôleur JMicron PCIe : toujours pas de bug, nous avons donc 5 disques dur connectés ( 3 SATA, 1 IDE sur la carte mère, 1 IDE sur la carte  PCIe JMicron ), à ce stade on peut donc innocenter tous les disques dur, même les 2 IDE

6) je branche le graveur DVD Sata sur le port SATA de la carte mère ---> le bug apparaît ! Le coupable est trouvé, ou plutôt les coupables, car la 7ième étape va le démontrer :

7) je branche le graveur DVD Sata cette fois sur le port SATA de la carte PCIe JMicron JMB363/368 ( qui possède 2 ports SATA et un port IDE ), le bug disparaît ! Le graveur SATA est donc innocenté ( un modèle Liteon  iHAS124  C )

conclusion : le bios de ma carte mère gigabyte GA-P31-DS3L possède un bug quand on mélange 3 disques dur SATA et un graveur sata sur les 4 connecteurs SATA que possèdent ma carte mère, bug qui ne se produit qu'avec le noyau 3.17,

la solution est donc très simple : brancher le graveur SATA sur le port SATA de la carte PCIe JMicron, j'ai effectué une trentaine de reboot consécutif et le bug n'est jamais apparu avec le noyau 3.17 et 3.18, j'ai toujours mes 5 disques dur connectés ( donc au total 6 périphériques si on compte le graveur )  

il y a probablement un bug dans le bios ( version F10A, le dernier disponible qui date de 2008 ) au niveau de la gestion de la latence, des timings quand on mélange disques dur sata et graveur, quelque chose de très subtile qui n'a été mis en évidence qu'avec le noyau 3.17,

ceci dit c'est peut-être aussi le noyau 3.17 qui est fautif si un certain standard/respect des latences n'a pas été respecté par le commit qui a introduit ce bug, il se peut que gigabyte avec son bios ait respecté un certain standard dans le pilotage du contrôleur SATA ICH7, et que le noyau 3.17 emploie une méthodologie ( le type de données "atomic_t" ) inappropriée pour acceder aux périphériques SATA ( ça casse la compatibilité avec certaines configurations matérielle comme la mienne, matos qui est pourtant en parfait état de marche )

Cette investigation de malade    
 
Et on a toujours pas un nom à mettre sur la case coupable  

en tout cas j'ai identifié les 3 éléments déclencheurs du bug :

- graveur dvd SATA de marque liteon modèle "iHAS124  C" ( mais ça concerne peut-être aussi les autres marques de graveur dvd sata ) branché sur un port sata  d'un contrôleur ICH7

- carte mère gigabyte GA-P31-DSL3 ( peut aussi concerner les autres cartes mère gigabyte si le bios a été conçu sur le même moule, du award par exemple )

- noyau 3.17 ( plus précisement le noyau à partir du commit 74665016086615bbaa3fa6f83af410a0a4e029ee "scsi: convert
host_busy to atomic_t" )

il suffit donc d'éviter un de ces 3 éléments déclencheurs pour ne pas avoir le bug, tous ceux qui ont du matériel relativement récent sont donc épargnés par le bug, ainsi que ceux qui utilisent une distribution linux où le noyau par défaut n'est pas encore du "3.17" ( la branche "stable" de debian par exemple )

Un détail, mais je ne comprend pas pourquoi tu parles d'IDE, au lieu de PATA.

Sinon bon travail, et bonne chance pour la suite!

Sinon quid de seulement le graveur et le disque avec Arch Linux? As tu le bog aussi?

 
le connecteur est de type IDE, donc disque IDE
 
c'est comme ça qu'on appelle les disques qui se connectent via le connecteur IDE
 

 
oui j'ai le bug dès que le graveur est connecté sur un port sata de la carte mère et qu'un disque dur sata est connecté aussi sur un des 4 ports sata de la carte mère,
 
par contre dès que le graveur est connecté sur le port sata du contrôleur Jmicron ( carte PCIe ) là il n'y a plus de bug

 
Comme tu dit gestion timing a la barbare dans le BIOS, soit du lecteur DVD, soit de la mobal, mais je pense pour un mode mal paramétré dans le lecteur, essaye de modifier et j'y tiens, via HDPARM, le mode (y'a de très bon tutos que j'ai déjà postée).
 
Le noyau 3.17 n'est pas coupable et stop de m'attaquer directement, parce que je suis pas admin réseaux, mais admin sys, et je fait principalement de l'archi sur solutions stockages pour le HPC, les branches du kernel niveau stockage j'y participe (ainsi que bus et timing CPU/code x86), quitte a se que sa passe pour du bash, la prochaine fois commence par faire des investigations sur ton matos avant d'aller fouiller dans le software. (je rajouterai bien un truc, mais chez HP t'as fait marré du monde).

Ouais, c'est moche, mais tant que ça fait rire, hein.
 
PS: on revert des commits, qu'il viennent de chez Intel ou ailleurs au passage.

Mais jamais d'HP, surtout pas du groupe de Mme!  

Oui enfin là, revert un truc qui :
-permet aux archis autre que le x86 de fonctionner
-permet aux environnements virtu de fonctionner
-est carrément clean au niveau du code
-est "dans les règles" vis à vis des conventions ...
 
Et c'pas mon groupe.

ce n'est pas vraiment ce que pense le développeur linux qui s'occupe de la partie scsi du code source, il dit ceci dans la mailing list concernant mon problème :

en gros quand quelque chose fonctionnait parfaitement avant une mise à jour logicielle alors c'est probablement cette mise à jour le fautif,

dans mon cas il y avait déjà beaucoup d'indicateurs qui penchaient vers  cette hypothèse :

- fonctionnement nickel avant l'apparition du noyau 3.17, pas de soucis aussi sous windows
- matos en bonne santé, les outils de diagnostics ( smartmontools ) n'indiquaient aucun problème

il me propose de tester un patch :

j'attaquais pas, je pense simplement que tu as une logique de réflexion trop orientée "matériel" sans doute à cause de ton métier ( tu vois des disques tous les jours, l'esprit tout le temps concentré sur ce domaine des disques ), ce qui fait que tu as tendance à foncer tête baissée vers une seule hypothèse "matériel" ( pour schématiser quand je lis tes messages c'est du genre "ouah attention ton disque il est tout pourri, il va claquer, c'est ce que je vois tous les jours dans mon taff des disques qui vont claquer, c'est pas la faute du noyau, crois moi il faut que tu changes de disque vite avant qu'il soit trop tard !"     )

ça manque de prudence dans ta démarche de résolution de problème ( et je trouve que tu as parfois un style pas très cordial dans tes messages, tu écris d'une façon qui peut énerver l'interlocuteur, avec des phrases bourrées de termes techniques mais qui parfois n'ont pas de sens ), comme disait Ralph c'est très courant les commits qui introduisent des bugs de régression, faut pas voir tout de suite une panne du matériel,

tu gagnerais à adopter une démarche plus prudente la prochaine fois, bien prendre en compte tous les paramètres du problème, la culture du "doute" c'est ce qui fait aussi la force d'un bon informaticien, avoir trop de certitudes, les œillères c'est pas bon ça,

d'ailleurs tu as presque réussi à me faire douter de l'état de santé de mes disques dur , mais le test hier a fait lever ces doutes

j'ai testé le patch de test proposé par le développeur linux, ça marche, le bug a disparu  
 
il va sans doute trouver la solution définitive, je lui ai donné aussi une autre hypothèse suite au message d'un utilisateur sur le forum anglais d'archlinux :
 
- le bug semble se produire lorsqu'on utilise pas le mode "AHCI" dans le bios, cet utilisateur a remarqué qu'avec le mode "IDE emulation" du bios alors le bug se produisait sur son PC ( une carte mère beaucoup plus récente que la mienne : gigabyte Z68P-DS3 prévue pour les processeurs intel comme le i7 ), mais s'il activait l'option "AHCI" alors le bug disparaissait,
 
cet utilisateur avait aussi un graveur DVD sata branché sur les ports sata de sa carte mère ( l'un des facteurs déclenchant du bug ),
 
de mon coté comme ma carte mère est assez ancienne elle n'a pas d'option AHCI dans le bios ( le contrôleur sata ICH7 ne supportant pas ce mode ), ce qui fait que tous les périphériques SATA semblent être traités comme de l'IDE ( dans le bios je vois la mention "IDE 0 channel : nom du disque dur sata" )

 
On va faire simple : je suis autiste asperger, ça ira plus vite que de te faire une dissertation.  
Maintenant, si j'affirme une chose, c'est que soit j'ai déjà eue le cas, soit j'ai reproduis le bug et j'ai déjà trouvée la cause, et je te donne la solution en direct, ça sert a rien de rentrer dans les détails, parce que si je te sort que l'ICH7 n'est qu'un HBA basique a laquel intel a rajouter une interface soft intégrée dans le noyau et que suivant la méthode de compilation (msft or intl) du BIOS ça peut foirer les appels spinup/spindown et la gestion du cache des DD voir la detection du bon mode PIO/DMA, tu va me dire que non, c'est pas possible, que ça peu pas faire tant de dégâts, que sinon tu l'aurai vue avant. Sauf qu'avant, il y avait des workaround mis en plus justement pour éviter ce genre de problèmes sur du matériel "mainstream" mais que passé une certaine période, le mainstream, on s'en fou, se qu'on cherche, c'est la compat avec le maximum de matériel, et que maintenir une branche spécifique pour un matos spécifique, c'est un peu difficile de tout vérifier.
 
Là, on arrive dans le cas typique où ton matos est bien pris en charge, mais le BIOS se plante lamentablement au niveau du POST et passer les informations au kernel. Du coup, le kernel arrive pas a spinup et il rentre dans une boucle infinie.

 
http://www.youtube.com/watch?v=hkDD03yeLnU

ou quelqu'un qui n'aime pas faire son auto-critique  

en tout cas le développeur linux de la mailing list qui a la patience de s'intéresser à mon problème semble beaucoup plus zen, pas de discours alarmiste sur le matériel, il cherche plutôt à corriger tout ça par un patch afin d'améliorer son code source et à continuer à assurer la compatibilité avec tous les types de PC, qu'il soit vieux ou récent ( je rappelle qu'un forumeur anglais a rencontré le même bug alors qu'il a un matériel bien plus récent que le mien )

Une astuce hors sujet:
 

 
etc...
 
On a bien compris que tu es une femelle, et on l'accepte, mais le verbe avoir lui, il s'en fiche.  

Sinon Elbarto, je crois que je gagne notre concours, mon patch va bientot arriver sur Mesa, alors que toi ce n'est pas encore fait
(et puis ca ne sera pas ton patch de toute façon )

 
Je parlais de la partie par exemple USB, qui est pas mal supporté par Intel en terme de commit, il y a déjà eu des 2/3 reverts dans une version y pour une 3.x.y alors que le code est passé par une review auparavant.  
 
Pour aller dans ton sens, c'est clair qu'ils testent au maximum pour le mainstream, mais ça ne veut pas dire qu'ils ne peuvent pas se taper des régressions et ou un support incomplet via le patch (exemple simple, le premier commit log du 3.17.3 sur xfs) juste parce que l'erreur est humaine (même avec des reviews) et qu'il est aussi de bon ton de dire parfois "oui j'ai merdé" que ça soit sur le code et/ou la méthodologie de la recherche de bug. Je ne connais personne qui peut dire "je ne me suis jamais planté" même dans son domaine de prédilection.
 
De plus si le patch en question permet un retour à la normale, au final, vous risquez de rire jaune chez HP, autant on peut remettre en cause des méthodologies venues de l'espace, mais la, avoir des problèmes avec un changement de noyau, que le matos soit vieux ou non, à moins d'être EXPLICITEMENT écrit, c'est pas dans les habitudes du Kernel de balancer un support aussi "commun" de contrôleur.

Fais gaffe mec, ils vont aussi rire de toi chez HP maintenant.

ils sont rapides je crois chez mesa pour valider un patch, je me souviens que j'avais crée un rapport de bug il y a 3 ans sur le fait que leur version de mesa posait des problèmes sur une vieille radeon 9000 AGP ( lancement de blender impossible ), une fois le patch mis au point ça été très rapidement intégré à la version suivante de mesa,

en comparaison ça peut parfois prendre du temps à être validé définitivement un patch sur le bugzilla du kernel, ainsi ça fait un mois qu'un patch correcteur a été mis au point pour résoudre un bug quand on utilise une carte contrôleur PCIe Sata/IDE JMicron JMB363/368 et qu'on veut utiliser la mise en veille du PC ---> au réveil du PC la carte JMicron ne répond plus et les disques rattachés à ce controleur ne sont plus disponibles,

la faute à la fonctionnalité "async_suspend" qui pose problème sur les cartes PCIe JMicron, le patch correcteur consiste à désactiver cette fonctionnalité pour les cartes contrôleur Sata/IDE JMicron, voici le patch que j'utilise et mis au point par un développeur linux :

ce patch n'est toujours pas présent dans la version 3.18rc5 du noyau linux

Putain Elbarto cette patience pour trouver un bug du kernel, impressionant

Ce n'est pas faux en effet!

Elbarto, ca c'est termine comment ton histoire ?
 
C'est toi qui est a la base de tout ce merdier: http://www.phoronix.com/scan.php?p [...] px=MTg1MDc ?

le bug que tu as mis en lien semble différent, chez moi c'est uniquement lié à la combinaison "périphériques lents type graveur" mélangés avec des disques dur  sur des ports SATA non AHCI ( ce dernier point est important ), le démarrage peut alors se bloquer tous les 5 à 10 boots lors de l'activité de systemd,
 
le développeur linux a crée un patch qui résout le problème mais il ne semble pas définitif, et il a refilé la patate chaude au groupe "linux-ide", depuis j'ai pas de nouvelles, je ne sais pas si le patch sera intégré au noyau 3.18,
 
au total 3 utilisateurs ont ce problème ( je m'y inclue dedans ), 2 ont une carte mère très récente, le point commun c'est qu'ils utilisent un graveur SATA, l'option "AHCI" pas activé dans le bios et parfois l'utilisation d'un graveur IDE

En même temps, se trimballer des antiquités en IDE

je fais partie de ceux qui montent leur PC pièce par pièce ( je n'achète pas de PC pré-monté ), donc inévitablement il y des éléments qui restent au fil des années tant qu'ils fonctionnent, et comme je ne suis pas un gros consommateur de données alors il n'y a aucune raison d'acheter du neuf juste pour le plaisir d'avoir du neuf

sinon concernant mon bug un responsable a enfin été officiellement rattaché à mon rapport de bug aujourd'hui ( Tejun Heo ), le titre a même été modifié :

https://bugzilla.kernel.org/show_bug.cgi?id=87581

jusqu'ici le problème avait été uniquement traité via la mailing list officielle du noyau linux,

à noter la sortie officielle du noyau 3.18 malgré le fait que tous les feux soient au rouge ( des bugs gênants dans le 3.17 n'ont pas été corrigés ) :

http://www.developpez.com/actu/789 [...] sion-3-17/

pour moi la dernière vraie bonne cuvée reste le noyau 3.15,

car le 3.16 j'en garde un mauvais souvenir à cause du bug des partitions fuse ( kernel panic aléatoire si on utilise virtualbox ), pour le 3.17 il y a ces histoires de blocage aléatoire,

et ce 3.18 qui va hériter des méchants bugs non corrigés des versions précédentes

Faudrait MAJ le titre du topic d'ailleurs

http://kernelnewbies.org/Linux_3.18
 
3.18 out

Meme le 3.18.1

http://lkml.iu.edu/hypermail/linux [...] 04059.html  

Le screen avec "Linux 4.1.15" provient de quel film Terminator ?

Salvation :

donc on peut faire un kill T-800 ? Trop simple

Je pose ça là : https://git.kernel.org/cgit/linux/k [...] 6d7ae6ee76

4.00 dans le titre du topic
Zéro zéro ? Wtf ?

4.0.0 .
Sinon, ça fait freezer les pilotes Nvidia (349.**).

Non plus