Neuer kernel bremst beim starten maximal.

[bastler]

Hallo erstmal.
ich suche schon seit paar Tagen. seit der Aktualisierung des kernels. auf 6.6.300 friert der beim starten immer ca 1 minute ein. Also, beim starten kommt die Meldung das die Ramdisk geladen wird. Dann passiert ca 1 minute gar nichts. Kein Festplattenbewegung, nichts alles wie eingefroren.
nach dieser Zeit erfolgt der weitere Start völlig normal ohne Probleme, es funktioniert auch alles. Probehalber den 120 er kernel gestartet, alles normal. Kernel 130 entfernt und neu installiert. das gleiche Problem.
Keine Fehlermeldungen im log.
das system:
Betriebssystem: Mageia 9
KDE-Plasma-Version: 5.27.10
KDE-Frameworks-Version: 5.114.0
Qt-Version: 5.15.7
Kernel-Version: 6.6.120-desktop-1.mga9 (64-bit)
Grafik-Plattform: X11
Prozessoren: 12 × AMD Ryzen 5 3600 6-Core Processor
Speicher: 15,5 GiB Arbeitsspeicher
Grafikprozessor: llvmpipe

Ist da irgendwas bekannt?
Hersteller: Gigabyte Technology Co., Ltd.
Produktname: B450M S2H V2

[doktor5000]

Ahoi, ich sehe keinen Bugreport dazu und auch sonst keine Meldung. Weil du schreibst wenn die Ramdisk geladen wird - hast du mal versucht die initrd neu schreiben zu lassen für 6.6.130 mittels dracut ? Sollte gehen mittels

Code: Alles auswählen

dracut --kver 6.6.130-desktop-1.mga9

[bastler]

Danke für den tip. aber da kommt
dracut: Will not override existing initramfs (/boot/initrd-6.6.130-desktop-1.mga9.img) without --force
Hat der nun oder nicht ist hier die Frage. Oder soll ich die erstmal mit der Hand löschen?

[doktor5000]

dracut: Will not override existing initramfs (/boot/initrd-6.6.130-desktop-1.mga9.img) without --force

Nein hat er nicht, die Meldung ist doch relativ eindeutig. Ob du nun --force machst oder manuell löschst kommt auf das gleiche hinaus.

[bastler]

Also habe es mit force probiert. ja da lief was durch. aber Ergebnis. gleich null. der Fehler ist bei diesem Kernel wieder da. Auch eine Neuinstallation von dem Kernel brachte nichts.
spaßeshalber mal den Repraturmodus des Kernles gestartet. Komisch der läuft durch. bis str D. und dann startet alles Normal.
Es ist so als wäre da ein Treiber im Kernel der im Rechner nicht existiert und er wartet das timeaut ab. Aber das ist nur spekulativ eines alten Mannes.
beim 120 er Kernel weiter ohne Probleme.

[jkowalzik]

Ahoi, ich sehe keinen Bugreport dazu und auch sonst keine Meldung.

Hallo!
Das muss ein Fehler sein, der nur deine Hardware/Einstellung betrifft.
Bei mir läuft ein Laptop AMD Ryzen7
....................Laptop i5 Intel
und...............Desktop AMD Bulldozer
ohne Probleme mit dem Kernel

Code: Alles auswählen

[juergen@localhost ~]$ uname -a
Linux localhost 6.6.130-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Thu Mar 26 01:48:01 UTC 2026 x86_64 GNU/Linux

Ansonsten:
"don't worry, be happy" -- "always look on the bright side of life"
manchmal verschwinden solche Fehler so, wie sie gekommen sind.

Gruß
J.

[bastler]

Ich warte ja auf die freihabe der M10. wahrscheinlich ist dann alles weg. Komisch nur, wen ich den Repraturmodus starte dann geht alles normal schnell bis zu str.D. und ab da auch alles normal bis zur Anmeldung.
Habe nochmals den kompletten Kernel samt dazugehöriger Pakete entfernt und neu geladen alles so wie beim ersten mal auch das mit --force hat nicht geholfen obwohl er da was gemacht hat.

[doktor5000]

Was siehst du denn im journal-Log für den Zeitraum wo es hängt, wenn du mit der Verzögerung bootest und ggf. das Loglevel ein bißchen erhöhst ? Folgende Bootoptionen anhängen für mehr Logs:

Code: Alles auswählen

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on

[bastler]

