FreeBSD 13 und radeonkms hängt beim Booten

berni51

berni51

Open-Net-FreeBSD user
Seltsamerweise hab ich relativ häufig Probleme mit FreeBSD und seinen Grafiktreibern. So auch jetzt wieder:

Hab ein 13.0-p10 auf einem Rechner mit Asus-Board und AMD A10 mit Radeon 7660D GPU installiert. FreeBSD bootet per UEFI.
Die Installation verlief problemlos, aber danach braucht der Rechner 2,3,4 oder 5 Versuche, um durchzubooten. Zunächst bootet die Kiste normal, alles wird ordentlich erkannt, aber sobald der radeonkms-Treiber geladen wird, wird der Bildschirm schwarz und nichts geht mehr: Keine Reaktion auf Maus, Tastatur, auch kein ping oder ssh klappt. Die Kiste ist einfach tot.
Nach mehreren Neustart klappt dann der Bootvorgang irgendwann und dann läuft alles gut und normal.
Nach so einem Blackscreen finde ich in den Log ... nichts dazu. Klappt der Bootvorgang, finde ich in messages den Eintrag:

Code: 
drm error: radeon_atombios_init
unable to find PCI I/O BAR
using MMIO for ATOM IIO

Dazu gibt Google nun etliche Informationen, aber keine davon konnte mein Problem lösen.

Den radeonkms lade ich in der rc.conf per kld_list radeonkms.
Versucht habe ich es dann mit dem radeonkms_CAYMAN_pf_bin, was keine Änderung brachte.
Mit dem amdgpu-Treiber ist die Grafik miserabel. Zwar stimmt die Aulösung (Full HD), aber die Farbdarstellung bricht nach jedem Programmaufruf quasi zusammen.

Auf der gleichen Maschine laufen noch ein Refracta-Linux und ein Openindiana, die beide mit der GPU keinerlei Probleme haben.

Und wie schon vorab erwähnt: Klappt der Bootvorgang, gibt es keinerlei Probleme, die Maschine läuft den ganzen Tag perfekt durch.
 
radeonkms ist schon richtig, ich habe eine ähnliche Kiste. Hast du mal graphics/drm-kmod explizit neu gebaut und/oder ohne UEFi versucht? Damit war auch irgendwas im Gehege.
Habe gerade mal auf meiner Kiste geschaut, das Modul habe ich bei mir ausgeklammert, dunkel erinnere ich mich aber auch beim letzten Update an deine beschriebenen Probleme.

normalerweise richtig in rc.conf:
kld_list="amdtemp /boot/modules/radeonkms.ko"
 
Bisher hab ich nur den radeonkms aus dem Repo genommen. UEFI und Legacy habe ich beide probiert, aber die tun sich nix.
Ich versuchs mal mit deinem rc.conf-Eintrag, hab jetzt nur die Kurzform "kld_list=radeonkms" drin. Was hat denn das amdtemp zu bedeuten?
 
berni51 schrieb:
Was hat denn das amdtemp zu bedeuten?
Zum Vergrößern anklicken....
Damit kannst du die Temperaturen von AMDs abrufen -> sysctl -a | grep temp
Das Pendant bei intel ist nicht inteltemp, sondern coretemp ;)

berni51 schrieb:
hab jetzt nur die Kurzform "kld_list=radeonkms" drin
Zum Vergrößern anklicken....
Sehe gerade auf https://wiki.freebsd.org/Graphics (ziemlich in der Mitte), dass für 13 die Pfadangabe unnötig ist.

berni51 schrieb:
UEFI und Legacy habe ich beide probiert, aber die tun sich nix.
Zum Vergrößern anklicken....
Etwas weiter oben auf der Seite steht dazu:

If UEFI boot results in a conflict between a driver and the EFI frame buffer, you can add this line to /boot/loader.conf to disable the buffer:

  • hw.syscons.disable=1
With the buffer disabled, console output will not appear until the driver loads. https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/170 explains.
Zum Vergrößern anklicken....

Dein user muss später noch Mitglied von video sein, aber das hat an der Stelle noch keine Auswirkung.
 
Bau erstmal den drm-kmod-13 in den ports. make . make install. reboot. dann den port für upgrades sperren! wenn danach weiter Probleme Problem report. sorry für die kürze. bin auf Arbeit
 
Jetzt hab ich, natürlich schön nacheinander, alle Hinweise abgearbeitet. Leider alles ohne Erfolg, teilweise sogar mit Verschlimmerung:
  • xf86-video-amdgpu deinstalliert - keine Änderung
  • drm-kmod aus den Ports gebaut und installert - keine Änderung
  • UEFI framebuffer disabled (hw.syscons.disable=1) - damit hätte ich mir fast den berühmten letzten Ast abgesägt. Der Rechner hing jetzt bereits kurz nach dem Bootmenu und hatte nicht mal Zeit, den Bildschirm zu schwärzen.

Ach ja, Frage an @mr44er : Kriegst Du mit dem Laden den amdtemp Moduls tatsächlich vernünftige Werte? Meine CPU wird damit 14°C war und erhitzt sich im weiteren Betrieb auf 11°C um dann nach 5 Minuten bei -0°C quasi in Rauch aufzugehen.
Allerdings krieg ich bei diesem Board mit keinem OS vernünftige Temperaturanzeigen.
Aber das nur nebenbei.
Mein Boot-Problem besteht also nach wie vor.
 
berni51 schrieb:
Kriegst Du mit dem Laden den amdtemp Moduls tatsächlich vernünftige Werte?
Zum Vergrößern anklicken....
Zumindest auf den beiden Kisten plausible Werte:
Code: 
dev.amdtemp.0.core0.sensor0: 34.5C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb4
dev.amdtemp.0.%pnpinfo:
dev.amdtemp.0.%location:
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent:
dev.cpu.7.temperature: 34.5C
dev.cpu.6.temperature: 34.5C
dev.cpu.5.temperature: 34.5C
dev.cpu.4.temperature: 34.5C
dev.cpu.3.temperature: 34.5C
dev.cpu.2.temperature: 34.5C
dev.cpu.1.temperature: 34.5C
dev.cpu.0.temperature: 34.5C
Code: 
dev.amdtemp.0.core0.sensor0: 22.2C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb4
dev.amdtemp.0.%pnpinfo:
dev.amdtemp.0.%location:
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent:
dev.cpu.3.temperature: 22.2C
dev.cpu.2.temperature: 22.2C
dev.cpu.1.temperature: 22.2C
dev.cpu.0.temperature: 22.2C

Nun stochere ich etwas nebulös. Die GPU bei diesen CPUs ist tatsächlich an der Schwelle zwischen den Welten und da ist die Kompatibilitätsmatrix nicht eindeutig gewesen (habe aktuell nicht geschaut). Grafik in CPU stopfen war bei Bulldozer recht neu.
Verhält sich das anders, wenn du im BIOS mal etwas rumspielst bei den GPU-Settings? Aus der Erinnerung kann man da mehr vram zuweisen, wahlweise fest oder dynamisch (autoconfig)

Edit: Die Matrix ist eindeutig, wie rossi das anmerkt. Bei diesen GPUs/Boards aber nicht zwingend. Die kleinen E-350er und E-450er haben da auch nicht 'gepasst'.
 
berni51 schrieb:
Kriegst Du mit dem Laden den amdtemp Moduls tatsächlich vernünftige Werte? Meine CPU wird damit 14°C war und erhitzt sich im weiteren Betrieb auf 11°C um dann nach 5 Minuten bei -0°C quasi in Rauch aufzugehen.
Zum Vergrößern anklicken....
Kommt auch stark auf die Generation an. AMD hat zumindest vor Zen mit praktisch jeder Untergeneration verändert, wie die Werte zu interpretieren sind und wenn der Treiber das nicht korrekt macht, kommt Murks raus. Zu den aktuellen CPUs kann ich aber mangels Erfahrung nur sagen, dass Zen1 (hier als Epyc) und Zen2 (als Ryzen) plausible Werte liefern.
 
Das war's wohl: Es muss der amdgpu.ko sein. Damit bootet und läuft die Kiste (bisher) bestens, egals ob UEFI oder Legacy. Der UEFI framebuffer beisst sich auch nicht damit - sieht gut aus, sehr gut. Ich danke euch allen für die schnelle und gute Unterstützung.

Was mich ein wenig wundert: Ganz zu Anfang meiner Probleme hatte ich den amdgpu schon einmal probiert, und hatte damit eine sehr miese Grafik, sah aus wie 2 bit. Jetzt stimmt aber alles.

War schon kurz davor, auf OpenBSD umzuschwenken .....

Sehr zufrieden, Berni
 
Kann sein, dass xf86-video-amdgpu nicht optimal für deine Grafikkarte war und die vorhanden Module ausreichen.
 
Fein. Da werd ich dann auch mal bei Gelegenheit rumfummeln und auf amdgpu schwenken bzw. nochmal ausprobieren, denn damals crashte das bei meiner Kiste.
 
Hallo

war vorhin etwas kurz weil Arbeit und Handy. Der amdgpu wird mit drm-kmod neu gebaut; kann sein, daß es das war.
Zumindest bis vor ein paar Wochen war es so, daß man den drm-kmod bei allem was nicht "[12,13].0 Release" ist, bauen muß und nicht einfach aus den packages ziehen kann. Falls du also, wenn es verfügbar ist, auf FreeBSD 13.1 wechselt - folgendes Vorgehen erspart Probleme.
1. amdgpu aus /etc/rc.conf auskommentieren und mit VESA booten
2. Release / Stable update machen
3. Reboot
4. drm-kmod 13.0 neu bauen und installieren
5. amdgpu wieder anschalten
6. reboot
Ansonsten lernt du aus der Not - weil Absturz beim Umschalten auf den amdgpu - wie man in die Not Single-User Shell bootet, ggf. die Tastatur umkonfiguriert, das Standard Boot Device System drüber mountet, damit man an in /etc den amdgpu abschalten kann und dann siehe oben.
Ansonsten nettes Tool: "radeontop". Vulkan geht übrigens mit dem Radeontreiber (zumindest mit meiner Polaris10 Generation)
 
Hier mal eine Auflistung der unterstützten Grafikkarten von xf86-video-amdgpu für ein Ubuntu-Sytem, was übertragbar ist. Wenn die Karte nicht dabei ist, nicht installieren. Vor allem nicht im "Zusammenspiel" mit drm-kmod und den damit vorhandenen Modulen für ATI bzw. AMD-GPUs!

AMDGPU-Driver - Community Help Wiki

help.ubuntu.com

Die unterstützten Grafikkarten für xf86-video-ati müsste man mal noch heraussuchen.
 
berni51 schrieb:
Da find ich aber meine
Code: 
AMD Trinity [Radeon HD 7660D]
nicht darunter.
Zum Vergrößern anklicken....
Deshalb die Module von drm-kmod bzw. gpu-firmware-kmod und nicht xf86-video-amdgpu. Das hattest Du doch, wie von mir geraten, deinstalliert? xf86-video-amdgpu wird automatisch geladen und verträgt sich nicht mit den passenderen Modulen von drm-kmod. Der zweite "unpassende Koch" verdirbt den Brei. Er ist zwar nicht der Richtige, nimmt aber Einfluss auf "ähnliche Teile" der Hardware - ähm des Breis. :)
 
Zuletzt bearbeitet:
rossi schrieb:
Deshalb die Module von drm-kmod bzw. gpu-firmware-kmod und nicht xf86-video-amdgpu. Das hattest Du doch, wie von mir geraten, deinstalliert? xf86-video-amdgpu wird automatisch geladen und verträgt sich nicht mit den passenderen Modulen von drm-kmod. Der zweite "unpassende Koch" verdirbt den Brei. Er ist zwar nicht der Richtige, nimmt aber Einfluss auf "ähnliche Teile" der Hardware - ähm des Breis. :)
Zum Vergrößern anklicken....
Jetzt verstehe ich's (erst) richtig. Und ja,den xf86-video-amdgpu hatte ich installert, und er war auch (wie Du schreibst) im System vorhanden.
Die ähnliche Namensgebung der amdgpu-Treiber kann aber auch ein wenig irritieren. :cool:
 
Hallo Zusammen,

ich hatte mit meinem Lenovo x121e mit AMD-Chipsatz auch das o.g. Problem mit 3...4 erfolglosen und dann dem 5. erfolgreichen Bootversuch mit dem radeonkms-Treiber. Das Deinstallieren und neu Erstellen des Pakets drm-kmod-g20190710_1 aus den Posts brachte jedoch keine Verbesserung.

Ihr könnt mich jetzt gerne für bekoppt halten, aber nachdem ich die Angabe von "kdl_list=" an den Anfang der /etc/rc.conf gesetzt habe läuft es:

Bash: 
root@x121e:~ # head -n1 /etc/rc.conf
kld_list="radeonkms"

PS: Danke für diesen Thread, sonst hätte ich aus Verzweiflung wahrscheinlich wieder Linux installiert. :)

HTH
 
stendate schrieb:
aber nachdem ich die Angabe von "kdl_list=" an den Anfang der /etc/rc.conf gesetzt habe läuft es
Zum Vergrößern anklicken....
Eigentlich sollte es egal sein an welcher Position in der /etc/rc.conf der kld_list-Eintrag steht. Probleme kann es natürlich geben, wenn irgendwo noch ein weiterer kld_list-Eintrag vorhanden ist (die muss ja auch nicht unbedingt in der /etc/rc.conf sein, sondern kann sich ja auch unterhalb von /etc/rc.conf.d/ verstecken).
 
So ist es! Nur eine Zeile anlegen:
Code: 
kld_list="modul1 modul2 modul3"

Beispiel:

Code: 
kld_list="snd_xonar nvidia nvidia-modeset"
 
Letztendlich ist die rc.conf einfach ein Shellscript. Man nutzt sie meist nur, um ein paar Variablen zu setzen. Aber man kann tatsächlich alle erdenkliche Shell-Magie machen, solange die notwendigen Tools in /bin/ liegen. Andere Pfade sind früh im Boot nicht garantiert verfügbar. Das vorweg, ich will darauf hinaus, dass man auch sowas machen kann:

Code: 
kld_list="modul1"
kld_list="$kld_list modul2"

So kann man halbwegs elegant einzelne Zeilen pro Modul bekommen, die einfach ein- und auskommentieren, durch Automatisierungstools behandeln und so weiter. Was hier aber natürlich Overkill ist. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben