J'utilise Debian depuis une quinzaine d'années, sans problème de RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent
brutalement, sans raison apparente (rien trouvé dans syslog, notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=10000).
* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la
version stable de Debian que j'utilise.)
* La machine de bureau, qui donnait entière satisfaction depuis plusieurs
années, a commencé à montrer les mêmes symptômes juste après son passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau en
juillet 2017.
* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.
* Les quatre machines utilisent exclusivement JFS.
Je souligne que même quand les performances deviennent abyssales, les tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').
Redémarrer la machine restaure la performance normale. La performance reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.
Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb
Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à
creuser ? Comment pourrais-je extraire du système des informations sur
l'origine du problème ? Voyez-vous quels changements intervenus dans la
Debian 8, après la release initiale, pourraient causer ce comportement ?
Merci d'avance pour votre aide !
Seb.
PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas
ce qu'il faut régler...
#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 17786 -
# 2 Short offline Completed without error 00% 15666 -
#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 16593 -
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1084953685-1507191962=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Thierry,
Idée de troisième solution à faire en parallèle d'un contournement: se rapprocher des développeurs du kernel pour signaler qu'il y a probablement un bug. Je pense qu'il n'y pas plus vraiment de doute l'existence d'un bug. Peut être que eux, justement, pourront proposer un contournement fiable en attendant la release du correctif.
C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ? Seb. ---1155178722-1084953685-1507191962=:17980--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Idée de troisième solution à faire en parallèle d'un contournement: se
rapprocher des développeurs du kernel pour signaler qu'il y a
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute
l'existence d'un bug. Peut être que eux, justement, pourront proposer un
contournement fiable en attendant la release du correctif.
C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ?
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1084953685-1507191962=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Thierry,
Idée de troisième solution à faire en parallèle d'un contournement: se rapprocher des développeurs du kernel pour signaler qu'il y a probablement un bug. Je pense qu'il n'y pas plus vraiment de doute l'existence d'un bug. Peut être que eux, justement, pourront proposer un contournement fiable en attendant la release du correctif.
C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ? Seb. ---1155178722-1084953685-1507191962=:17980--
Pascal Hambourg
Le 05/10/2017 à 10:24, Seb a écrit :
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie depuis <https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64> (je suppose que l'architecture est amd64) ou depuis une machine sous Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch. Les dépendances devraient être satisfaites. Sinon, faire comme avec les backports : ajouter les dépôts jessie dans sources.list et forcer l'installation du paquet de jessie avec apt-get -t jessie...
Le 05/10/2017 à 10:24, Seb a écrit :
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)
J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie
depuis <https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64>
(je suppose que l'architecture est amd64) ou depuis une machine sous
Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch.
Les dépendances devraient être satisfaites.
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans
sources.list et forcer l'installation du paquet de jessie avec apt-get
-t jessie...
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie depuis <https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64> (je suppose que l'architecture est amd64) ou depuis une machine sous Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch. Les dépendances devraient être satisfaites. Sinon, faire comme avec les backports : ajouter les dépôts jessie dans sources.list et forcer l'installation du paquet de jessie avec apt-get -t jessie...
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour Pascal,
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée. Si j'appelle sur une machine en Debian 9 apt-cache search linux-image je ne vois pas de noyau 3.16 . Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de solution packagée indiquée; d'un autre côté, elle ne mentionne pas non plus les backports pour avoir, au contraire, un noyau plus récent. Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire ça, cela s'est soldé par un échec. JKB
Seb a écrit :
Bonjour Pascal,
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée.
Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .
Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée. Si j'appelle sur une machine en Debian 9 apt-cache search linux-image je ne vois pas de noyau 3.16 . Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de solution packagée indiquée; d'un autre côté, elle ne mentionne pas non plus les backports pour avoir, au contraire, un noyau plus récent. Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire ça, cela s'est soldé par un échec. JKB
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour,
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer la performance des disques avec cette nouvelle situation. Voici le résultat: https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png
Bon... Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12). Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau. Cordialement, JKB
Seb a écrit :
Bonjour,
Pour finir, je sais obtenir un retour a des performances normales en
vidant le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un
certain temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9
stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à
mesurer la performance des disques avec cette nouvelle situation. Voici
le résultat:
https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png
Bon...
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée et le chipset (ou le contrôleur disque). C'est un point à ne
pas négliger d'autant que je vois pae dans le nom du noyau.
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer la performance des disques avec cette nouvelle situation. Voici le résultat: https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png
Bon... Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12). Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau. Cordialement, JKB
Pascal Hambourg
Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans sources.list et forcer l'installation du paquet de jessie avec apt-get -t jessie...
En fait même pas besoin de forcer puisque le paquet n'existe pas dans stretch.
Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans
sources.list et forcer l'installation du paquet de jessie avec apt-get
-t jessie...
En fait même pas besoin de forcer puisque le paquet n'existe pas dans
stretch.
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans sources.list et forcer l'installation du paquet de jessie avec apt-get -t jessie...
En fait même pas besoin de forcer puisque le paquet n'existe pas dans stretch.
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1776380740-1507195388=:17980 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer quelle serait la bonne commande ?
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors de l'installation de Debian et je ne sais pas dans quelle mesure on peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive
souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb
mais il ne s'installe pas sur un système en 64 bits.)
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors
de l'installation de Debian et je ne sais pas dans quelle mesure on peut
espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1776380740-1507195388=:17980 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer quelle serait la bonne commande ?
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors de l'installation de Debian et je ne sais pas dans quelle mesure on peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Je l'avais fait quand Debian 9 stretch était encore en testing, peu avant sa publication en stable. Pas de problème particulier, sauf avec le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce modèle de GPU, l'initialisation du module radeon semblait ne pas aller à son terme (il manquait des messages dans les logs du noyau) et l'affichage se coupait. Pourtant le même noyau 3.16 initialisait correctement le GPU même sans firmware avec le userland de Debian 8 jessie. Le dernier message du module radeon dans les logs du noyau parlant de "user helper", il se peut fort bien que ce soit effectivement une incompatibilité avec la version de systemd/udev de stretch. Aucun problème en revanche si le firmware était présent, ni avec le noyau 4.9 de stretch avec ou sans firmware.
Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :
Seb a écrit :
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.
Je l'avais fait quand Debian 9 stretch était encore en testing, peu
avant sa publication en stable. Pas de problème particulier, sauf avec
le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce
modèle de GPU, l'initialisation du module radeon semblait ne pas aller à
son terme (il manquait des messages dans les logs du noyau) et
l'affichage se coupait. Pourtant le même noyau 3.16 initialisait
correctement le GPU même sans firmware avec le userland de Debian 8
jessie. Le dernier message du module radeon dans les logs du noyau
parlant de "user helper", il se peut fort bien que ce soit effectivement
une incompatibilité avec la version de systemd/udev de stretch. Aucun
problème en revanche si le firmware était présent, ni avec le noyau 4.9
de stretch avec ou sans firmware.
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.)
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Je l'avais fait quand Debian 9 stretch était encore en testing, peu avant sa publication en stable. Pas de problème particulier, sauf avec le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce modèle de GPU, l'initialisation du module radeon semblait ne pas aller à son terme (il manquait des messages dans les logs du noyau) et l'affichage se coupait. Pourtant le même noyau 3.16 initialisait correctement le GPU même sans firmware avec le userland de Debian 8 jessie. Le dernier message du module radeon dans les logs du noyau parlant de "user helper", il se peut fort bien que ce soit effectivement une incompatibilité avec la version de systemd/udev de stretch. Aucun problème en revanche si le firmware était présent, ni avec le noyau 4.9 de stretch avec ou sans firmware.
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer quelle serait la bonne commande ?
lspci par exemple.
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors de l'installation de Debian et je ne sais pas dans quelle mesure on peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Aïe...
Bien cordialement, JKB
Seb a écrit :
Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur
un système 64 bits ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité
accrue.
et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?
lspci par exemple.
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée
lors de l'installation de Debian et je ne sais pas dans quelle mesure on
peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
et le chipset (ou le contrôleur disque). C'est un point à ne pas négliger d'autant que je vois pae dans le nom du noyau.
Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer quelle serait la bonne commande ?
lspci par exemple.
Avec un init systemV, c'est assez trivial. Avec la grouille systemd/udev, c'est assez casse-gueule.
J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors de l'installation de Debian et je ne sais pas dans quelle mesure on peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.
Aïe...
Bien cordialement, JKB
Pascal Hambourg
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits nécessaires ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne désactivera pas PAE. C'est une option en dur dans le noyau. Pour désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre des fonctionnalités comme le NX/XD bit). Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits
sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité
accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits nécessaires ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne désactivera pas PAE. C'est une option en dur dans le noyau. Pour désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre des fonctionnalités comme le NX/XD bit). Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
BERTRAND Jo=c3=abl
Pascal Hambourg a écrit :
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits nécessaires ?
Ça coule de source. Mais à force, ledit paquet risque de demander des bibliothèques qui ne seront plus sur les versions récentes de debian...
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne désactivera pas PAE. C'est une option en dur dans le noyau. Pour désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre des fonctionnalités comme le NX/XD bit).
Je pense (mais je n'ai pas regardé, il y a longtemps que je ne bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Ça ne dépend pas des options de compilation et des scripts d'édition des liens ? Il me semble qu'il est possible de forcer la taille des pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire là-dedans. Cordialement, JKB
Pascal Hambourg a écrit :
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?
Ça coule de source. Mais à force, ledit paquet risque de demander des
bibliothèques qui ne seront plus sur les versions récentes de debian...
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement
(VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).
Je pense (mais je n'ai pas regardé, il y a longtemps que je ne
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Ça ne dépend pas des options de compilation et des scripts d'édition
des liens ? Il me semble qu'il est possible de forcer la taille des
pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je
ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire
là-dedans.
Une remarque en passant : je n'ai pas observé ce genre de chose en amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le visualisateur d'images qui a ma préférence -- geekie ne sait pas bien effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb mais il ne s'installe pas sur un système en 64 bits.)
Et en recompilant depuis les sources quitte à recompiler en 32 bits sur un système 64 bits ?
Ou en activant le multi-arch et en installant les bibliothèques 32 bits nécessaires ?
Ça coule de source. Mais à force, ledit paquet risque de demander des bibliothèques qui ne seront plus sur les versions récentes de debian...
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire installée
8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une complexité accrue.
Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne désactivera pas PAE. C'est une option en dur dans le noyau. Pour désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre des fonctionnalités comme le NX/XD bit).
Je pense (mais je n'ai pas regardé, il y a longtemps que je ne bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Ça ne dépend pas des options de compilation et des scripts d'édition des liens ? Il me semble qu'il est possible de forcer la taille des pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire là-dedans. Cordialement, JKB