Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2586 connectés 

 

 

 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  172  173  174  ..  179  180  181  182  183  184
Auteur Sujet :

[Noyau Linux] Version 6 et des brouettes

n°1368236
Elbarto
Posté le 10-11-2014 à 01:20:05  profilanswer
 

Reprise du message précédent :
j'ai trouvé cette info sur ccache et makepkg.conf :

 

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
mood
Publicité
Posté le 10-11-2014 à 01:20:05  profilanswer
 

n°1368237
Mysterieus​eX
Chieuse
Posté le 10-11-2014 à 05:00:57  profilanswer
 

Utilisez surtout pas CCACHE bande de malheureux, si c'est un problème du processeur, sous CCACHE vous ne vous rendrez pas compte d'où il vient. Règle numéro 1 en debug : on utilise commence par virer CCACHE et toutes les options de compilation exotiques du genre LTO etc ...

n°1368239
Elbarto
Posté le 10-11-2014 à 05:10:12  profilanswer
 

je cherche juste à accélérer la compilation, d'après le site de ccache il n'y a pas d'inconvénients :

 
Citation :


Is it safe?

 

Yes. The most important aspect of a compiler cache is to always produce exactly the same output that the real compiler would produce. This includes providing exactly the same object files and exactly the same compiler warnings that would be produced if you use the real compiler. The only way you should be able to tell that you are using ccache is the speed.

 

ccache has been coded very carefully to try to provide these guarantees. However, if you experience any bugs, please report them.

 

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 :

 
Citation :


Kernel compilation

 

In compiling the kernel, ccache doesn't help at all for most cases. If you want to bisect the kernel, then it will take effect only when the number of remaining patches fall below about 200.

Message cité 1 fois
Message édité par Elbarto le 10-11-2014 à 05:34:32
n°1368252
make insta​ll
Posté le 10-11-2014 à 11:27:27  profilanswer
 

le make install sur le kernel c'est assez peu invasif si c'est ça qui te gêne.
Tu fais un make installmodules (ou un truc dans le genre je sais plus) et tout est hyper cloisonné dans /lib/modules/<version>
Puis le kernel tu le copies à la main dans /boot, et tu génères l'initrd avec mkinitcpio.

 

Pour tout nettoyer c'est rapide.


Message édité par make install le 10-11-2014 à 11:28:34
n°1368255
gee
Bon ben hon
Posté le 10-11-2014 à 11:31:35  profilanswer
 

Il peut utiliser -e (cette fois oui pour le 'e' :p) et garder le meme repertoire a chaque fois avec makekpg.
 
Mais je suis d'accord avec toi, quand j'ai bitsec curl pour xbmc, je ne me suis pas pris la tete, make/make install/make uninstall.


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368264
Mysterieus​eX
Chieuse
Posté le 10-11-2014 à 16:20:28  profilanswer
 

Elbarto a écrit :

je cherche juste à accélérer la compilation, d'après le site de ccache il n'y a pas d'inconvénients :
 

Citation :


Is it safe?
 
Yes. The most important aspect of a compiler cache is to always produce exactly the same output that the real compiler would produce. This includes providing exactly the same object files and exactly the same compiler warnings that would be produced if you use the real compiler. The only way you should be able to tell that you are using ccache is the speed.
 
ccache has been coded very carefully to try to provide these guarantees. However, if you experience any bugs, please report them.


 
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 :
 

Citation :


Kernel compilation
 
In compiling the kernel, ccache doesn't help at all for most cases. If you want to bisect the kernel, then it will take effect only when the number of remaining patches fall below about 200.



 
Le problème, c'est que si tu tourne actuellement sur un kernel qui génère des bugs ou a tourné sur un kernel qui génère des bugs de compilation, vis a vis de ton CPU ou autre chose, a cet instant T ils vont être mis dans le cache de compilation, et ces bugs vont être présent. Tu change de kernel, ça bug, tu recompile le kernel qui ne posait pas problème et ça se mettra a bugger comme par enchantement, parce que tu aura remplacé des trucs non buggés par des lignes en cache buggées pour ton kernel.
Donc pour résoudre des problèmes, on utilise JAMAIS CCACHE, c'est même le premier truc qu'on te demande de désactiver sur les forums LFS/Gentoo.

n°1368269
Elbarto
Posté le 10-11-2014 à 17:17:21  profilanswer
 

en fait je pars du principe que le bug que j'ai ( freeze aléatoire au boot ) vient d'un commit moisi crée par un développeur linux distrait,

 

et que la compilation avec ccache ne posera pas de problèmes ( pas de cache corrompu ),

 

le risque que tu évoques doit avoir une probabilité assez faible de se produire chez moi, le jeu en vaut la chandelle tellement ccache permet d'économiser du temps ( j'ai un PC pas très puissant ),

 

si le git bisect réussi ( le commit coupable trouvé ) alors ça signifiera que ccache n'a pas causé de problème


Message édité par Elbarto le 10-11-2014 à 17:37:01
n°1368287
Elbarto
Posté le 10-11-2014 à 18:23:56  profilanswer
 

$ git bisect bad
Bisecting: 80 revisions left to test after this (roughly 6 steps)
[3a6095a0173ad8f20c508446880558c9f9224324] KVM: x86: Avoid emulating instructions on #UD mistakenly


 
les mailles du filet se resserrent  [:pingolu:4]


Message édité par Elbarto le 10-11-2014 à 18:24:43
n°1368299
Elbarto
Posté le 10-11-2014 à 23:45:50  profilanswer
 

le coupable a été identifié  [:pandaman2]  [:sweet-memories:1]

 

$ git bisect bad
045065d8a300a37218c548e9aa7becd581c6a0e8 is the first bad commit
commit 045065d8a300a37218c548e9aa7becd581c6a0e8
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Aug 10 05:54:25 2014 -0700

 

   [SCSI] fix qemu boot hang problem
   
    The latest kernel fails to boot qemu arm images when using scsi
    for disk access. Boot gets stuck after the following messages.
   
    brd: module loaded
    sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
    sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
    sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
    sym0: SCSI BUS has been reset.
    scsi host0: sym-2.2.3
   
    Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
    atomic_t" ). Code inspection shows the following suspicious change
    in scsi_request_fn.
   
    out_delay:
    -       if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
    +       if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
                blk_delay_queue(q, SCSI_QUEUE_DELAY);
        }
   
    'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
    meaning the logic was reversed. Changing this expression to
    '!atomic_read(&sdev->device_busy)' fixes the problem.
   
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Acked-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Fixes: 71e75c97f97a
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>

 

:040000 040000 308ba2598b40aade33c390d7e4a97b0132a2131f 73e54c0ef2dd04c52749b7f108d6ff129decc99b M      drivers

 

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
n°1368303
Elbarto
Posté le 11-11-2014 à 02:51:45  profilanswer
 

j'ai crée un patch qui corrige le problème, ça annule le commit défectueux :
 

--- a/drivers/scsi/scsi_lib.c 2014-10-05 21:23:04.000000000 +0200
+++ b/drivers/scsi/scsi_lib.c 2014-11-11 00:24:29.656031943 +0100
@@ -1775,7 +1775,7 @@ static void scsi_request_fn(struct reque
  blk_requeue_request(q, req);
  atomic_dec(&sdev->device_busy);
 out_delay:
- if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
+ if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
   blk_delay_queue(q, SCSI_QUEUE_DELAY);
 }
 


 
j'ai recompilé le paquet linux-3.17.2 en appliquant par dessus ce patch et tout est rentré dans l'ordre, plus aucun freeze aléatoire au boot,
 
j'ai contacté l'auteur du commit défectueux pour l'avertir du bug et lui demander de réécrire son patch, j'ai aussi ajouté mon patch dans mon rapport de bug ( pour l'instant aucun développeur linux ne s'est interessé à ce rapport de bug ),
 
j'espère qu'ils vont réagir, tout semble indiquer un problème dans le code relatif à la gestion du SCSI, ça donne un bug étrange qui apparait de manière aléatoire sur certaines configurations PC

mood
Publicité
Posté le 11-11-2014 à 02:51:45  profilanswer
 

n°1368304
Mysterieus​eX
Chieuse
Posté le 11-11-2014 à 03:15:42  profilanswer
 

Elbarto a écrit :

j'ai crée un patch qui corrige le problème, ça annule le commit défectueux :
 

--- a/drivers/scsi/scsi_lib.c 2014-10-05 21:23:04.000000000 +0200
+++ b/drivers/scsi/scsi_lib.c 2014-11-11 00:24:29.656031943 +0100
@@ -1775,7 +1775,7 @@ static void scsi_request_fn(struct reque
  blk_requeue_request(q, req);
  atomic_dec(&sdev->device_busy);
 out_delay:
- if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
+ if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
   blk_delay_queue(q, SCSI_QUEUE_DELAY);
 }
 


 
j'ai recompilé le paquet linux-3.17.2 en appliquant par dessus ce patch et tout est rentré dans l'ordre, plus aucun freeze aléatoire au boot,
 
j'ai contacté l'auteur du commit défectueux pour l'avertir du bug et lui demander de réécrire son patch, j'ai aussi ajouté mon patch dans mon rapport de bug ( pour l'instant aucun développeur linux ne s'est interessé à ce rapport de bug ),
 
j'espère qu'ils vont réagir, tout semble indiquer un problème dans le code relatif à la gestion du SCSI, ça donne un bug étrange qui apparait de manière aléatoire sur certaines configurations PC


 
Vue se qu'implique ton patch, le risque est plus grand que le gain. Bug relatif au TLER et aux disques un peu lent qui se font éjecter des grappes RAID. Si jamais t'as un disque qui part en carafe du coup t'aura l'effet inverse là. Ton système va hang out, voir corruptions de données. C'est plutôt ton disque qui donne des signes de faiblesses alors patcher le kernel a la barbare pour résoudre ça ...  :ange:

n°1368305
Elbarto
Posté le 11-11-2014 à 03:27:33  profilanswer
 

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,
 
en ce qui me concerne annuler le commit douteux me permet justement d'éviter des pertes de données  vu que le bug entraînait un arrêt brutal du boot ( freeze ), ce qui m'obligait à faire un reset et du coup fsck était obligé de corriger le système de fichiers au prochain boot,
 
c'est une solution temporaire en attendant que les développeurs publient un patch correcteur définitif,
 
à noter que je n'ai aucun disques SCSI, mais uniquement 3 disques SATA, 2 disques IDE et un graveur de DVD sata,
 
il se peut que ce soit la fonction blk_delay_queue() qui soit boguée en réalité, avec le commit cette fonction est peut-être appelée trop souvent et qu'à un moment un bug subtil apparaissait [:transparency]
 
 
sans correctif :
 

Code :
  1. blk_requeue_request(q, req);
  2.   atomic_dec(&sdev->device_busy);
  3. out_delay:
  4.   if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
  5.    blk_delay_queue(q, SCSI_QUEUE_DELAY);


 
traduction approximative : si le disque n'est pas occupé et qu'il n'est pas bloqué alors exécute la fonction blk_delay_queue()
 
avec mon patch :
 

Code :
  1. blk_requeue_request(q, req);
  2.   atomic_dec(&sdev->device_busy);
  3. out_delay:
  4.   if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
  5.    blk_delay_queue(q, SCSI_QUEUE_DELAY);


 
traduction approximative : si le disque est occupé ( à faire quelque chose ) et qu'il n'est pas bloqué alors exécute la fonction blk_delay_queue()
 
ce sont donc les conditions du if() qui changent entre les 2 versions, reste à voir si la première version ( celle du commit douteux ) était bonne en terme de logique pour le if(),
 
si ce patch entraîne plus de mal que de bien alors je le saurai assez vite :D
 
là ça fait une heure que je suis avec le patch, tout est Ok pour l'instant


Message édité par Elbarto le 11-11-2014 à 04:28:00
n°1368307
Mysterieus​eX
Chieuse
Posté le 11-11-2014 à 07:11:43  profilanswer
 

https://www.kernel.org/doc/htmldocs [...] queue.html
 
L'électronique de ton disque pue la mort imminente. Puisqu'en gros, ça veux dire que ton disque ne supporte plus la mise en NCQ et/ou la mise en cache de données.
 
Le truc le plus propre aurait été de modifier le TLER ou de virer les fonctions d'économie d'énergie via HDparm, voir encore de virer la queue via hdparm, voir encore de virer le NCQ (etc ...) de ton disque (qui doit être un caviar green ou un truc du genre) au lieu de corriger le kernel comme un bourrin.  
Et les états SMART ne sont pas un bon indicatif de l'état de santé d'un disque dur. La encore tests de vitesse HDparm peuvent aider.
 
Edit : ou alors c'est ta carte d'interface qui pue la mort, au choix.


Message édité par MysterieuseX le 11-11-2014 à 07:13:39
n°1368309
Elbarto
Posté le 11-11-2014 à 08:08:19  profilanswer
 

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 )

 
Citation :

I have the same problem with the 3.17.2 and 3.17.1 kernels. About a third of all boots hangs after "Triggering uvents...". Other times the boot process continues a bit longer and then hangs when mounting either a partition from my SSD or an NFS share. Some times the system boots ok, which seems to indicate a race condition somewhere.

 

Disabling intel-ucode does not help, but reverting back to 3.16.4 solves the problem for me. I have a 64-bit system with Intel i7-2600K and use nouveau with a GeForce 210. I do not load KMS early.

 

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 :o

 

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 :D )

 

reste un mystère : pourquoi nous sommes que 2 à avoir ce bug ?
c'est le seul point qui me gène, soit les utilisateurs ne rebootent pas assez :D, soit ils ont le problème mais pensent qu'il ne s'agit pas d'un bug mais d'un défaut matériel de leur PC, du coup ils n'osent pas se manifester sur le bugzilla du kernel,

 

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
n°1368310
Mysterieus​eX
Chieuse
Posté le 11-11-2014 à 08:30:42  profilanswer
 

T'as pas bien compris le pourquoi du comment du bug du coup en fait.
 
En gros, pour booter, ça veux dire que tu force un délais dans la queue pour attendre que ton disque réponde, c'est bien un sérieux problème de compatibilité/hardware défectueux.
Le code est bon, puisque la logique veuille qu'on ne le fasse que si le disque est en idle (puisque la fonction remet a 0 la queue en même temps).
Alors que toi tu demande a le faire pendant que le disque est en fonction (wait what ? oO)
 
Edit : pour bien faire, faudrait que tu reprenne la discussion du pourquoi du commit.
http://www.serverphorums.com/read.php?12,1001179
 
Si tu veux ne pas avoir de problèmes et que les kernels d'avant fonctionnaient "nickel" il faut que tu mette :  
if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
L'interprétation du code une fois compilée doit être différente de  
if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
Même si la logique reste la même.

Message cité 1 fois
Message édité par MysterieuseX le 11-11-2014 à 08:37:34
n°1368311
Elbarto
Posté le 11-11-2014 à 08:50:20  profilanswer
 

MysterieuseX a écrit :


En gros, pour booter, ça veux dire que tu force un délais dans la queue pour attendre que ton disque réponde, c'est bien un sérieux problème de compatibilité/hardware défectueux.

 

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 )

 


MysterieuseX a écrit :

T'as pas bien compris le pourquoi du comment du bug du coup en fait.

 

ç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 :D

  


MysterieuseX a écrit :


Si tu veux ne pas avoir de problèmes et que les kernels d'avant fonctionnaient "nickel" il faut que tu mette :
if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
L'interprétation du code une fois compilée doit être différente de
if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
Même si la logique reste la même.

 

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 :D


Message édité par Elbarto le 11-11-2014 à 09:06:45
n°1368319
gee
Bon ben hon
Posté le 11-11-2014 à 12:29:37  profilanswer
 

Si tu n'as pas de reponse sur ton bug, tu peux toujours poster sur la ML.
Si tu dis texto "breaks userspace", t'es sur que Linus vas lire ton message :)

 

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!"
n°1368321
Elbarto
Posté le 11-11-2014 à 12:48:53  profilanswer
 

comment faire pour poster sur la mailing list ?
 
tu parles de ce site ? :
 
https://lkml.org/
 
je n'arrive pas à trouver de lien "register" pour créer un compte et pouvoir poster sur la mailing list, on dirait que c'est reservé qu'aux développeurs linux,
 
edit : j'ai la réponse : http://www.tux.org/lkml/#s3-1
 
sinon j'ai utilisé ccache avec pacman, merci de me l'avoir conseillé :jap:  
 
il a été surtout utile vers le milieu des étapes du bisect ( quand il restait moins de 500 révisions à tester ),  je suis alors passé d'une compilation qui durait 1h10 à une compilation qui ne dure plus que 15 minutes  :sol:  
 
c'est excellent comme programme, du coup je l'active maintenant tout le temps dans makepkg.conf et j'ai augmenté la taille du cache à 5 Go, c'est un gain de temps appréciable, surtout quand on doit recompiler le même programme quand on veut faire des mises au point


Message édité par Elbarto le 11-11-2014 à 12:57:34
n°1368325
gee
Bon ben hon
Posté le 11-11-2014 à 13:04:32  profilanswer
 

Exactement!
Apres comme tout programme il n'est pas parfait, penses-y quand tu as un soucis (comme pour ton edition de fichier xorg)


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368369
Elbarto
Posté le 12-11-2014 à 01:03:21  profilanswer
 

gee a écrit :

Si tu n'as pas de reponse sur ton bug, tu peux toujours poster sur la ML.
Si tu dis texto "breaks userspace", t'es sur que Linus vas lire ton message :)


 
ça y est j'ai envoyé le mail dans la mailing list,  
 
j'ai utilisé un anglais un peu approximatif mais les développeurs devraient comprendre,
 
je n'ai pas utilisé le terme "breaks userspace" mais j'ai mis en majuscules le mot bug, puis les termes "scsi", "bad commit" devraient attirer l'oeil je pense,
 
j'ai eu une réponse me demandant de mettre l'auteur du commit suspect en copie caché mais j'avais déjà envoyé un mail à cet auteur ( toujours pas de réponse à l'heure où j'écris )
 
comme je me suis inscrit à la mailing list j'ai reçu des tas d'autres mails sur d'autres bugs en peu de temps, la quantité de mails émis dans cette mailing list semble énorme

n°1368370
gee
Bon ben hon
Posté le 12-11-2014 à 01:15:58  profilanswer
 

J'ai lu ton message, ca va ca se comprend.
 
Sinon un patch n'est pas necessaire, il suffit "d'annuler le commit fautif".

Code :
  1. git revert <commit>


 


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368536
gee
Bon ben hon
Posté le 13-11-2014 à 10:40:09  profilanswer
 

Elbarto tu as un email, faut y repondre pour fixer ce soucis :o
Si jamais tu ne sais pas pour la question:

Code :
  1. cat /sys/module/scsi_mod/parameters/use_blk_mq


 
Sinon pour MysterieuseX, pas un seul dev sur la ML n'a ecrit quoi que ce soit sur le soit disant materiel d'Elbarto en train de mourir... bizarre ca.


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368541
Elbarto
Posté le 13-11-2014 à 11:11:22  profilanswer
 

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 ),
 
je leur ai dit que je n'utilisais pas cette option de démarrage du kernel,
 
quand je fais un "cat /sys/module/scsi_mod/parameters/use_blk_mq" j'ai la réponse "N", ce qui prouve que je n'utilise pas cette option,
 
n'étant pas expert en code SCSI j'ai suggéré d'utiliser des tests unitaires pour vérifier le fonctionnement correct des fonctions SCSI du code source linux,
 
je suis développeur mais pas du tout dans le domaine des systèmes d'exploitation ( je fais plutôt dans le java, un peu de web, un peu de C#, des choses pas trop complexes et surtout pas de C :D ), très souvent les tests unitaires m'ont permis d'éviter le pire au niveau des bugs, je ne sais pas si les développeurs linux ont l'habitude de rédiger des tests unitaires, mais ça réduirait beaucoup le risque de bugs de regression

n°1368542
gee
Bon ben hon
Posté le 13-11-2014 à 11:13:53  profilanswer
 

Un test unitaire c'est bien et meme indispensable.
Mais si le soucis vient d'une chaines de fonctions + materiel special, ton test unitaire ne servira pas a trouver cela.
 
Je suis aussi dev, et aussi pas OS comme toi, meme si j'ai deja ecrit mon propre kernel il y a longtemps pour voir... :)


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368568
Mysterieus​eX
Chieuse
Posté le 13-11-2014 à 18:02:45  profilanswer
 

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.
Les trucs plus ou moins exotiques du genre HBA jmicron, va falloir oublier et évoluer sur le matos :/
 
Donc c'est pour ça que j'ai exprimée mes doutes sur la modif qu'il a fait et d'autres le font sur la ML. Notamment MONSIEUR LSI logic et intégration ASIC chez HP pour le stockage et le big data ( https://www.linkedin.com/in/robertcelliott ) avec qui j'échange assez régulièrement pour savoir qu'il dit pas que des conneries. Bref ...
 
Je persiste c'est ton matos qui supporte pas les nouveaux codages/est en train de mourir :>

n°1368572
Elbarto
Posté le 13-11-2014 à 18:40:00  profilanswer
 

matos déprécié ?
 
mes disques SATA  datent de 2010 à peu près, c'est pas si vieux que ça,
 
la carte PCIe JMicron ( qui a 2 ports SATA et un port IDE ) date aussi de 2010,
 
à moins que tu sois pour l'obsolescence programmée ce genre de matériel est encore tout à fait d'actualité :D
 
la carte mère date de 2008, chipset intel P31, supporte les core 2 duo et quad, le CPU date de 2010 ( pentium dual core E6800 3.33 Ghz ) ça vaut pas un icore i7 mais c'est suffisant pour mes besoins,
 
il y a un paquet considérable de PC bien plus vieux que le mien qui tournent sous linux, ce serait une erreur monumentale de la part des développeurs linux d'abandonner le support des périphériques IDE, je pense qu'ils vont assurer la compatibilité avec le vieux matos même s'ils mettent à jour les API liées à la gestion des disques durs, ils ne peuvent pas faire autrement, ce serait se tirer une balle dans le pied sachant que les OS concurrents continuent de gérer les disques IDE,
 
je te le répète à nouveau cette configuration fonctionne parfaitement sous windows et sous archlinux, le souci n'est présent qu'avec le noyau 3.17 ( et 3.18 ) et uniquement au boot et uniquement de manière aléatoire ( 20% de chances que le boot se bloque brutalement ), une fois que l'étape du boot est passée alors le bug ne se produit pas durant la session KDE,  
 
tout indique donc un bug logiciel quelque part dans le code source du noyau 3.17 et 3.18
 

MysterieuseX a écrit :


Je persiste c'est ton matos qui supporte pas les nouveaux codages/est en train de mourir :>


 
ça ne veut rien dire cette phrase, ce n'est pas au matériel de s'adapter au logiciel mais l'inverse, les développeurs se basent sur des spécifications techniques du matériel ( norme IDE, SATA, SCSI etc ) pour créer le pilote qui va bien et ensuite tant qu'il n'y a pas de bug dans le pilote alors le matériel continuera de fonctionner sans soucis, que ce soit maintenant ou dans 10 ans,
 
regarde le cas du lecteur de disquette, du port parallèle, le port série : ce sont des périphériques obsolètes mais c'est toujours supporté dans le noyau linux


Message édité par Elbarto le 13-11-2014 à 19:02:20
n°1368574
Mysterieus​eX
Chieuse
Posté le 13-11-2014 à 19:24:13  profilanswer
 

Visiblement, ça sert pas a grand chose d'essayer de t'expliquer quelque chose.
 
Un contrôleur HBA, c'est l'association d'un phy (pour puce d'adaptation physique) et d'un software. Le tout forme un firmware.
Le firmware est a la norme SATA, qui a des specs fermées (=closed source) mais utilisable a but non lucratif. Que le kernel sache envoyer des commandes "bloc" a la norme SATA c'est une chose, que le phy fonctionne en est une autre, mais que le software entre les deux soit adapté, 100% du temps sous linux, c'est niet. Vue que justement, sur ce type de matos, c'est le firmware complet et surtout sa partie software qui est closed source et souvent non supporté sous linux (ou alors mal : CF les controleurs marvell ou les firmware sont dispo mais implémentation merdique).
Alors maintenant, pour le software concernant les puces jmicron, il y a deux protocoles qui permettent d'assurer la phase de boot jusqu'au chargement du firmware. Ces protocols sont fait par rétro ingénierie et assurent un fonctionnement basique pour une large palette dans les familles de puces jmicron, alors va comprendre pourquoi, y'a un truc qui foire a ce niveau la.
Explication du "bug" : quelque part une fonction SATA sert pour gérer la queue, tes disques ont du NCQ, le controleur doit aussi être compatible, bref, t'as une queue de X commandes SATA. Normalement, cette queue doit être remise régulièrement a 0 avant que le disque puisse en accepter de nouvelles commandes, mais dans son mécanisme, quelque part, sa remise a 0 bloc et te place le disque en perma occupé > le kernel attend ... attend ... attend ...
Deux choses :  
Premier commit "if (sdev->device_busy == 0 && !scsi_device_blocked(sdev)) "  
Second commit "if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))"
 
Les deux fonctions, sont interprétable par GCC ou LLVM/Clang de la même manière MAIS visiblement le code produit diffère (pourtant c'est la même chose) va savoir pourquoi ? (imho, c'est un problème du style LTO dans le compilateur et pas un problème du code)
On est plusieurs a te le dire que NON fondamentalement le code n'est pas différent dans son résultat, soit passons !
On est plusieurs a te dire que ça solutionne des problèmes.
 
Moi je t'explique qu'une variation du code, ou de la prise en charge des protos niveau bas niveau peu provoquer ça, ou alors un soucis de compilation, ou autre ... (Genre matos qui rend l'ame, tu sais, une puce mémoire de 128ko ça jarte vite sur un asic ou un HBA, c'est le truc con mais ça arrive même sur du matos qui a 1 semaine.)
 
Les monsieur de la LKML te proposent de revenir au commit d'origine (celui qui introduit if (sdev->device_busy == 0 && !scsi_device_blocked(sdev)) chose que je te propose aussi) et de voir si tu as des problèmes.
Si tu en as, c'est ton matos qui rend l'âme (tu n'avais pas de problèmes avant, tu en a maintenant, alors que stricto sensus le code a pas changé depuis au moins les kernel 3.14) ou le LTO a virer quand tu compile le kernel (link time optimisation) puisque le LTO change régulièrement (t'es en rolling et la toolchain évolue sur arch, se qui est un défaut de conception de la distro mais passons, parce que tu ne peu débugger un kernel sans être sur que ta toolchain ne change pas, faut comparer a toolchain fixe) si tu n'as pas de problème alors tu peu explorer le LTO (encore une fois) puisque le commit est stricto sensus le même.
Mais tu ne peu rester comme tu es actuellement (se que tout le monde te dit également) puisque ça revient a ne pas utiliser la queue et provoquer des bugs dans qemu et d'autres couches fonctionnant en mode bloc.

n°1368581
Elbarto
Posté le 13-11-2014 à 20:06:04  profilanswer
 

tu as le don de complexifier les choses de manière XXL, le tout dans une dimension très orientée matériel  [:implosion du tibia]  
 
C'est peut-être à cause de ton métier ? ( administrateur système ? )
 
 
j'ai une analyse nettement plus "KISS" pour reprendre le gimmick d'archlinux  :
 
d'un coté je constate que :
 
- ça marche nikel avec les noyaux inférieurs à 3.17
- ça marche avec Windows ( c'est notamment ce point qui fragilise ton hypothèse "matérialiste", si défaut matériel il aurait dû se produire avec windows )
- RAS niveau infos smart/secteurs défectueux
- le matos n'est pas si vieux que ça
 
d'un autre coté :
 
- j'ai trouvé un utilisateur qui a ( à priori ) le même bug mais un PC bien plus récent
- un bisect désigne du doigt un commit
- j'annule ce commit --> tout redevient normal
- je vois qu'il y a eu plein de commits ces derniers mois relatifs à des modifications dans le code SCSI
 
la conclusion logique est donc de dire que vraisemblablement il y a eu un bug de régression durant ces tentatives de modifier les élements du code source SCSI, inutile de partir tout de suite dans des délires alarmistes/technologiques/matos obsolète/qui va tomber en panne [:shigeru24]
 
si le matériel est vraiment en cause alors on verra à ce moment là, chaque chose en son temps
 
 

MysterieuseX a écrit :


Si tu en as, c'est ton matos qui rend l'âme (tu n'avais pas de problèmes avant, tu en a maintenant, alors que stricto sensus le code a pas changé depuis au moins les kernel 3.14)


 
il y a nécessairement quelque chose qui a changé puisqu'avec les noyaux antérieurs au 3.17 il n'y a pas de souci, et que je suppose que mon matériel n'est pas en cause,
 
ne pas oublier qu'il y a des interactions entre plusieurs composants du code source linux, des fonctions qui s'appuient sur d'autres fonctions, si l'une d'elles a un bug cela aura des répercussions sur le reste, sans oublier le cauchemar du développeur C : les pointeurs qui merdouillent, les chaines non terminées par un zéro, tout ce qui fait que je déteste ce langage :D


Message édité par Elbarto le 13-11-2014 à 21:05:05
n°1368596
gee
Bon ben hon
Posté le 14-11-2014 à 00:26:10  profilanswer
 

MysterieuseX a écrit :


Les deux fonctions, sont interprétable par GCC ou LLVM/Clang de la même manière MAIS visiblement le code produit diffère (pourtant c'est la même chose) va savoir pourquoi ? (imho, c'est un problème du style LTO dans le compilateur et pas un problème du code)


La par contre je ne comprend pas.
Tu dis que le code revient au meme mais produit un asm different.
Si l'asm est different, le code est alors aussi different non? (hors options du compilateurs qui changent bien sur)


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
n°1368599
Elbarto
Posté le 14-11-2014 à 01:44:21  profilanswer
 

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,
 
il s'agit de ce commit qui déclenche le bug ( commit où il y a eu énormément de modifications sur plusieurs fichiers ), paru fin juillet dernier ( 2 semaines avant celui de Guenter Roeck ), à priori c'est lui le premier "bad commit"  :
 
scsi: convert host_busy to atomic_t :
 
http://git.kernel.org/cgit/linux/k [...] a0a4e029ee
 
le bug est donc plus compliqué que ce qu'il n'y parait,
 
quand je regarde le noyau 3.16.x qui ne pose pas de problème le if() est comme ceci :
 

Code :
  1. /*
  2.  * lock q, handle tag, requeue req, and decrement device_busy. We
  3.  * must return with queue_lock held.
  4.  *
  5.  * Decrementing device_busy without checking it is OK, as all such
  6.  * cases (host limits or settings) should run the queue at some
  7.  * later time.
  8.  */
  9. spin_lock_irq(q->queue_lock);
  10. blk_requeue_request(q, req);
  11. sdev->device_busy--;
  12. out_delay:
  13. if (sdev->device_busy == 0)
  14.  blk_delay_queue(q, SCSI_QUEUE_DELAY);
  15. }


 
la différence : le if() est beaucoup plus simple sans de seconde condition ( pas de "&& !scsi_device_blocked(sdev)" )
 
peut-être qu'en supprimant cette seconde condition dans mon patch je retrouverai un fonctionnement vraiment similaire aux versions 3.16.x  qui étaient Ok chez moi :
 
ça donnerait ceci comme patch :
 

Code :
  1. - if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
  2. + if (!atomic_read(&sdev->device_busy) )
  3.   blk_delay_queue(q, SCSI_QUEUE_DELAY);
  4. }


 
edit : j'ai testé ce changement, ça ne marche pas, ça fait réapparaître le bug,
 
donc retour au précédent patch en attendant la solution définitive de la part des développeurs


Message édité par Elbarto le 14-11-2014 à 03:11:45
n°1368774
Elbarto
Posté le 16-11-2014 à 18:56:39  profilanswer
 

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
- valeur à 6 ms : c'est mieux, le bug se produit beaucoup plus rarement
- valeur à 15 ms : idem, la probabilité d'apparition du bug est repoussée, mais se produit toujours
- valeur à 30 ms : presque parfait, le bug n'apparait maintenant que très rarement ( tous les 20 reboots, alors qu'avant c'était tous les 5 à 10 reboots )
- valeur à 40 ms : le bug a disparu ! J'ai dû faire une trentaine de reboots consécutifs et le bug n'est jamais apparu

 

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 :

 

--- a/drivers/scsi/scsi_lib.c 2014-10-05 21:23:04.000000000 +0200
+++ b/drivers/scsi/scsi_lib.c 2014-11-16 17:39:16.819674725 +0100
@@ -1776,7 +1776,7 @@ static void scsi_request_fn(struct reque
  atomic_dec(&sdev->device_busy);
 out_delay:
  if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
-  blk_delay_queue(q, SCSI_QUEUE_DELAY);
+  blk_delay_queue(q, 40);
 }
 
 static inline int prep_to_mq(int ret)

 

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
n°1368794
Mysterieus​eX
Chieuse
Posté le 17-11-2014 à 10:41:34  profilanswer
 

Elbarto a écrit :

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
- valeur à 6 ms : c'est mieux, le bug se produit beaucoup plus rarement
- valeur à 15 ms : idem, la probabilité d'apparition du bug est repoussée, mais se produit toujours
- valeur à 30 ms : presque parfait, le bug n'apparait maintenant que très rarement ( tous les 20 reboots, alors qu'avant c'était tous les 5 à 10 reboots )
- valeur à 40 ms : le bug a disparu ! J'ai dû faire une trentaine de reboots consécutifs et le bug n'est jamais apparu
 
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 :
 

--- a/drivers/scsi/scsi_lib.c 2014-10-05 21:23:04.000000000 +0200
+++ b/drivers/scsi/scsi_lib.c 2014-11-16 17:39:16.819674725 +0100
@@ -1776,7 +1776,7 @@ static void scsi_request_fn(struct reque
  atomic_dec(&sdev->device_busy);
 out_delay:
  if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
-  blk_delay_queue(q, SCSI_QUEUE_DELAY);
+  blk_delay_queue(q, 40);
 }
 
 static inline int prep_to_mq(int ret)


 
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


 
Relit mes posts, ceci dit, moi en tant qu'admin stockage, je refuse ce patch, et a mon avis, y'a pas grand monde niveau stockage qui passera le commit : grappe de 10 disques = 400ms, une armoire de 200 disques =80 secondes de delais (au lieu de 6), vue que t'invalide les queues en HA pour aller plus vite pour préparer les disques ...
Ou alors prévoir un gonflement de la ram a juste 10 fois la masse actuelle ?
Personne n'a relevé la remarque parce qu'elle est fixée au minimum acceptable par le matos en règle générale et que c'est basé sur le seek time et la mise en rotation des disques.

n°1368799
make insta​ll
Posté le 17-11-2014 à 11:09:11  profilanswer
 

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 ?
Tu as fait les tests SMART les plus longs ou juste les tests de base Elbarto ?

n°1368841
Elbarto
Posté le 17-11-2014 à 15:54:53  profilanswer
 

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 [:transparency]

 


MysterieuseX a écrit :


grappe de 10 disques = 400ms
une armoire de 200 disques =80 secondes de delais (au lieu de 6).

 

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
n°1368853
Mysterieus​eX
Chieuse
Posté le 17-11-2014 à 18:23:55  profilanswer
 

Elbarto a écrit :

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 [:transparency]
 
 
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


 
Je vais éviter de dire se que j'en pense sachant que j'ai déjà soulever le point de disque obsolète, fixer avec HDPARM en jouant sur les param de mise en veille etc ... Mais que tu persiste a qualifier ça de bug (alors que le problème viens de ton matos)  :ange:

n°1368862
Elbarto
Posté le 17-11-2014 à 19:46:09  profilanswer
 

MysterieuseX a écrit :


tu persiste a qualifier ça de bug (alors que le problème viens de ton matos)  :ange:

 

bug de régression parce que :

 

- aucun problème avec les noyaux 3.16.x et antérieurs
- aucun soucis avec les OS concurrents ( windows )

 

c'est pourtant pas compliqué à comprendre [:amiralj]

 

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 [:monsieur spock]

 


un comparatif avec et sans patch "40ms" du temps que met une compilation du noyau 3.17.3 ( avec ccache activé )

 

sans patch
real    16m1.622s
user    15m6.360s
sys     2m52.900s

 

avec patch "40ms"
real    15m55.995s
user    15m6.933s
sys     2m53.170s

 

systemd-analyze

 

Startup finished in 4.756s (kernel) + 14.595s (userspace) = 19.352s

 

avec patch 40ms
Startup finished in 4.601s (kernel) + 14.628s (userspace) = 19.230s

 


des temps équivalents

 

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
n°1368867
Ralph-
★ You'll hate me. ★
Posté le 17-11-2014 à 21:08:05  profilanswer
 

MysterieuseX a écrit :


 
Je vais éviter de dire se que j'en pense sachant que j'ai déjà soulever le point de disque obsolète, fixer avec HDPARM en jouant sur les param de mise en veille etc ... Mais que tu persiste a qualifier ça de bug (alors que le problème viens de ton matos)  :ange:


 
J'ai lu nul par que le noyau 3.17 ne devait plus gérer la norme IDE... C'est pas non plus comme si on avait des revert commit à la pelle dans tous les kernels juste en pétant 5% de compatibilité. En tout cas, Elbarto se casse bien le cul pour trouver d'où ça vient, et je trouve ça bien plus productif que du taunt de bas étage.

n°1368926
Elbarto
Posté le 18-11-2014 à 22:26:41  profilanswer
 

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

 
Citation :

The purpose of atomic_t is to implement a type and a set of functions that can operate on it correctly from different threads without requiring synchronization like mutexes. It is implemented in its own way on a specific platform so that it's guaranteed by implementation.

 

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 [:transparency]

 

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
n°1368929
Mysterieus​eX
Chieuse
Posté le 19-11-2014 à 00:09:52  profilanswer
 

Elbarto a écrit :

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
 

Citation :

The purpose of atomic_t is to implement a type and a set of functions that can operate on it correctly from different threads without requiring synchronization like mutexes. It is implemented in its own way on a specific platform so that it's guaranteed by implementation.


 
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 [:transparency]
 
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
 
 


 
Merci d'avancer dans le sens du problème que j'ai soulevée finalement (alors que non, non c'était pas ça :x, c'est juste un peu mon taff a moi de régler ce genre de problèmes, de façon journalière hein ...)
Pas certaine que passer sur le jmicron résolve le problème, dépend du port sur lequel il sera branché.
Et la synchro ne se voit pas sur un test de compilation, ça se mesure a l'init des disques (mais t'as pas les outils pour, faut un kernel patché pour récupérer les spinup time, idle time AU BOOT dans ton cas ou pendant le POST d'un disque hotplug a la rigueur)

n°1368931
Elbarto
Posté le 19-11-2014 à 00:51:09  profilanswer
 

MysterieuseX a écrit :


Merci d'avancer dans le sens du problème que j'ai soulevée finalement (alors que non, non c'était pas ça :x, c'est juste un peu mon taff a moi de régler ce genre de problèmes, de façon journalière hein ...)


 
dans la mesure où le problème n'existe pas avec les noyaux précédents et ni avec les OS concurrents alors ton hypothèse "matériel défectueux" n'est pas plausible :o  
 
merci donc de ne plus insister lourdement là dessus,
 
la solution doit passer idéalement par la correction du bug, on doit rester dans un domaine purement logiciel, ton travail d'administrateur réseau est hors-sujet ici et ne fait ajouter que de la confusion, ce que j'aimerai c'est quelqu'un qui puisse trouver un meilleur patch que le mien, mais pour cela il faut comprendre pourquoi le passage au type de données "atomic_t" crée ce problème chez moi,
 
le dernier paragraphe de ton message est incompréhensible, notamment la phrase "la synchro ne se voit pas sur un test de compilation",
 
je vais finir par croire que tu utilises un générateur de phrases qui puise au hasard dans une liste de termes informatique :o

Message cité 1 fois
Message édité par Elbarto le 19-11-2014 à 01:01:41
n°1368935
gee
Bon ben hon
Posté le 19-11-2014 à 01:12:51  profilanswer
 

Elbarto a écrit :


 
dans la mesure où le problème n'existe pas avec les noyaux précédents et ni avec les OS concurrents alors ton hypothèse "matériel défectueux" n'est pas plausible :o  


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 :/


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  172  173  174  ..  179  180  181  182  183  184

Aller à :
Ajouter une réponse
 

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


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR