[kernel 6.5] depuis chgmt kernel plus de démarrage / démarrage très long

[Rapty]

Bonjour

Depuis le passage en 6.5.2 (et maintenant 6.5.3) du kernel linux, je ne parviens plus à démarrer -en fait, je peux démarrer mais cela prends plus de 20min avec un écran statique et j'ai au départ pensé qu'il était freezé.
Lorsque je redescends en 6.4.12 (boot sur clef archiso, arch-chroot, pacman -U), le démarrage fonctionne à nouveau.

journalctl ne s'active qu'au bout de 15min, et à partir de là les messages ne pointent plus rien de particulier.

Je vais essayer de résumer ce qu'il se passe.
J'appuie sur on.
syslinux démarre, pas de prompt (normal).
syslinux termine avec le dernier message (normal):

Code : Tout sélectionner

Probing EDD (edd=off to disable)... ok

l'écran reste sur ce message pendant 5 min (> pas normal à partir de là)
Puis apparaît une suite d'une dizaine de messages rapides : (je n'en recopie qu'un)

Code : Tout sélectionner

[   245.378467] INFO: task kworker/u2:9:78 blocked for more than 122 seconds.
 [   245.378527]    Not tainted 6.5.3-arch1-1 #1
 [   245.378583] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

l'écran reste statique sur ces messages pendant plus de 10 min
l'écran devient noir
l'écran reste noir quelques minutes
GDM apparait (> à partir de là, les choses semblent normales)

Je ne sais pas si je suis le seul dans cette situation, si j'ai une mauvaise configuration qui s'est faite par ailleurs et qui depuis empêche les kernels suivant de démarrer (c'est à dire: à l'époque de 6.4.12 la configuration était bonne et c'est ce qui me permet de redescendre à ce kernel là d'une certaine façon ?) ou si ça vient purement et simplement d'une nouveauté de la branche 6.5

le fallback kernel ne fait rien de mieux.

merci pour votre support

[benjarobin]

Bonjour,
Avec le peu de log que tu as donné, tu as un bug kernel.
Pour y voir plus clair, peux tu donner l'intégrité du log du boot ? La sortie complète (en root) via "journalctl -b" redirigée vers un fichier

[Rapty]

ci-joint
(le démarrage réel était à 09:30:00)

https://textup.fr/731238Yx

[laurent85]

Bonjour,
Les symptômes font penser à un bug entre le noyau Linux et le bios de la machine. Vérifie que le bios est à jour.

sept. 21 09:45:57 A300 /usr/lib/gdm-x-session[449]: Kernel command line: BOOT_IMAGE=../vmlinuz-linux root=/dev/sda1 rw ipv6.disable=1 nvidia_drm.modeset=1 nosmp=1 initrd=../intel-ucode.img,../initramfs-linux.img

Pourquoi le paramètre nosmp=1 ? ça désactive le multiprocesseur et l' IO APIC.
Supprime ce paramètre.

[Rapty]

Pourquoi le paramètre nosmp=1 ? ça désactive le multiprocesseur et l' IO APIC.

Exact. C'est parce que je tentais de voir si j'étais dans le cas là (à ce moment là):
https://bbs.archlinux.org/viewtopic.php?id=288855
mais au final non. Avec un ou tous, ça fait la même chose...

Depuis j'ai fait un démarrage sans (j'ai les logs si vous le souhaitez mais il me semble que ça ne change pas beaucoup).
Puis j'ai refait un démarrage et là ça ne démarre plus du tout (plus d'une demi heure sans rien).
Ah et je n'ai pas dit mais la machine ne peut plus s’éteindre. Elle atteint l'éteint "power off" mais elle reste allumée dessus.
Je suis revenu sur le 6.4.12 (qui s'allume et qui s'éteint) pour vous répondre.

Les symptômes font penser à un bug entre le noyau Linux et le bios de la machine. Vérifie que le bios est à jour.

Ok mais mon BIOS n'est plus mis à jour depuis longtemps.
Du coup, je suis arrivé au terme du voyage c'est ça ?
je suis bridé aux kernels 6.4 ?
Dans ce cas, est-il préférable de basculer sur le (plus ancien) linux-lts mais potentiellement qui sera plus à jour en sécurité ?

En tous cas, merci pour vos retours.

[laurent85]

lts intègre les correctifs de sécurité. Si ton matériel fonctionne avec lts il n'y a pas de souci à se faire.

mais je me pose la question qu'elle procédure tu suis pour passer de 6.4.12 à 6.5.3 et inversement pour booter ?

[Rapty]

Pour monter en version, c'est le chemin normal:

Code : Tout sélectionner

# pacman -Syu
:: Synchronisation des bases de données de paquets…
 core est à jour
 extra est à jour
 multilib est à jour
:: Début de la mise à jour complète du système…
résolution des dépendances…
recherche des conflits entre paquets…

Paquets (2) linux-6.5.4.arch2-1  linux-headers-6.5.4.arch2-1

Taille totale du téléchargement :  151,97 MiB
Taille totale installée :          251,07 MiB
Taille de mise à jour nette :      -34,07 MiB

:: Procéder à l’installation ? [O/n] O

(au passage je vois le 6.5.4 qu'il va me falloir essayer)
Puis reboot.
> kernel 6.5.3 qui tente de démarrer

Pour redescendre ;
boot sur clef archiso (une ancienne, pas forcément à jour, qui a un kernel 5.)
montage de la racine
arch-chroot dessus
Je vais dans le répertoire cache de pacman

Code : Tout sélectionner

# pacman -U linux-headers-6.4.12.arch1-1-x86_64.pkg.tar.zst linux-6.4.12.arch1-1-x86_64.pkg.tar.zst

Puis reboot.
> kernel 6.4.12 qui démarre parfaitement

est ce que ça peut etre une mauvaise conf mkinit par exemple ? cela m’empêcherait de générer la conf de nouveaux kernel mais ça fonctionnerait pour 6.4.12 car je retombe sur la conf effectuée à une époque précédente où ça allait ?

Code : Tout sélectionner

# cat /etc/mkinitcpio.conf | grep -v "#"
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
BINARIES=()
FILES=()
HOOKS=(base udev autodetect modconf keyboard keymap consolefont block filesystems fsck)

je tente le nouveau kernel 6.5.4 de ce pas. Si je ne réponds pas dans la foulée c'est qu'il ne démarre pas

[laurent85]

Ok
As-tu essayé linux-lts ?

ci-joint
(le démarrage réel était à 09:30:00)

https://textup.fr/731238Yx

Les logs fournis de 6.5.3 il manque le début des logs entre la version du kernel et le démarrage de journald, exemple la 1ère ligne de mes logs :

Code : Tout sélectionner

journalctl -b | head -n1
sept. 22 08:28:02 archiso kernel: Linux version 6.4.12-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Thu, 24 Aug 2023 00:38:14 +0000

[Rapty]

As-tu essayé linux-lts ?

- Linux 6.5.4 : KO
- Linux 6.1.54-1-lts : OK

Les logs fournis de 6.5.3 il manque le début des logs entre la version du kernel et le démarrage de journald, exemple la 1ère ligne de mes logs :

Code : Tout sélectionner

journalctl -b | head -n1
sept. 22 08:28:02 archiso kernel: Linux version 6.4.12-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Thu, 24 Aug 2023 00:38:14 +0000

Yeap je suis d'accord, rien à voir non plus avec les logs du "bon démarrage" avec le kernel 6.4.12 pour moi.
Je pense que le fait que journald commence 15min plus tard aide pas, d'ailleurs il est dit dès le début:

Code : Tout sélectionner

Missed 1312 kernel messages

Puis le reste est une cacophonie sans nom (tout dans la même milliseconde).

Le fait que linux-lts démarre alors que c'est la première fois que je l'instancie me fait dire que ce n'est pas une histoire d'environnement mais bien de kernel.
Dommage, archiso est actuellement en 6.4.12 donc je ne peux pas voir le boot d'un live.
Il va me falloir trouver une autre distrib qui a un live en 6.5.x et booter pour définitivement confirmer que ça vient du kernel et pas de l'installation (mais j'en suis déjà assez convaincu maintenant).
Edit: Fedora 39 avec linux 6.5 vient de sortir en beta juste hier, c'est nickel !

[laurent85]

que c'est la première fois que je l'instancie me fait dire que ce n'est pas une histoire d'environnement mais bien de kernel.

un bug avec le bios de cette machine a mon avis.

Il va me falloir trouver une autre distrib qui a un live en 6.5.x et booter pour définitivement confirmer que ça vient du kernel et pas de l'installation (mais j'en suis déjà assez convaincu maintenant).
Edit: Fedora 39 avec linux 6.5 vient de sortir en beta juste hier, c'est nickel !

Prends une iso archuseriso ici http://dl.gnutux.fr/archuseriso/iso/fr_FR/

[Rapty]

Prends une iso archuseriso ici http://dl.gnutux.fr/archuseriso/iso/fr_FR/

Merci! je ne connaissais pas.
Le LIVE a exactement le même problème que mon installation.
Elle est donc plus ou moins innocentée

un bug avec le bios de cette machine a mon avis.

Ok mais un bug seulement avec la branche 6.5 ?
Il doit y avoir une amélioration qui ne passe pas (le multi CPU en parallèle ? non j'ai déjà essayé sans).
Ou alors mon vieux matériel vient de perdre son support ?
Ou alors un bug pur et dur ?

Faut-il que je déclare ce problème au gens du kernel ?
https://wiki.archlinux.org/title/Kernel ... egressions
A priori il faut d'abord que j'essaie avec la version vanilla sans patch avant de les solliciter.

[laurent85]

Signale d'abord le problème sur le forum anglais d'Arch. Est-ce que tu as pu tester la fedora beta ?

C'est quoi comme matériel ?

Peut être ce bug https://bbs.archlinux.org/viewtopic.php?id=288855

[benjarobin]

Pour avoir le début des logs, c'est assez facile, ajoute ceci aux paramètres kernel

Code : Tout sélectionner

log_buf_len=16M

[Rapty]

Est-ce que tu as pu tester la fedora beta ?

même problème

C'est quoi comme matériel ?

Carte mère Gigabyte Technology Co., Ltd. P55A-UD3
BIOS F11 08/11/2010 (dernier en date)
Processeur Intel® Core™ i5 760 × 4

Signale d'abord le problème sur le forum anglais d'Arch.

Ok je vais le faire

Peut être ce bug https://bbs.archlinux.org/viewtopic.php?id=288855

C'est celui que je suivais avant d'ouvrir ce sujet, et la raison pour laquelle j'avais nosmp=1.
Il y a beaucoup de point commun et des points pas communs, je vais essayer de clarifier avec eux si on a la même chose.

Pour avoir le début des logs, c'est assez facile, ajoute ceci aux paramètres kernel

Code : Tout sélectionner

log_buf_len=16M

https://pastebin.com/j70gFEFk
Merci, cette fois il y a bien le début, mais je trouve rien de spectaculaire.

[laurent85]

Dans les logs ça plante :

sept. 23 10:31:38 A300 kernel: INFO: task swapper/0:1 blocked for more than 122 seconds.
sept. 23 10:31:38 A300 kernel: Not tainted 6.5.4-arch2-1 #1
sept. 23 10:31:38 A300 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sept. 23 10:31:38 A300 kernel: task:swapper/0 state:D stack:0 pid:1 ppid:0 flags:0x00004002
sept. 23 10:31:38 A300 kernel: Call Trace:
sept. 23 10:31:38 A300 kernel: <TASK>
sept. 23 10:31:38 A300 kernel: __schedule+0x3e8/0x1410
sept. 23 10:31:38 A300 kernel: schedule+0x5e/0xd0
sept. 23 10:31:38 A300 kernel: async_synchronize_cookie_domain+0x118/0x160
sept. 23 10:31:38 A300 kernel: ? __pfx_autoremove_wake_function+0x10/0x10
sept. 23 10:31:38 A300 kernel: ? __pfx_kernel_init+0x10/0x10
sept. 23 10:31:38 A300 kernel: kernel_init+0x1f/0x1c0
sept. 23 10:31:38 A300 kernel: ret_from_fork+0x34/0x50
sept. 23 10:31:38 A300 kernel: ? __pfx_kernel_init+0x10/0x10
sept. 23 10:31:38 A300 kernel: ret_from_fork_asm+0x1b/0x30
sept. 23 10:31:38 A300 kernel: </TASK>
sept. 23 10:31:38 A300 kernel: INFO: task kworker/u16:3:77 blocked for more than 122 seconds.
sept. 23 10:31:38 A300 kernel: Not tainted 6.5.4-arch2-1 #1
sept. 23 10:31:38 A300 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sept. 23 10:31:38 A300 kernel: task:kworker/u16:3 state:D stack:0 pid:77 ppid:2 flags:0x00004000
sept. 23 10:31:38 A300 kernel: Workqueue: events_unbound async_run_entry_fn
sept. 23 10:31:38 A300 kernel: Call Trace:
sept. 23 10:31:38 A300 kernel: <TASK>
sept. 23 10:31:38 A300 kernel: __schedule+0x3e8/0x1410
sept. 23 10:31:38 A300 kernel: schedule+0x5e/0xd0
sept. 23 10:31:38 A300 kernel: async_synchronize_cookie_domain+0x118/0x160
sept. 23 10:31:38 A300 kernel: ? __pfx_autoremove_wake_function+0x10/0x10
sept. 23 10:31:38 A300 kernel: async_port_probe+0x69/0x70
sept. 23 10:31:38 A300 kernel: async_run_entry_fn+0x34/0x130
sept. 23 10:31:38 A300 kernel: process_one_work+0x1e1/0x3f0
sept. 23 10:31:38 A300 kernel: worker_thread+0x51/0x390
sept. 23 10:31:38 A300 kernel: ? __pfx_worker_thread+0x10/0x10
sept. 23 10:31:38 A300 kernel: kthread+0xe8/0x120
sept. 23 10:31:38 A300 kernel: ? __pfx_kthread+0x10/0x10
sept. 23 10:31:38 A300 kernel: ret_from_fork+0x34/0x50
sept. 23 10:31:38 A300 kernel: ? __pfx_kthread+0x10/0x10
sept. 23 10:31:38 A300 kernel: ret_from_fork_asm+0x1b/0x30
sept. 23 10:31:38 A300 kernel: </TASK>

Le flot de message concernant ata14, je ferais ces tests. Débrancher disques et lecteur dvd. Puis booter sur le live linux 6.5.4. Et si ça boote procéder par élimination pour identifier le responsable du bug. Recharger aussi les valeurs par défaut du bios pour le réinitialiser.

Attention au remontage le paramètre de boot root=/dev/sda1, il faut mettre l'uuid de sda1 de cette façon root=UUID=fdfbf9f7-67c1-4757-9ae1-78a6a9d05f48 pour éviter une erreur d'identifiant au démarrage.

Et tant que ça marche avec lts autant rester dessus en attendant un correctif.

[Rapty]

Merci laurent85 pour ces pistes.
J'ai essayé le BIOS pour commencer: il y a un paramètre "reset to failsafe defaults" et cela me semblait pertinent.
> le live ne boot toujours pas.

Par contre, plus rien ne bootait ensuite. Si j'ai bien compris ça a désactivé pas mal de chose (contrôleur SATA, contrôleur réseau) et il m'a fallu un peu de temps pour retrouver une situation normale (je ne suis pas sur d'avoir tout retrouvé, notamment l'USB3).
Je ferai l'expérience du débranchement plus tard.

Pour le ata14 qui génère tant de message en 6.5, je crois que c'est la partie RAID du contrôleur SATA de la carte mère.
RAID que je n'utilise pas: ça explique pourquoi peut être, pour moi, 6.5 finit par booter avec un fonctionnement presque normal.
Cela ne se désactive pas plus qu'il ne l'est déjà, je suis obligé de vivre avec.

Dans les expériences qu'il me reste à faire :
- forçage du mode IDE du BIOS: ok je vais perdre (temporairement) mes partitions mais peut être le live USB pourra booter sans SATA
- débrancher physiquement le matériel

[laurent85]

Pour le ata14 qui génère tant de message en 6.5, je crois que c'est la partie RAID du contrôleur SATA de la carte mère.

Il y a 2 contrôleurs sata sur cette carte mère, j'ai consulté la doc https://download1.gigabyte.com/Files/Ma ... 166895af16

6 ports sata pour le contrôleur P55 Intel et 2 ports sata pour le contrôleur Marvell 9128. Je désactiverais le contrôleur Marvell et je n'utiliserais pas ses ports.

5-1-2 Configuring Marvell 9128 SATA Controller
A. Installing SATA hard drive(s) in your computer
...
Make sure GSATA Controller under the Integrated Peripherals menu is enabled.

Le mettre sur disabled

Je mettrais aussi le mode exotique eXtreme Hard Drive (XHD) sur disabled
Et le mode du contrôleur Intel la ligne PCH SATA Control Mode sur AHCI

[Rapty]

Tout d'abord: merci. Encore, merci !
Ton aide est vraiment précise (et documentée) !
Cela m'a aidé à retrouver des options correctes dans le BIOS.

Du coup j'ai mis

Code : Tout sélectionner

eXtreme Hard Drive (XHD) disabled
PCH SATA Control Mode AHCI
GSATA Controller disabled

ça ne fait pas de mal, vu que je n'utilise pas ces fonctions.
Malheureusement, 6.5 ne démarre pas plus.
Il y a un message en particulier

Code : Tout sélectionner

ata2: softreset failed (1st FIS failed)

qui me fait dire qu'il n'y a pas que ata14 qui pose problème...

pour le moment, je vis avec lts. Au final, ça fonctionne très très bien et pour le moment, il est mis à jour.
Alors, je peux patienter.

merci encore

[Rapty]

Problème résolu depuis Linux 6.5.6-arch2-1

merci !