Bonjour,
Ce fil a été extrait d'un autre fil afin de traiter de manière plus générale un problème récurrent ces derniers temps
Symptômes :
- Le disque dur, plus précisément la racine, se remplit très vite. Suite aux mises à jour de juin-juillet 2018, sur la 16.04 (xenial), certains ont remonté une vitesse de remplissage de l'ordre de 30Go en quelques dizaines de minutes. 18.04 (Bionic) est également touchée (souvent elle ne démarre même pas, restant bloqué dans la séquence de boot)
- une analyse du disque dur montre que le répertoire /var et en particulier /var/log sont très volumineux. 2 fichiers (et leurs archives) sont mis en cause : /var/log/kern.log et /var/log/syslog
- l'analyse de ce que remonte le noyau montre qu'un message récurrent est envoyé et c'est celui-ci que l'on retrouve dans les logs
- l'analyse de la machine montre que c'est un des bridges pci qui génère le message d'erreur, et jusqu'à présent, il se trouve que c'est le bridge sur lequel est connecté la carte WIFI
Situation actuelle / solution de contournement
La solution de contournement est aujourd'hui de passer un paramètre au noyau. Il existe plusieurs paramètres possibles dont principalement :
- pci=noaer (le plus utilisé)
- pcie_aspm=off
Aucun des 2 n'est idéal :
pci=noaer masque le problème en demandant au noyau de ne plus remonter certaines erreurs (NO Advanced Error Reporting)
pcie_aspm=off traite le bug au plus proche de la source, mais désactive la gestion avancée de l'alimentation, réduisant l'autonomie sur les ordinateurs portables.
AJOUT : en fait; pcie_aspm=off désactive l'AER et donc à le même effet que noaer, en ayant un effet de bord sur la consommation (et donc l'autonomie de portable) FIN AJOUT
Mise en place de ces paramètres (exemple avec pci=noaer) :
Dans un shell d'une session normale :
sudo cp /etc/default/grub /etc/default/grub.old
sudo nano /etc/default/grub
sur la ligne GRUB_CMDLINE_LINUX_DEFAULT, ajouter pci=noaer
Ca doit donner quelque chose comme
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer"
sauvegarder (ctrl o)
Entrée
quitter (ctrl x)
sudo update-grub
reboot
Lorsque le disque dur et plein ou presque plein, il faut vider les logs avec la procédure suivante :
echo | sudo tee /var/log/kern.log.*
echo | sudo tee /var/log/syslog.*
sudo logrotate --force /etc/logrotate.conf
echo | sudo tee /var/log/kern.log.1
echo | sudo tee /var/log/syslog.1
Si le système est bloqué :
Il faut booter sur une session live et vider les logs
Puis booter une session normale en passant un paramètre à la volée
Et valider en dur ce paramètre
Pour booter en session live, il peut être nécessaire de passer également un paramètre (si celle-ci ne démarre pas)
Exemple pour une session efi (la procédure est similaire pour une session legacy, sans le terme efi)
Rebooter sur une session live (Essayer sans installer), en mettant le support d'installation. Dès que grub apparaît (soit sur cet
écran ou
celui-ci, appuyer sur 'e'
- descendre avec les touches (curseur) jusqu'à tomber sur
Linux /casper/vmlinuz.efi...
- avec le curseur, le déplacer pour le mettre après splash.
- écrire "pci=noaer" entre splash et la fin (---), avec un espace entre splash et pci... et un espace entre aer et ---. Remarque, il n'y a aucun espace dans pci=noaer (quand le clavier est un clavier AZERTY il faut taper
pci=noqer pour que s'affiche
pci=noaer)
- Bien vérifier que c'est pci=noaer qui s'affiche
- valider par F10
Pour vider les logs avec la session live, il faut identifier la partition sur laquelle se trouve la racine (dans cet exemple sda5), et la monter :
sudo mkdir /mnt/5
sudo mount /dev/sda5 /mnt/5
et appliquer la procédure pour vider les logs en remplaçant
/var/log par
/mnt/5/var/log
Dans un tel cas, il est préférable de rebooter la session normale en passant le même paramètre à la volée. La procédure est la même que pour une session live. Pour faire apparaître GRUB dans le cas d'une machine avec un seul OS, appuyer sur Echap en continue dès le reboot de celle-ci. Ensuite, il suffit d'appliquer la procédure de mise en place d'un paramètre.
===================================Explications plus détaillées===================================
Analyse :
Exemple d'analyse du disque dur, à partir d'une session live :
Commande :
sudo du -am --max-depth=1 / 2>/dev/null | sort -n
Réponse
(dans cet exemple, la racine a été étudiée à partir d'une session live, montée sur /mnt/5):
4 /lib32
4 /mnt/5/lib32
13 /mnt/5/bin
13 /mnt/5/sbin
14 /mnt/5/etc
211 /mnt/5/boot
237 /mnt/5/home
1035 /mnt/5/lib
4383 /mnt/5/usr
31289 /mnt/5/var
37196 /mnt/5
Exemple d'analyse de /var/log :
Commande :
ls -lAs /var/log | sort -n | tail -14
Réponse
(dans cet exemple, /var/log a déjà été partiellement nettoyé en vidant kern.log.1 et syslog.1):
108 -rw-rw-r-- 1 root utmp 106368 juil. 16 11:37 wtmp.1
116 -rw-r--r-- 1 root root 117079 juil. 28 16:47 dpkg.log
132 -rw-r--r-- 1 root root 132709 nov. 26 2017 dpkg.log.8.gz
640 -rw-r----- 1 syslog adm 653971 juil. 24 15:12 syslog.4.gz
40420 -rw-r----- 1 syslog adm 41388600 juil. 21 18:28 syslog.6.gz
138892 -rw-r----- 1 syslog adm 142220179 juin 24 15:34 kern.log.3.gz
170356 -rw-r----- 1 syslog adm 174439908 juil. 23 12:09 syslog.5.gz
183356 -rw-r----- 1 syslog adm 187755849 juil. 20 14:20 syslog.7.gz
242488 -rw-r----- 1 syslog adm 248306250 juil. 25 14:24 syslog.3.gz
722900 -rw-r----- 1 syslog adm 740243542 juil. 16 23:22 kern.log.2.gz
1193692 -rw-r----- 1 syslog adm 1222330432 juil. 26 11:44 syslog.2.gz
1262356 -rw-r----- 1 syslog adm 1292646727 juin 21 19:58 kern.log.4.gz
16989564 -rw-r----- 1 syslog adm 17397285055 juil. 29 15:40 syslog
78035144 -rw-r----- 1 syslog adm 79907880960 juil. 29 15:23 kern.log
Exemple de message répétitif :
Commande
dmesg -lerr | tail -20
Extrait de la réponse
[ 3200.937935] pcieport 0000:00:1c.4: device [8086:9d14] error status/mask=00000001/00002000
[ 3200.937950] pcieport 0000:00:1c.4: [ 0] Receiver Error (First)
[ 3200.938659] pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e4(Receiver ID)
Analyse avancée :
Exemple d'analyse de la machine :
L'erreur détectée par dmesg montre :
pcieport 0000:00:1c.4
La commande
sudo lshw
montre (extrait de la partie intéressante) :
*-pci:1
description: PCI bridge
produit: Sunrise Point-LP PCI Express Root Port #5
fabriquant: Intel Corporation
identifiant matériel: 1c.4
information bus: pci@0000:00:1c.4
version: f1
bits: 32 bits
horloge: 33MHz
fonctionnalités: pci pciexpress msi pm normal_decode bus_master cap_list
configuration: driver=pcieport
ressources: irq:16 portE/S:4000(taille=4096) mémoire:a4500000-a45fffff
*-network
description: Interface réseau sans fil
produit: RTL8723BE PCIe Wireless Network Adapter
fabriquant: Realtek Semiconductor Co., Ltd.
identifiant matériel: 0
information bus: pci@0000:02:00.0
nom logique: wlp2s0
version: 00
numéro de série: 18:4f:32:63:27:03
bits: 64 bits
horloge: 33MHz
fonctionnalités: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=rtl8723be driverversion=4.15.0-29-generic firmware=N/A latency=0 link=no multicast=yes wireless=IEEE 802.11
ressources: irq:16 portE/S:4000(taille=256) mémoire:a4500000-a4503fff
Associant le slot pcie 1c.4 (dans cet exemple) au WIFI.
lspci -vv
montre (toujours dans cet exemple, extrait de la partie intéressante) :
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
Subsystem: Hewlett-Packard Company RTL8723BE PCIe Wireless Network Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 4000 [size=256]
Region 2: Memory at a4500000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: rtl8723be
Kernel modules: rtl8723be
Dans ce cas, le mis en cause est le rtl8723be
Finalité/Etape suivante
Comme indiqué au sujet des paramètres, le problème est contourné à ce jour, avec des conséquences.
L'objectif est d'essayer de trouver une solution technique qui traite complètement (ou mieux à défaut) ce problème. Ca passe probablement par le driver de la carte WIFI, soit par un paramètre, soit par une modification de son code.
L'analyse des développeurs sur le driver github du rtl8723be a mis en évidence un bug en relation avec l'ASPM. A ce jour la validité de la correction n'a pas été prouvé.
De même, il est prouvé que le rtl8723be pose problème. l'ath10k en pose également, dans une moindre mesure (l'erreur existe, mais ne remplit pas les logs autant que pour le rtl8723be). Cette liste n'est pas exhaustive.
Votre contribution est la bien venue pour identifier les composants qui posent problème, valider la/les solutions de contournement et valider la correction si celle-ci est identifiée
