[3.17.x] freeze aléatoire au boot ( contourné matériellement )

[Elbarto]

Mais franchement je trouve très étrange que ce soit ce commit le responsable : https://github.com/torvalds/linux/commi ... d581c6a0e8

qu'est-ce qui te fait dire ça ?

là je suis en train de compiler la version 3.17.2 sans ce commit, on va voir ce que ça donne,

si ça ne marche pas alors j'ai dû me tromper dans le git bisect lorsque j'ai déclaré "good" un des commits proposés par git, car comme c'est un bug aléatoire au boot il se peut que je n'ai pas assez rebooté lors des tests, faisant alors passer un commit pour "good" alors qu'il possède le bug,

mais dans tous les cas je pense qu'on est pas loin de la vérité, c'est forcément quelque chose liée au SCSI car dans les derniers commits que git m'a proposé de tester j'ai vu plusieurs commits liés à des modifications du code relatif au SCSI

[Elbarto]

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

Code : Tout sélectionner

--- 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 sur le bugzilla du kernel ( 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

[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" ( commit qui est le vrai "premier bad commit" car j'ai refait un nouveau bisect )

http://git.kernel.org/cgit/linux/kernel ... a0a4e029ee

à 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é, 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 :

Code : Tout sélectionner

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

[Elbarto]

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écutifs 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

[benjarobin]

Ou un bug dans le kernel...

[Elbarto]

oui, mais ce qui est bizarre c'est que peu de gens se soient manifestés, il n'y a que moi et quelqu'un dans le forum anglais qui se soient manifestés ( cet utilisateur possède aussi une carte mère gigabyte mais beaucoup plus récente que la mienne ),

à noter que ma carte mère n'a pas l'option "AHCI" dans le bios, car elle n'a qu'un contrôleur disque ICH7 basique, peut-être que ça joue dans l'apparition du bug

[benjarobin]

Franchement c'est loin d'être commun d'avoir autant de chose de branché... Donc cela ne m'étonne pas du tout...

[Elbarto]

en fait il n'y a pas besoin d'avoir autant de disques branchés ( je n'ai peut-être pas été clair dans ma démonstration ), car le bug apparait dès que le graveur de DVD est connecté sur un des ports sata interne de ma carte mère :

en gros dès qu'il y a un disque dur et un graveur de branché sur les ports SATA de ma carte mère alors le bug va apparaitre ( blocage aléatoire au boot, 20 à 30% de chance d'apparition ), le graveur semble ne pas apprécier les effets du commit 74665016086615bbaa3fa6f83af410a0a4e029ee ( scsi: convert host_busy to atomic_t ), dans ce commit le type de données "atomic_t" est utilisé pour certaines variables dans le code source lié au scsi, alors qu'avant ce commit ce type de données n'y apparaissait pas, auparavant c'était un simple "unsigned int" qui était utilisé pour certaines variables, le type "atomic_t" est utilisé dans linux quand on ne veut pas s'embêter à utiliser un système de sémaphores pour synchroniser 2 threads concurrents,


cette configuration ( disque + graveur sata ) est loin d'être exceptionnelle, mais il faut avoir une vieille carte mère ( contrôleur ICH7 ) et peut-être la même marque de graveur DVD sata, ce sont ces 2 derniers aspects qui probablement font que peu de personnes soient touchées,

quand les distributions linux généralistes basculeront sur le noyau 3.17 on verra peut-être un peu plus de gens touchés par ce bug

[Elbarto]

un développeur linux a proposé un patch correcteur, je l'ai testé et ça résout le problème :

Code : Tout sélectionner

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 994eb08..99b77f7 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -311,16 +311,16 @@ void scsi_device_unbusy(struct scsi_device *sdev)
 	struct scsi_target *starget = scsi_target(sdev);
 	unsigned long flags;
 
+	spin_lock_irqsave(shost->host_lock, flags);
 	atomic_dec(&shost->host_busy);
 	if (starget->can_queue > 0)
 		atomic_dec(&starget->target_busy);
 
 	if (unlikely(scsi_host_in_recovery(shost) &&
 		     (shost->host_failed || shost->host_eh_scheduled))) {
-		spin_lock_irqsave(shost->host_lock, flags);
 		scsi_eh_wakeup(shost);
-		spin_unlock_irqrestore(shost->host_lock, flags);
 	}
+	spin_unlock_irqrestore(shost->host_lock, flags);
 
 	atomic_dec(&sdev->device_busy);
 }
@@ -1504,6 +1504,8 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
 	if (scsi_host_in_recovery(shost))
 		return 0;
 
+	spin_lock_irq(shost->host_lock);
+
 	busy = atomic_inc_return(&shost->host_busy) - 1;
 	if (atomic_read(&shost->host_blocked) > 0) {
 		if (busy)
@@ -1527,21 +1529,19 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
 
 	/* We're OK to process the command, so we can't be starved */
 	if (!list_empty(&sdev->starved_entry)) {
-		spin_lock_irq(shost->host_lock);
 		if (!list_empty(&sdev->starved_entry))
 			list_del_init(&sdev->starved_entry);
-		spin_unlock_irq(shost->host_lock);
 	}
 
+	spin_unlock_irq(shost->host_lock);
 	return 1;
 
 starved:
-	spin_lock_irq(shost->host_lock);
 	if (list_empty(&sdev->starved_entry))
 		list_add_tail(&sdev->starved_entry, &shost->starved_list);
-	spin_unlock_irq(shost->host_lock);
 out_dec:
 	atomic_dec(&shost->host_busy);
+	spin_unlock_irq(shost->host_lock);
 	return 0;
 }

[benjarobin]

Je suis curieux, as tu le lien vers l'échange ? De plus le rapport de bug que tu avais ouvert n'en parle pas.

Trouvé : https://lkml.org/lkml/2014/11/11/931 + https://lkml.org/lkml/2014/11/20/581

When breaking an existing setup in software it's always the softwares fault, btw..

C'est ce que je pense aussi C'est pour cela que j'insistais sur un bug kernel...

[Elbarto]

j'ai ajouté ce patch dans le rapport de bug,

en tout cas le patch fonctionne bien, je ne sais pas si c'est un patch définitif, peut-être que le développeur va encore l'améliorer

[Elbarto]

dans le rapport de bug que j'ai ouvert il y a enfin quelqu'un qui s'est manifesté et qui a le bug,

il a une carte mère beaucoup plus récente, mais il utilise des périphériques IDE : un graveur et un disque dur :

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

il a testé le patch crée par le développeur linux et ça a résolu le problème,

ça fait donc 2 utilisateurs recensés ( avec celui du forum anglais archlinux ) touchés par ce bug