|
Auteur | Sujet : [Noyau Linux] Version 6 et des brouettes |
---|
Elbarto | Reprise du message précédent : https://wiki.archlinux.org/index.php/Ccache à priori ça devrait être compatible avec ma méthode de copier-coller du code source vers un dossier, puis création d'un fichier linux-3.1x.tar.gz afin que le PKGBUILD le prenne en compte Message édité par Elbarto le 10-11-2014 à 01:20:12 |
Publicité | Posté le 10-11-2014 à 01:20:05 |
Elbarto | je cherche juste à accélérer la compilation, d'après le site de ccache il n'y a pas d'inconvénients :
sinon d'après le site de gentoo ccache devient utile uniquement lorsque le nombre de revisions restantes à tester descend en dessous de 200 en ce qui concerne le bisect avec git :
Message cité 1 fois Message édité par Elbarto le 10-11-2014 à 05:34:32 |
MysterieuseX Chieuse |
|
Elbarto | le coupable a été identifié
http://git.kernel.org/cgit/linux/k [...] d581c6a0e8 à noter que j'ai aucun périphérique SCSI, j'ai juste que des disques SATA et IDE ( dont un disque IDE branché sur une carte PCIe contrôleur JMicron SATA/IDE jmb363/368 ), peut-être que linux utilise une émulation SCSI pour tous les périphériques SATA/IDE ? je vais essayer de voir si je peux créer un patch qui annule ce patch qui crée le bug Message édité par Elbarto le 11-11-2014 à 00:02:21 |
Elbarto | j'ai crée un patch qui corrige le problème, ça annule le commit défectueux :
|
Publicité | Posté le 11-11-2014 à 02:51:45 |
MysterieuseX Chieuse |
|
Elbarto | les disques sont Ok vu qu'avec le noyau 3.16.7 je n'ai pas de soucis, la bonne santé matérielle a été confirmée par les analyses des infos SMART des disques et par le lancement d'un test de diagnostic par l'utilitaire du fabricant du disque dur,
Message édité par Elbarto le 11-11-2014 à 04:28:00 |
MysterieuseX Chieuse | https://www.kernel.org/doc/htmldocs [...] queue.html
Message édité par MysterieuseX le 11-11-2014 à 07:13:39 |
Elbarto | je ne crois pas que le problème soit matériel puisque : 1) le bug ne se produit que lors du boot de manière aléatoire et uniquement avec le noyau 3.17.x ( ainsi que le 3.18.x ), une fois que l'étape du boot est franchie alors durant la session KDE je n'ai plus du tout le bug 2) un autre utilisateur a le même bug sur le forum archlinux, et lui possède un PC bien plus récent que le mien ( en plus il a un SSD )
https://bbs.archlinux.org/viewtopic [...] 9#p1473209 il a contourné le problème en modifiant une option de son bios ( option "AHCI" activée au lieu du mode "IDE", avec ce mode le bug n’apparaît plus ), et comme moi il n'avait aucun soucis avec le noyau 3.16.4 3) la fonction blk_delay_queue() est appelée à d'autres endroits du fichier scsi_lib.c, donc pas de panique, mon patch ne touche pas aux autres endroits où cette fonction est appelée, ce patch ne fait qu'annuler ce commit douteux, il ne réinvente rien, on se retrouve en fait à l'état antérieur d'avant ce commit 4) Mon PC fonctionne sans soucis depuis un an avec archlinux, c'est uniquement depuis la sortie du noyau 3.17.1 que ce bug est apparu, et si je vais sous windows ( j'ai un multiboot ) il n'y a aucun problème conclusion : ce n'est pas un problème matériel, mes disques vont bien c'est probablement un bug lié à des portions de code qui gèrent le SCSI dans le code source du noyau 3.17.x, un bug qui n'apparait que lorsque des conditions très précises sont réunies ( déjà le bug ne se produit qu'au boot et de manière très aléatoire, à peu près 1 boot sur 10 aura ce bug chez moi avec le noyau 3.17.x, une probabilité d'apparition entre 10 et 20% d'après mes essais pour reproduire ce bug, il faut rebooter comme un malade au moins 10 fois d'affilée pour reproduire ce bug ) reste un mystère : pourquoi nous sommes que 2 à avoir ce bug ? autre hypothèse : la majorité des utilisateurs linux dans le monde n'ont pas encore basculé vers le noyau 3.17.x Message édité par Elbarto le 11-11-2014 à 08:40:13 |
MysterieuseX Chieuse | T'as pas bien compris le pourquoi du comment du bug du coup en fait.
Message cité 1 fois Message édité par MysterieuseX le 11-11-2014 à 08:37:34 |
Elbarto |
tu t'avances trop dans ton hypothèse "matériel défectueux", alors qu'on a aucune certitude, et on sait que mon matériel fonctionne bien avec les noyaux précédents, ainsi que sous windows ( n'oublie pas aussi l'utilisateur du forum anglais archlinux, il a un PC bien plus récent et il a pourtant le bug )
ça sera aux développeurs linux de creuser en profondeur pour résoudre définitivement le bug, en proposant une solution définitive, je ne suis qu'un simple utilisateur qui a eu l'idée d'utiliser la fonction "bisect" de git pour trouver le commit douteux et l'annuler ensuite, si je m'amuse à essayer de me mettre à la place du développeur linux je risque de tout casser
le problème c'est qu'avant ce commit douteux le "sdev->device_busy" a été remplacé par "atomic_read(&sdev->device_busy)", comme si le développeur voulait prendre en compte la fonction atomic_read() ( nouvelle fonctionnalité obligatoire ? ), j'ai regardé l'intégralité du fichier scsi_lib.c et cette fonction atomic_read() est tout le temps utilisée pour accéder à sdev->device, le "sdev->device" tout court sans le mettre dans la fonction "atomic_read()" c'est risqué ( c'est du langage C, les histoires de pointeurs, parfois du code pas très lisible, pas le droit à l'improvisation ici, sinon les kernel panics vont pas tarder à apparaitre si on modifie sans certitudes des lignes ) il vaut mieux attendre que le développeur me réponde et me propose la vraie solution ( je l'ai contacté par mail, j'ai pas encore de réponse, ni de retour sur mon rapport de bug sur le site du kernel ), en attendant je suis donc à l'état antérieur de ce commit douteux, et comme ça a l'air de marcher alors je laisse comme ça Message édité par Elbarto le 11-11-2014 à 09:06:45 |
gee Bon ben hon | Si tu n'as pas de reponse sur ton bug, tu peux toujours poster sur la ML. Sinon as-tu utilise ccache? ou tout de base? Message cité 1 fois Message édité par gee le 11-11-2014 à 12:30:03 --------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
Elbarto | comment faire pour poster sur la mailing list ?
Message édité par Elbarto le 11-11-2014 à 12:57:34 |
gee Bon ben hon | Exactement!
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
Elbarto |
|
gee Bon ben hon | J'ai lu ton message, ca va ca se comprend.
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
gee Bon ben hon | Elbarto tu as un email, faut y repondre pour fixer ce soucis
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
Elbarto | je viens de répondre ( avant d'avoir vu ton message ), j'ai supposé qu'il parlait d'une option de démarrage du noyau pour grub ( scsi_mod.use_blk_mq ),
|
gee Bon ben hon | Un test unitaire c'est bien et meme indispensable.
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
MysterieuseX Chieuse | Je fait du dev sys dans le ... Stockage justement. Le soucis ici, c'est que le matos d'Elbarto est "deprecated", dans le sens ou libide a été merge dans libata (et libsata) et libata (et libsata) utilise libscsi pour les HBA, sauf qu'une partie du support a été passée en deprecated depuis longtemps. A rajouter que libata va être deprecated bientôt pour libsata (qui sera deprecated pour libahci ...). libscsi va aussi disparaitre au profit de libsas+support firmware en userspace+libahci+libsata.
|
Elbarto | matos déprécié ?
Message édité par Elbarto le 13-11-2014 à 19:02:20 |
MysterieuseX Chieuse | Visiblement, ça sert pas a grand chose d'essayer de t'expliquer quelque chose.
|
Elbarto | tu as le don de complexifier les choses de manière XXL, le tout dans une dimension très orientée matériel
Message édité par Elbarto le 13-11-2014 à 21:05:05 |
gee Bon ben hon |
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
Elbarto | suite à une demande d'un developpeur linux j'ai testé des versions de commit antérieures à celui incriminé et sur l'un d'eux ça bogue alors que la modification qu'on suspectait n'avait pas encore été faite,
Message édité par Elbarto le 14-11-2014 à 03:11:45 |
Elbarto | j'ai fait une percée décisive dans la compréhension du bug, lors de mes échanges mails avec les développeurs linux l'un d'eux avait fait une remarque intéressante : - il s'était demandé pourquoi la valeur de la variable globale SCSI_QUEUE_DELAY était fixée arbitrairement à 3 millisecondes, sous-entendu que cette valeur était peut-être trop faible ou incompatible avec certains disques dur pas assez rapides et surtout avec le nouveau changement lié au commit "scsi: convert host_busy to atomic_t", à l'époque personne n'avait rebondi sur sa remarque, je me suis donc mis ce dimanche à explorer cette piste : modifier la valeur par défaut de SCSI_QUEUE_DELAY : - valeur à 5 ms : pas de changement toujours le bug j'ai donc crée ce patch qui impose manuellement la valeur de 40 ms que pour le if() de la ligne 1779 du fichier /drivers/scsi/scsi_lib.c :
cela a l'avantage de laisser la valeur de 3 ms pour SCSI_QUEUE_DELAY dans les autres parties du fichier où la fonction blk_delay_queue() est appelée, ici on utilise la valeur de 40 ms uniquement dans une partie précise du code source du fichier /drivers/scsi/scsi_lib.c, après application du patch je n'ai pas constaté de lenteur de performance au niveau des opérations de lecture-écriture sur les disques durs Message cité 1 fois Message édité par Elbarto le 16-11-2014 à 19:57:14 |
MysterieuseX Chieuse |
|
make install | Je ne pense pas qu'il ait prévu de proposer ce patch (crado) sur la ML pour inclusion, c'est son workaround personnel temporaire, non ?
|
Elbarto | oui il s'agit d'un patch temporaire qui concerne que mon PC, en attendant que les développeurs linux corrigent leur bug, pour les tests smart ce sont les tests courts car le test intégral prendrait trop de temps ( j'ai 5 disques dur au total, 3 modèles SATA et 2 modèles IDE ), je reprécise encore qu'avant le commit suspect ( scsi: convert host_busy to atomic_t ) tout fonctionnait très bien sans avoir besoin de patch correcteur, la réinstallation d'un noyau 3.16.x fait d'ailleurs disparaître le bug, il est donc assez improbable que les disques dur soient devenus défectueux pile au moment de la sortie du noyau 3.17.1
dans le fichier /drivers/scsi/scsi_lib.c la fonction blk_delay_queue() est présente à plusieurs endroits ( 3 reprises ), mon patch ne modifie qu'une ligne ( donc un seul des 3 appels à la fonction blk_delay_queue() sera concerné par la nouvelle valeur de 40 ms, c'est pour le cas de figure "out delay" ), ceci explique probablement pourquoi je n'ai pas constaté de ralentissement des disques dur après application du patch, quand je lance une grande opération de lecture écriture ( comme une compilation du noyau ) ça prend toujours le même temps ( 1h15 ) que ce soit avec ou sans le patch, le boot a aussi la même durée, je reprécise que j'ai restauré les conditions du if() ( annulation de mon premier patch ), ce qui change ici c'est que la valeur de 40 ms donne un peu plus de temps aux disques dur, cette valeur permet peut-être d'éviter que se réalise un cas de figure de type "collision/race condition" ( termes souvent utilisés dans les rapports de bug quand on a l'impression que des éléments se disputent la même ressource, ou que des processus se sont désynchronisés, ça donne alors une situation de blocage ), preuve qu'il y a sans doute une faille dans le nouvel algorithme mis en place depuis le commit "scsi: convert host_busy to atomic_t", faille qui ne se produit qu'avec mon PC et celle d'un utilisateur sur le forum anglais d'archlinux, les seuls points commun que j'ai avec cet internaute c'est la marque de la carte mère ( gigabyte ) et un rapport avec l'IDE ( il était en mode "émulation IDE" dans le bios pour la gestion des disques dur ), ma carte mère ne supportant pas le mode AHCI ( j'ai un contrôleur ICH7 basique qui ne supporte pas ce mode ) et j'utilise 2 disques IDE en plus de 3 disques SATA, une cohabitation entre 2 technologies de génération différente Message cité 1 fois Message édité par Elbarto le 17-11-2014 à 16:09:49 |
MysterieuseX Chieuse |
|
Elbarto |
bug de régression parce que : - aucun problème avec les noyaux 3.16.x et antérieurs c'est pourtant pas compliqué à comprendre que le problème vienne d'un disque dur IDE non compatible avec le nouvel algorithme introduit par le commit suspect c'est une autre histoire, la règle numéro 1 chez un développeur logiciel c'est de ne jamais casser la compatibilité avec le parc matériel existant quand il sort des mises à jour de son logiciel, il y a en effet un contrat implicite qui est passé avec l'utilisateur et le développeur --> sans mention contraire de sa part le logiciel qu'il produit doit pouvoir tourner sur la plateforme matérielle à laquelle il est destiné, à priori je n'ai vu nulle part sur le changelog du noyau 3.17.x que le commit lié au SCSI allait briser soudainement la compatibilité avec certains disques dur/carte mère, bref mon raisonnement est d'une logique implacable
systemd-analyze
la prochaine étape : faire un test en désactivant temporairement les 2 disques IDE, cela me permettra de savoir si changer ces disques par du neuf peut contourner le problème ( au cas où les développeurs linux renoncent à corriger le "bug" ), car le problème pourrait aussi venir du bios de ma carte mère gigabyte, auquel cas le changement de disques ne sera d'aucune utilité Message édité par Elbarto le 17-11-2014 à 20:59:29 |
Ralph- ★ You'll hate me. ★ |
|
Elbarto | les nouvelles du jour : en fait l'algorithme linux qui gère le scsi est quasiment le même malgré le commit suspect ( scsi: convert host_busy to atomic_t ), ce qui a changé dans ce commit c'est que plusieurs variables sont devenues des "atomic_t" comme type de donnée au lieu de "unsigned int", exemple : http://git.kernel.org/cgit/linux/k [...] a0a4e029ee
un peu de lecture : http://www.makelinux.net/books/lkd2/ch09lev1sec1 ça semble avoir un rapport avec le multithread, un mécanisme automatique qu'ils ont voulu implémenter dans le code source lié au scsi dans le noyau 3.17, visiblement avec ma configuration chargée ( 5 disques dur dont 2 modèles IDE ) ça crée des blocages, des situations de "race condition" : http://fr.wikipedia.org/wiki/Situa [...] 3%A9tition mon patch "40ms" permet donc d'éviter cette situation de compétition entre threads mal synchronisés, j'ai eu ensuite l'idée de désactiver le contrôleur IDE de ma carte mère ( afin de désactiver mon disque dur IDE ), et comme je le pressentais ça résout le problème, de 5 disques dur je passe à 4 disques dur ( 3 disques SATA branchés sur la carte mère et un disque IDE branché sur une carte PCIe contrôleur JMicron ), comme si le fait de simplifier ma configuration permet d'éviter que la "race condition" se crée un autre test utile serait de brancher les 2 disques IDE sur la carte PCIe JMicron ( afin de ne pas utiliser le contrôleur IDE de la carte mère ), comme ça j'aurai toujours 5 disques dur dans le PC et cette configuration différente permettra aussi peut-être de contourner le problème Message cité 1 fois Message édité par Elbarto le 18-11-2014 à 22:32:53 |
MysterieuseX Chieuse |
|
Elbarto |
Message cité 1 fois Message édité par Elbarto le 19-11-2014 à 01:01:41 |
gee Bon ben hon |
--------------- "Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!" |
Publicité | Posté le |
Sujets relatifs | |
---|---|
[GNU/Linux/mdk90] Mauvaise version des kernel-headers ....... [résolu] | Le Kernel Linux |
Sécuriser Linux par le Kernel : LIDS ou GRSecurity ? | [Info@ZDNet][Linux]bug kernel 2.4.20 - perte de donnée |
il arrive quand le linux kernel 2.4.20 dans la Debian Sarge ? | [Linux Mandrake 9] Kernel Panic :( |
une carte du kernel linux très impressionnante !! | Linux --> Kernel panic |
Les 'tainted kernel' , 'no license' & cie sous linux.... | Mise a jour d'un kernel, je crois que je vais abandonner linux.... |
Plus de sujets relatifs à : [Noyau Linux] Version 6 et des brouettes |