Lors du passage en Debian11 et donc en Kernel 5 j’ai rencontré un problème de non reconnaissance de mes disques durs connectés sur la carte PCIe, avec des temps de boot très longs.

En faisant dmesg j’avais pu déduire que c’était à l’inscription du module ahci que se déclenchait l’erreur, le kernel n’arrivait pas à calibrer les disques et donc à les reconnaîtres.Après avoir jouer avec les paramètre de libata et de libahci et sans succès, j’ai constaté que dans dmesg le module AHCI prenait des niveaux d’interuption qui me semblaient un peu élevés par rapport à la plage d’interruptions fournie par le bios.

Cette constatation m’a amené à me dire que le problème était peut être de ce côté et en cherchant sur le Net je suis tombé sur des articles citant des problèmes avec d’autres cartes Sata PCIe, sans aucun rapport avec la mienne. Donc j’ai tenté le paramètre noapic qui m’a gentiment planté puis le paramètre pci=nomsi. et ça a fait l’affaire.

Ce paramètre désactive un mode avancé de gestion des interruptions qui est probablement mal reconnu soit de ma carte PCIe soit par l’Apic de mon PC.

un lien citant la solution : https://forum.ubuntu-fr.org/viewtopic.php?id=1638921 ou https://askubuntu.com/questions/1104219/what-does-pci-noaer-or-pci-nomsi-mean.

Ce qui confirme qu’il ne faut jamais baisser les bras, si on ne comprend pas aujourd’hui on comprendra plus tard.

Mise à jour décembre 2024 :
Ce réglage n’est plus nécessaire avec les noyaux 6.11 et peut être un peu antérieur de Debian Sid. Un autre problème de boot est apparu avec des difficultés d’initialisation de la partie video et donc la console qui bloque et c’est en essayant de régler ce problème que j’ai testé la suppression du paramètre. Le plus drôle c’est que ça améliore un peu les difficultés de boot. Je pense que ce problème aléatoire actuel est lié à un timing trop resserré pour ma vielle bécane.

On trouve beaucoup de documentation sur la connexion bluetooth d’un casque sur le web mais c’est assez touffu et si vous essayer d’appliquer toutes les recettes et bien ça ne marche pas.
Après pas mal de manip j’ai fini âr désinstaller tout ce que j’avais tenté et je suis parti du plus simple :

 sudo apt install blueman bluez-firmware

Et ça suffit 🙂

Et j’admide de plus en plus ma debian avec lxqt sur mon vieux PC c’est propre net et je peux regarder Molotov dessus (qui d’ailleurs fonctione mieux que sous windows et notamment avec un son et un volume de meilleur qualité). Prochaine étape voir comment éviter que xsceensaver n’interrompe le visionnage.

Après des années à ne pas comprendre pourquoi le count(*) était aussi long sur ma base à partir du moment où je la comptais à partir d’une View, j’ai drastiquement accéléré la requête. Quand je dis drastiquement je suis passé d’une dizaine de seconde à du quasi instantané et la consommation mémoire de la base a chu. L’analyse me montrait que le count(*) de la table principale de la view se faisait sur l’index alors que le count(*) sur la view déclenchait un full scan.

Dans un premier temps j’ai réécrit la view pour passer de jointures à gauche en étoile à des jointures en cascade, au passage un jointure à gauche est devenu une jointure normale. Cette modification améliorait un chouia le temps de réponse mais pas de manière transcendante.

Puis je suis tombé sur un article qui expliquant que l’opimiseur Innodb lors d’un count(*) n’utilisait pas le primary index, la répartition de celui-ci n’étant pas optimal, s’il y a un secondary index c’est celui-ci qui est utilisé sinon l’optimiseur cherche à déterminer quelle est la meilleur colonne pour le count(*).

Je n’y croyais pas mais effectivement le rajout d’un index « qui ne sert à rien mais sur une colonne petite » (dans mon cas le code postal) a suffit pour obtenir un temps de réponse canon pour le count(*) sur ma table de plus de 2 millions d’enregistrement.

Un grand Merci à Aaron Francis pour son éclairant article Is COUNT(*) slow in MySQL?