13.1-RELEASE-p2 und AMD 8750D GPU

berni51

Open-Net-FreeBSD user
Hab gerade große Probleme mit einem Asus F2a85M-Board mit AMD A10 und Radeon 8750D-Grafik. Sowohl unter 13.1 als auch unter 14-Current geht bei EFI-Boot überhaupt kein Xorg - no screens found.
Im Legacy Mode mit entsprechend mieser Auflösung auf der Konsole kann ich mit gebautem drm-kmod den amdgpu laden und bekomme auch ein Xorg in korrekter Auflösung.
Allerdings ist nach jedem Wechsel auf eine Konsole und zurück dann die Farbtiefe extrem gering und der Text zerschrieben. Das gleiche passiert beim Aufruf mancher Programme, 100% reproduzierbar.
Versuche ichs mit dem radeonkms, friert die Maschine sofort ein. Der xf86-video-amdgpu läuft überhaupt, ebenfalls no screens found.
Also eigentlich läuft kein Treiber wirklich vernünftig. Hab jetzt den halben Sonntag alles durchprobiert, aber ohne Erfolg.
Die beiden anderen BSDs (Net/Open) laufen problemlos auf der Grafik.
Hab im Moment keine Idee mehr.
LG
Berni

PS:
Der FreeBSD-Matrix zufolge sollte amdgpu als Kernel Modul funktionieren, also der drm-kmod Port. Läuft ja auch - irgendwie. Aber total unbefriedigend. Bin viel zu oft an der Console, um diese grobe VGA-Auflösung zu akzeptieren.
 
Probier ich nachher mal. Aber ob das den Zusammenbruch der Grafik nach Umschalten auf Text und zurück beseitigen kann?

Hab heute nochmal auf einem ähnlichen Board mit AMD 8650 GPU eine Installation versucht - mit den gleichen Ergebnissen wie bei der 8750er. Auf den 7xxxer GPUs dagegen klappts immer mit der amdgpu aus den Ports.
 
Ein vidcontrol -i mode liefert mir ja die verfügbaren Modi - und da kommt nichts, rein gar nichts, nur eine leere Zeile. Ich würde mal sagen, dass FreeBSD für diese (zugegebenermassen ältere) GPU keinen passenden Treiber hat.
 
Bleibt noch 'nen PR aufzumachen. Aber bei FreeBSD kann's dir passieren, daß der Entwickler zurückschreibt, du möchtest doch für ihn ein paar Versuche / Debugging Sachen machen. Das sollte man dann fairerweise auch tun
 
Was die Konsole angeht kann es möglicherweise auch helfen statt dem neuen vt-Treiber den alten syscons zu benutzen.
Kann man auch als Bootparameter übergeben ohne das in die /boot/loader.conf einzutragen. So hat man mit einem Reboot alles wieder wie vorher falls was damit schief geht.
set kern.vty="sc"
Wobei ich jetzt nicht glaube, das das das Problem löst. Ist mehr so ein Versuch aus der Verzweiflung heraus. :-)

Der FreeBSD-Matrix zufolge sollte amdgpu als Kernel Modul funktionieren
Der Eintrag Radeon 8750D findet sich doch nicht direkt:
Ich würde auch eher den amdgpu-Treiber als den Richtigen ansehen. Aber so klar aus der GPU-Matrix ersichtlich ist das nicht.
 
Ich versuchs erstmal ohne PR.
Hab nochmal alle Beiträge zu diesem Thema studiert und einiges ausprobiert. Beim Eintrag von
Code:
hw.syscons.disable=1
in die loader.conf habe ich jetzt zum ersten mal ein stabiles xorg - aber dafür gibts beim Booten keinen Text mehr auf den Konsolen, sondern das erste Bild ist nun der DM. Und auf Textkonsolen umschalten klappt auch nicht mehr. Aber immerhin bricht die Grafik jetzt nicht mehr ein.
Trotzdem ein hoher Preis, denn ohne Konsolen bin ichs einfach nicht. Die Suche geht also weiter.
 
@Andy_m4 : Auch auf der AMD-Seite werden diese GPUs unter Serie 8000 geführt und meine speziellen GPUs (8750, 8650) finde ich nirgendwo.
Den Versuch mit dem alten syscons Treiber mache ich heute noch. Das war es wohl auch, was @serie300 im anderen Thread mit alter/neuer Konsole gemeint hat. Damit konnte ich erst gar nichts anfangen, aber jetzt wirds klar.#
 
Ich nutz beides gleichermassen und möchte wenns geht auf keines verzichten. Aber klar, es geht schon auch ohne Textkonsolen. OpenIndiana z.B. hat ex works auch nur die grafische Oberfläche und damit kann ich schon leben.
Dennoch probier ichs weiter.
Der Versuch Konsole alt/neu hat übrigens nichts verändert: Der amdgpu Treiber zeigt unterbeiden das gleiche Verhalten.
Ich bleib dran.
 
Ich kann mich irgendwie dunkel erinnern, daß vor Jahren bei diversen integrierten / Chipsatz AMD GPUs (müßten die ersten Ryzen gewesen sein) die Konsole sich nicht mit dem drm Treiber vertrug. D.h. man mußte bei drm mit dunklem Bildschirm booten.
 
Ich hab das gleiche Board und auch das -pro gehabt, auch ein paar iGPUs damit getestet. Die gleichen Effekte hatte ich ebenso, das ist recht tricky. Vorab sei aber gleich mal gesagt, dass du es vergessen kannst, zwischen virtueller Konsole und xorg zu wechseln. Das gibt Grafikmatsch und das wars dann. :)
Allerdings kannst du je boot einmal eine Konsole (aber trotzdem grafisch ausgegeben) bekommen (Treiber lädt, Bild flackert, Auflösung wechselt auf native des Monitors), wenn du deinen DM aus dem autostart nimmst. In diesem State kannst du auch zwischen den virtuellen Konsolen wie gewohnt wechseln, aber sobald du irgendwas mit xorg startest, ist Ende Gelände mit wechseln.
Ich würde grob so vorgehen:
1. amdgpu ist richtig, das passt. Aber der soll auch erstmal aus dem autostart raus. Ebenfalls prüfe mal nach, dass du auch keinerlei xorg.conf hast, aus nvidia-Altlasten oder so und wäre ein Stolperstein.
2. Grafisches Zeug aus dem autostart entfernen, alles was mit xorg zu tun hat.
3. Bisher gemachte Änderungen rückgängig machen -> syscons (sc) / vt aka newcons https://wiki.freebsd.org/Newcons
4. Im BIOS die iGPU mit 256MB vRAM auf forced/first/primary setzen. Nochmal versichern, dass UEFI-Boot an sich aktiviert ist. Einmal speichern, dann nochmal ins BIOS rein. Nun versichern, dass als erster Booteintrag auch der UEFI Loader der passenden Platte drin ist, da das BIOS gerne 2-3 Einträge anzeigt und ich ungerne verwirrt bin. ;) Dazu haue ich explizit noch alle weiteren folgenden Bootalternativen raus, egal ob PXE oder disk2...
5. Jetzt einmal durchbooten, du solltest dann am loginprompt landen und zwar mit vt, aber ohne Treiber.
6. Nun als root anmelden und testen, ob du durch die virtuellen Konsolen wechseln kannst.
(6½. optional von einer anderen Maschine drauf, damit du im vga-crash-fall logs gucken kannst)
7. Ein beherztes kldload amdgpu abfeuern. (Vorteil hierbei: du kannst nach jedem Test sauber booten)
Ensure that your UID is a member of the video group.
...wird gerne vergessen
8. Wenn alles gut, erneut testen, ob du Konsolen wechseln kannst. Wenn auch das klappt, kann man die config als autostart hinbiegen. Wenn nicht, zurück auf Los. -> hw.syscons.disable=1 -> Verstehe ich nicht, weil vt ja schon ewig default ist.

Nochmal: Ab hier kannst du dann Konsolendinge tun, aber sobald du xorg gestartet hast, wars das dann bis zum nächsten Boot. :)
 
@mr44er : Besten Dank für deine prima nächtliche Anleitung - habs direkt nachgestellt und so funktionierts jetzt auch bei mir. Die Einstellungen im BIOS waren schon korrekt gesetzt. :) So kann das jetzt bleiben.
Aber ein wenig schwach ist das schon vom FBSD-Treiber. Die Boards waren (und sind) ja vielfach im Einsatz. Und das es geht zeigen ja Open- und NetBSD.

Aus Neugier und weils gerade so herrlich ruhig war, wollte ich dann wissen, wie sich die FBSD-Abkömmlinge dabei verhalten. Also schnell zwei Sticks präpariert. einen mit GhostBSD, einen mit Dragonfly.

GhostBSD verhält sich ähnlich wie FBSD. Nur hat das OS ja keinen grafischen Installer (oder ich hab ihn nicht gefunden), deshalb musste ich am Loader Prompt dann doch den Spruch ->hw.syscons.disable=1-< eingeben und damit booten. Dann konnte ich installieren und die Einstellung in der loader.conf festspaxen.
Jetzt hab ich zwar auch da keine virtuellen Konsolen, aber das ist ja vielleicht sogar im Sinne von GhostBSD. Xorg läuft jedenfalls prima, stabil und rund. Ist allerdings so gar nicht mein Geschmack, hat sich angefühlt wie Ubuntu. Sollte ja auch nur ein Test sein.

Etwas aufwändiger wars mit Dragonfly. Installieren kein Problem, ist ja ein Konsolen-Installer. Bis dann aber Xorg lief, musste ich ganz ordentlich rumprobieren. hw.syscons.disable hatte keinen Effekt, an Treibern liess sich nur der amdgpu absturzfrei laden, gab aber noch kein xorg: No sreens found.

Erst mit < gop set 2 > am Loader Prompt (der höchstmöglichen Auflösung) kann ich jetzt Xorg starten, das aber völlig ohne Probleme. Und der Hammer: Die virtuellen Konsolen bleiben erhalten. Zwar dauert die Umschaltung von Text auf Grafik dann ein paar Sekunden, aber es klappt. Volle Punktzahl für Dragonfly, dass mir auch sonst ganz gut gefällt.

Die ganze Arbeit für so ein altes Board mag sich ja wenig sinnvoll anhören, aber wir haben etliche davon im Einsatz. Sind auch heute noch sehr gut geeignet für so ziemlich alles, was hier gemacht wird. Einige davon haben zum Glück GPU aus der 6- oder 7000er Reihe, damit gibt es sowieso keine Probleme.

Insgesamt ist mein Eindruck, dass bei FBSD in Sachen Grafiktreiber oder besser Treiberkonzept durchaus noch Luft nach oben ist.

LG
Berni
 
An sich solide sind diese Boards, aber sie sind alt genug, dass sie noch UEFI-Kinderkrankheiten haben. Ob das die Zickigkeiten mit dem Treiber zündet, weiß ich nicht. Insgesamt, aber nicht aussagekräftig würde ich sagen, dass ich solche Probleme nur mit APUs/onboard-Gekrempels hatte.
Btw. GPU: Wenn man da eine PCIE-Karte steckt, die keine GPU ist, gibts erstmal kein Bild und Gepiepse. Je nachdem ob diese Karte ein UEFI-kompatibles BIOS hat oder nicht muss man mit den CSM/opROM-Settings rumprobieren. Die unlogischste Einstellung gewinnt meist. :ugly:

Insgesamt ist mein Eindruck, dass bei FBSD in Sachen Grafiktreiber oder besser Treiberkonzept durchaus noch Luft nach oben ist.
Nachvollziehbarer Blickwinkel:
In the past, the FreeBSD graphics stack got far behind the upstream sources. One of the main reasons for this was that as a project we'd been terrible about getting changes accepted upstream (or even trying to upstream them). These technical issues lead to much frustration and exacerbated many teamwork issues with the stack. For a time, things were somewhat dysfunctional. However, the graphics teams has caught up on all this technical debt by upstreaming changes; integrating Linux compatible APIs (like evdev); or by writing adapters to make FreeBSD-specific things like devd look like their Linux counterparts.
https://wiki.freebsd.org/Graphic <-ganz unten die letzten Absätze
 
Jetzt hab ich mir den Link von @mr44er nochmal in Ruhe zu Gemüte geführt - mit dem Ergebnis, dass ich mir das ganze Gefrickel mit amdgpu, radeonkms, hw.syscons.disable, set gop usw. usf. hätte sparen können. Ein bisschen Lesen, den xf86-video-scfb Treiber installiert, und schon hab ich ganz normal beides: Xorg und die Konsolen. Und das unter FreeBSD, GhostBSD und Dragonfly.
Das Leben kann so einfach sein - oder auch nicht.
Wollte ich euch nur kurz mitteilen.

LG
Berni
 
Das ist aber dann nicht beschleunigt, auf lange Sicht der mMn. schlechtere Kompromiss. Klar, auf wobbly windows oder sonstiges eyecandy kann man verzichten.
Ich könnte mir aber Probleme beim Videoabspielen vorstellen oder dass man keine 60Hz fahren kann. Wenn das trotzdem geht, will ich nix gesagt haben. :D
 
Da hast Du schon Recht, null Beschleunigung. Das ist aber bei diesen Arbeitsmaschinen wurscht. Da gibts keine Spiele, vielleicht mal ein Youtube Video, das geht sogar ganz erträglich.
En gut funktionierender amdgpu wäre mir natürlich lieber, aber den wirds wohl für diese GPU nicht mehr geben.
 
Ich bin mir unsicher, aber damit greifen wahrscheinlich auch die Stromsparmechanismen nicht. Es wird kein Löwenanteil sein, aber bei den aktuellen Strompreisen könnte man eventuell mal mit einem Messgerät vergleichen, wenn ihr davon ein paar viele Boards im Einsatz habt.
 
Zurück
Oben