Sorry, momentan wenig Zeit. Meine Frau wird am Mittwoch operiert. sieht nicht gut aus. Aber zum Thema. Ich bekomme das als Antwort.
bash: systemd.log_level=debug: Kommando nicht gefunden.

[doktor5000]

Das sind Bootoptionen für den Kernel, keine Befehle. Siehe auch https://wiki.mageia.org/en/Wie_man_Kern ... nstellt-de

[bastler]

Ups da steht bei mir einen Haufen drin. Gestern-heute auch neuen Kernel installiert. Hier mal die Meldungen des Kernels von heute:

Code: Alles auswählen

May  5 00:07:31 localhost kernel: [ 5835.483968] AMD-Vi: Completion-Wait loop timed out
May  5 00:07:46 localhost kernel: [ 5850.874694] AMD-Vi: Completion-Wait loop timed out
May  5 00:14:43 localhost kernel: [ 6267.508111] AMD-Vi: Completion-Wait loop timed out
May  5 00:15:24 localhost kernel: [ 6308.742908] AMD-Vi: Completion-Wait loop timed out
May  5 00:17:44 localhost kernel: [ 6448.843057] AMD-Vi: Completion-Wait loop timed out
May  5 00:19:33 localhost kernel: [ 6557.588798] AMD-Vi: Completion-Wait loop timed out
May  5 00:24:43 localhost kernel: [ 6868.042519] AMD-Vi: Completion-Wait loop timed out
May  5 00:28:37 localhost kernel: [  136.833750] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 08:56:51 localhost kernel: [  136.867314] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 08:57:11 localhost kernel: [  159.757854] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 08:57:11 localhost kernel: [  159.783847] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 08:57:11 localhost kernel: [  160.318861] nouveau 0000:0a:00.0: msvld: unable to load firmware data
May  5 08:57:11 localhost kernel: [  160.318865] nouveau 0000:0a:00.0: msvld: init failed, -19
May  5 09:59:35 localhost kernel: [  284.082102] AMD-Vi: Completion-Wait loop timed out
May  5 10:14:12 localhost kernel: [    5.483587] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
May  5 10:14:12 localhost kernel: [  136.368119] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 10:14:37 localhost kernel: [  165.620006] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 10:14:37 localhost kernel: [  165.644004] usb 1-3.4: 3:1: cannot get freq at ep 0x84
May  5 10:14:37 localhost kernel: [  166.088125] nouveau 0000:0a:00.0: msvld: unable to load firmware data
May  5 10:14:37 localhost kernel: [  166.088129] nouveau 0000:0a:00.0: msvld: init failed, -19

eventuell hilft das . was soll ich abschalten?

[doktor5000]

Nur die Meldungen vom kernel sind etwas wenig. Du solltest schon noch dazuschreiben wann die Kiste gebootet wurde und wo die Wartezeit auftritt, damit man das mit dem Log korrelieren kann.

Für die AMD-Vi Meldungen: entweder UEFI/BIOS-Update falls verfügbar.
Oder kernel-Optionen durchprobieren wie z.b.

Code: Alles auswählen

amd_iommu=off

oder

Code: Alles auswählen

iommu=soft

und schauen ob die Wartezeit immer noch da ist.

[bastler]

Ist noch da. Aber was mich wundert. wen man beim Start den re... Modus auswählt. läuft er ohne Unterbrechungen los zum str. D durch. ohne Probleme.

[doktor5000]

Ist noch da.

Das ist bissel wenig Rückmeldung auf die Vorschläge. Ohne Logs zu teilen musst du da wohl selbst herausfinden wo die Verzögerung herkommt.

Und die Unterschiede der Kernel-Optionen im Recovery-Mode kannst du jederzeit in der Bootloader-Config also z.B /boot/grub2/grub.cfg vergleichen.

[bastler]

Habe ich verglichen. Ich finde keinen Unterschied.Das ist ja das verrückte.
Welches log wird den gebraucht.

[doktor5000]

Wenn es keinen Unterschied zwischen den Optionen der Recovery-Einträge und den normalen gibt, dann ist da zum einen bei dir was kaputt,
und zum anderen sind die Einträge dann auch identisch und können sich nicht anders verhalten, die booten ja jeweils die selben Kernel.

Und zum Log - naja wie hast du das denn zuvor abgefragt ?

Hier mal die Meldungen des Kernels von heute:

Einfach der Anfang der Ausgabe als root von

Code: Alles auswählen

journalctl -ab

und dazu konkret die Info ergänzen wo die Verzögerung auftritt.