# Seit Bios Update auf F23 hängt der Kernel beim booten

## Child_of_Sun_24

Hi @all

Ich weiß im moment nicht so recht wohin ich mich mit meinem Problem wenden soll.

Hier erstmal mein System:

MB: Gigabyte AB350-Gaming

CPU: Amd Ryzen 7 2700X

GraKa: 1x Sapphire Radeon RX Vega 64 Nitro+

Ram: 4x8 GB G.Skill Ripjaws V DDR4-3200

SSD: 2x256GB Sandisk (Windows 10 x64, Spiele)

SSD: 64GB Sandisk (Gentoo Hyper-V/Nativ)

HDD: 3TB Toshiba DT01ACA3 (Datenfestplatte)

Externe HDD: 1TB Maxtor (System-Backups)

Optisch: 1x Optiarc DVD-Brenner, 1x LG BlueRay Brenner

Netzteil: Thermaltake TR2 S 700W

Kühlung: Thermaltake Water 3.0 Riing RGB 240

Seit ich das Mainboard von F23d (agesa 1.0.0.2a) auf F23 (agesa 1.0.0.4) upgedatet habe hängt jeder neuere Kernel beim Booten fest (4.16.0-4.19.0-rc3) ohne Fehlermeldung, der letzte funktionierende Kernel ist 4.15.18 (welcher mir keinen Schutz vor Spectre v4 bietet) den Kernel 4.14.67 habe ich noch nicht getestet, da der Vega support meines Wissens erst im 4.15er Kernel integriert worden ist.

Meine Frage ist jetzt wo soll ich das Problem bekanntgeben und welche Infos sind dafür nötig (dmesg log kann ich nicht liefern da der Kernel gar nicht soweit bootet er hängt sich beim oder nach dem initialisieren der Festplatten auf, wobei er mir auch keine befriedigende Antwort auf den gerade hängenden Teil gibt).

Ich hoffe mir kann hier jemand dabei Helfen die entsprechenden Infos an die richtige Stelle zu übermitteln.

----------

## mike155

Hallo Child_of_Sun_24,

bevor Du Infos oder einen Bug reportest, solltest Du versuchen herauszufinden, was genau das Problem ist. Wenn ich Dich richtig verstehe, vermutest Du das Problem bei der Vega Grafikkarte. Das ist gut möglich - aber es kann auch etwas anderes sein.

Zeigt Dein Bildschirm eine Ausgabe, bevor der Computer hängen bleibt? Wenn ja: mache ein Bildschirmphoto und poste es. Wenn Du nichts siehst, weil der Computer in den Grafikmodus schaltet und dann leer ist: verhindere das Umschalten in den Grafikmodus. Die Ausgabe des Kernels ist Gold wert!

Weiterhin kannst Du einen Kernel bauen ohne Vega Treiber und schauen, ob der Rechner dann bootet. Wenn er immer noch nicht bootet, liegt's an einem anderen Subsystem. In diesem Fall kannst Du der Reihe nach alle Subsysteme im Kernel deaktivieren, bis der Rechner bootet - dann weißt Du, wo das Problem liegt.

Sobald Du weißt, welches Subsystem Probleme bereitet, würde ich Google fragen: Du bist bestimmt nicht der Einzige, bei dem dieses Problem auftritt.

Falls Du mit Google keine Lösung findest und der Fehler reproduzierbar ist und Du noch Energie hast, kannst Du ins Kernel Bisect Business einsteigen und den Patch suchen, der das Problem verursacht. Wenn Du den Patch gefunden hast, kannst Du eine E-Mail an die Kernel Entwickler des entsprechenden Subsystems schreiben - die freuen sich über gute Fehlerreports mit Angabe des Patches - und fixen Probleme meist recht schnell.

Berichte uns von Deinen Fortschritten. Poste auch mal Deine Kernel .config (über pastebin o.ä.) Vielleicht können wir dann helfen.  :Smile: 

Mike

----------

## Child_of_Sun_24

Danke für deine schnelle Antwort, ich vermute das Problem nicht bei der Vega Grafikkarte, da es auch schon mit der RX 580 auftrat, ich mache mal ein Bildschirmfoto vom hängengebliebenen Kernel.

Hier mal meine Kernel .config:

https://bpaste.net/show/5c81ae1748f8

Bildschirmfoto:

https://www.imagebanana.com/s/1178/OynIijO0.html

*EDÌT*

Habe jetzt mal zuerst das Sata Subsystem weggelassen und danach das Usb Subsystem, er hängt immer noch, scheint so als würde er sich aufhängen bevor er mitteilt was er gerade macht.

Device-Mapper und Netzwerk können auch ausgeschlossen werden.

amdgpu und multimedia sind es auch nicht.

hid kann man auch ausschließen, teste später weiter wenn ich wieder Zeit habe  :Smile: 

gpio support, Adaptive Voltage Scaling Class Support, Voltage and Current Regulator Support können auch ausgeschlossen werden.

Hardware Monitoring support, Sound card support sinds auch net.

LED Support, EDAC (Error Detection And Correction) reporting, Real Time Clock sinds nicht.

X86 Platform Specific Device Drivers, IOMMU Hardware Support auch nicht.

Generic Dynamic Voltage and Frequency Scaling (DVFS) support, External Connector Class (extcon) support, Reliability, Availability and Serviceability (RAS) features auch nicht.

DAX: direct access to differentiated memory, Generic powercap sysfs driver sinds auch nicht.

ACPI ist es auch nicht, habe außerdem mal den Kernel 4.16-rc1 probiert das Problem besteht auch hier, also wäre es nützlich zu Wissen was zwischen 4.15.18 und 4.16-rc1 gepatcht wurde, leider finde ich kein Changelog dafür.

Habe alles unter general setup deaktiviert was ging, wars auch nicht.

Habe alles unter Memory Management options deaktiviert, wars auch nicht.

Connector - unified userspace <-> kernelspace linker, Block devices warens auch net.

SCSI device support scheint es auch nicht zu sein, kann es nicht komplett deaktivieren.

Unter Input Devices konnte ich auch nicht alles deaktivieren aber die warens auch nicht.

Habe unter Character Devices alles deaktiviert was ging, wars auch nicht.

Unter I2C support alles was ging deaktiviert wars auch nicht.

Alles unter Processor type and features deaktiviert, wars auch nicht.

Wenn ich unter Bus options (PCI etc.) den PCI Support komplett deaktiviere dann startet er, allerdings habe ich dann auf nichts zugriff er startet nur die notfall-shell meiner initrd.

Haha  :Smile:  Habe es rausgefunden  :Smile:  wenn ich die IOMMU Treiber deaktiviere kann ich unter Bus options (PCI etc.) die Message Signaled Interrupts (MSI and MSI-X) deaktivieren, sobald ich dann boote startet der Kernel ohne Probleme, habe dann halt nur keinen IOMMU Support, was aber nicht schlimm ist.

Was mache ich jetzt damit, wie kann ich die Kernel-Devs kontaktieren damit sie evtl. einen Patch dafür schreiben können ?

----------

## Child_of_Sun_24

Habe jetzt im Bugzilla von kernel.org einen Bug eröffnet:

https://bugzilla.kernel.org/show_bug.cgi?id=201115

----------

## firefly

Da es an MSI wohl hängt kannst du MSI auch per kernel commandline disablen.

Und zwar mit folgendem commandline argument:

 *Quote:*   

> pci=nomsi

 

Dann müsstest du IOMMU nicht im kernel deaktivieren, wenn es wirklich nur rein am MSI/MSI-X support hängt

----------

## mike155

Das war ja ganz schön viel Arbeit! An IOMMU hätte ich erst mal nicht gedacht... Ich finde es toll, dass Du das Subsystem gefunden hast und dass Du auch einen Fehlerreport geschrieben hast!

Wie sieht es aus mit den BIOS Einstellungen? Hast Du hier etwas besonderes konfiguriert? Oder tritt der Fehler auch mit den Default-Einstellungen auf?

Bei 4.16 gab es eine größere Änderung an den IOMMU Treibern: 5-level paging wurde eingeführt: https://lkml.org/lkml/2017/12/20/685. Ob es damit zusammenhängt?

----------

## Child_of_Sun_24

 *firefly wrote:*   

> Da es an MSI wohl hängt kannst du MSI auch per kernel commandline disablen.
> 
> Und zwar mit folgendem commandline argument:
> 
>  *Quote:*   pci=nomsi 
> ...

 

Wenn ich diese Option nutze, dann kriegt der Kernel Probleme beim booten, so wie es scheint wird der amdgpu Treiber nicht geladen, der Festplatten Treiber funktioniert nicht richtig, der Usb treiber kriegt Probleme und noch einige andere Sachen, hier mal ein Screenshot vom ende des booten:

https://www.imagebanana.com/s/1179/JV5qQ71n.html

Was dann hinterher darin endet das wieder die notfall shell der initrd geladen wird, das ganze aber ohne funktionierende Tastatur.

Das ist leider keine Lösung für das Problem.

Und ja das war ganz schön aufwendig das alles durchzutesten  :Smile: Last edited by Child_of_Sun_24 on Thu Sep 13, 2018 3:37 pm; edited 1 time in total

----------

## Child_of_Sun_24

Die Bios Einstellungen sind weitestgehend auf Default, musste nur SVM aktivieren (Wegen Hyper-V), die Speichereinstellungen auf Profil1 stellen (Wegen 3200 MHz), die Spannung vom Speicher auf 1,37 V stellen (Wegen der Stabilität), CSM deaktivieren und den SystemFan anschluss meiner Wasserkühlung auf Fullspeed stellen, das war es auch glaube ich schon.

----------

## firefly

 *Child_of_Sun_24 wrote:*   

>  *firefly wrote:*   Da es an MSI wohl hängt kannst du MSI auch per kernel commandline disablen.
> 
> Und zwar mit folgendem commandline argument:
> 
>  *Quote:*   pci=nomsi 
> ...

 

Dann kann der Fehler wohl nicht an MSI/MSI-X liegen  :Smile:  wie du es vermutet hattest:

 *Child_of_Sun_24 wrote:*   

> Haha  Habe es rausgefunden  wenn ich die IOMMU Treiber deaktiviere kann ich unter Bus options (PCI etc.) die Message Signaled Interrupts (MSI and MSI-X) deaktivieren, sobald ich dann boote startet der Kernel ohne Probleme, habe dann halt nur keinen IOMMU Support, was aber nicht schlimm ist. 

 

Dann wohl eher am IOMMU support

----------

## Child_of_Sun_24

 *firefly wrote:*   

>  *Child_of_Sun_24 wrote:*    *firefly wrote:*   Da es an MSI wohl hängt kannst du MSI auch per kernel commandline disablen.
> 
> Und zwar mit folgendem commandline argument:
> 
>  *Quote:*   pci=nomsi 
> ...

 

Aber er hängt auch ohne aktivierte Iommu Treiber sobald ich MSI/MSI-X im Kernel aktiviere

----------

## Keruskerfuerst

Beim Bios Update danach "Load Optimized Defaults" durchgeführt ?

----------

## Child_of_Sun_24

 *Keruskerfuerst wrote:*   

> Beim Bios Update danach "Load Optimized Defaults" durchgeführt ?

 

Das macht das Uefi automatisch wenn eine neue oder ältere Version geflasht wurde.

----------

## Child_of_Sun_24

Um es nochmal zusammenzufassen, die beiden Lösungen sind:

Das Uefi auf F23d zu downgraden oder

MSI / MSI-X im Kernel zu deaktivieren.

Ersteres kommt für mich nicht in Frage weil er dann auch eine ältere agesa Version nutzt.

Die zweite Lösung ist für mich im moment der Stand der dinge, da ich Linux zwar auch unter Windows Virtualisiere allerdings nicht Windows unter Linux weswegen ich auf die Iommu Unterstützung verzichten kann.

Jetzt warte ich einfach ab ob bei der Bug Meldung auf kernel.org etwas rumkommt.

----------

## Marlo

Hi  Child_of_Sun_24,

gibt es einen Grund warum du nur microcode_amd_fam17h.bin geladen hast?

Grüße

Ma

----------

## Child_of_Sun_24

 *Marlo wrote:*   

> Hi  Child_of_Sun_24,
> 
> gibt es einen Grund warum du nur microcode_amd_fam17h.bin geladen hast?
> 
> Grüße
> ...

 

https://wiki.gentoo.org/wiki/Ryzen#Kernel

Wurde hier so erklärt.

----------

## Child_of_Sun_24

Nun mit Kernel 4.19-rc5 hängt er nochmal ganz kurz an der selben Stelle aber bootet dann ganz normal weiter, das Problem scheint gelöst worden zu sein  :Smile: 

Mit 4.18.10 klappt es auch  :Smile:  Da gibts nur ärger mit dem Psp Device (Ok die gibt es auch mit 4.9-rc5).

----------

