FreeBSD-12.2 - ATI / AMDGPU(0): [KMD] drm modesetting isn't supported

[kongstrong]

Hallo,

wenn ich richtig gelesen habe benötigt man unter FreeBSD 12.2 amd64 für Ati Radeon HD 8330E den "drm-kmod" Port.
Der Treiber wird bei Systemstart geladen per

/etc/rc.conf

mit dem Eintrag

kld_list="amdgpu"

. So weit so gut, wenn ich jetzt allerdings startx ausführe erhalte ich als Fehlermeldung Xorg:

(II) AMDGPU(0): [KMS] drm report modesetting isn't supported.
(II) AMDGPU(1): [KMS] drm report modesetting isn't supported.
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)

Wie kann man das Problem beheben ?

 

[serie300]

Hallo,

wie hast du den drm-kmod installiert? Aus den Packages oder mit 'make'? Hast du in drm-mod-next oder drm-kmod 'make' gemacht?
Ich frage, weil ich gelesen hatte, daß man drm-kmod wieder aus packages installieren kann, was nicht stimmt und dann nach dem update auf 12.2. bei auf meinem Laptop mit intel HD6irgendwas (die auch in drm-kmod ist) eine ähnliche Meldung erhalten habe. Erst nach bauen ging's dann einwandfrei.

 

[kongstrong]

Hallo serie300,

ich habe den "drm-kmod" Port direkt mit

make BATCH=yes && make install clean

gebaut (als root)... zuvor hatte ich die Ports aktualisiert (siehe: 4.1) ...

Wenn ich den radeonkms Treiber versuche beim Systemstart automatisch mit zu laden, schmiert FreeBSD mit einer KernelPanic ab...
Also laut Wikipedia kann wohl der Radeon ab einer HD7000 genutzt werden, ob das auch bei FreeBSD so ist weiss ich alldings der Zeit nicht

Weil ich es noch gerade gelesen habe, UEFI/EFI ist im BIOS abgeschaltet.

@OffTopic: leider weiss ich immoment noch nicht, wie ich die aktuelle Monitor Auflösung von 640x480 ändere und Scrollback in FreeBSD aktiviere, sonst könnte ich zu der Panic mehr Auskunft geben.

 

[Andy_m4]

Also laut Wikipedia kann wohl der Radeon ab einer HD7000 genutzt werden

Ob Du radeonkms oder amdgpu nutzen musst geht eher aus
https://wiki.freebsd.org/Graphics/AMD-GPU-Matrix
hervor.
Für Deine Radeon HD 8330E würde ich mal auf den amdgpu-Treiber tippen.

Scrollback in FreeBSD aktiviere

Mit Hilfe der "Scroll Lock" Taste (auf deutschen Tastaturen auch gern "Rollen" genannt). Ist das aktiviert, dann kannste mit den Pfeiltasten herumscrollen. Ich hoffe mal, das das auch nach dem Kernel Panic funktioniert. :-)
Aber wie schon gesagt. radeonkms ist vermutlich sowieso der falsche Treiber.

den "drm-kmod" Port.

Probier mal lieber drm-fbsd12.0-kmod:
/usr/ports/graphics/drm-fbsd12.0-kmod

 

[pit234a]

Weil ich gerade ebenfalls darüber gestolpert bin, nachdem ich ein System auf 12.2 updaten wollte, das auf Quarterly sitzt und bei dem ich nicht selbst bauen möchte und wo deshalb die drm-kmod Unterstützung mir um die Ohren geflogen ist:

ist es nicht so, dass drm-kmod ein Meta-Port ist und automagisch wählt, ob es den
drm-legacy-kmod
oder den
drm-fbsd12.0-kmod
haben möchte?
Bei mir wurde jedenfalls drm-fbsd12.0-kmod benutzt und ich erinnere mich nicht, dass ich den jemals installiert hätte.

Ja, und ich denke, dass es nun eigentlich einen drm-fbsd12.2-kmod geben müsste, der dann irgendwann mal als Paket auftauchen sollte?

 

[Alexander88207]

Die Treiber werden solange fuer 12.1 gebaut bis 12.1 EOL ist.

 

[Andy_m4]

ist es nicht so, dass drm-kmod ein Meta-Port ist und automagisch wählt, ob es den
drm-legacy-kmod
oder den
drm-fbsd12.0-kmod
haben möchte?

Ja. Ist ein Metaport.
Ob man die Wahl als "automagisch" bezeichnen möchte, weiß ich jetzt nicht.
Es wird ja nur die FreeBSD-Version abgefragt und an Abhängigkeit davon drm-fbsd11.2-kmod (FreeBSD 11), drm-fbsd12.0-kmod (FreeBSD 12) oder drm-current-kmod (FreeBSD 13) installiert.

Meine Idee dahinter trotzdem drm-fbsd11.2-kmod explizit zu bauen ist auch sicherzustellen, das das auch wirklich geschieht und er das nicht auslässt, weil es ja via Packages schon drin ist.

und ich denke, dass es nun eigentlich einen drm-fbsd12.2-kmod geben müsste

Das denke ich nicht. Denn ein Neukompilieren tut es ja. Und für die unterschiedlichen FreeBSD-Versionen gibts ja auch jeweils gebaute Pakete (pkg lädt ja u.a. auch in Abhängigkeit der FreeBSD-Version von unterschiedlichen Server-Verzeichnissen, wenn ich mich richtig erinnere; korrigier mich einer wenn ich falsch liege).

Warum jetzt trotzdem noch die "falschen" Pakete installiert werden weiß ich jetzt nicht. Ich vermute mal, beim 12.2 Release hat man einfach den bestehenden Packagebestand weiter benutzt damit man erst mal was hat und baut die nach und nach neu.

 

[Andy_m4]

Ich hatte ja eine spekulative Aussage gemacht, was mich noch mal angehalten hat das zu überprüfen.
Und zwar ging es um die Paketverzeichnisse.
Also ja, die Pakete liegen in Abhängigkeit von der FreeBSD-Version in unterschiedlichen Server-Verzeichnissen, aber es wird offenbar nur die Hauptversionsnummer berücksichtigt.
Also für das drm-fbsd12.0-kmod Paket ist der Link:
http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest/All/drm-fbsd12.0-kmod-4.16.g20200221.txz
Der Aufbau des Links ist selbsterklärend, denke ich.

Das heißt aber auch, Du wirst um das Selbstkompilieren des Treibers nicht herum kommen, wenn Du den zeitnah einsetzen willst.

 

[serie300]

Wenn ich mich recht erinner, hat meine maschine beim 'make' in drm-kmod nicht viel gemacht. Ich brauchte ein 'make' in drm-fbsd12. man sieht dann wie die Module kompiliert werden. dann noch 'make install'

 

[pit234a]

Das heißt aber auch, Du wirst um das Selbstkompilieren des Treibers nicht herum kommen, wenn Du den zeitnah einsetzen willst.

oder anders herum:
meine beiden pkg-only Systeme (zwei Laptops) sind 12.2 not ready.

Das ist vielleicht nicht nur eine Erkenntnis, sondern eine wichtige Information.
Von Anfang an wollte ich auf beiden Systemen ganz bewusst auf den Portstree und die Sourcen verzichten und ausschließlich nur Pakete benutzen. Damit war mir auch bewusst, dass ich vielleicht auf die ein oder andere Annehmlichkeit verzichten müsste.
Installation und Betrieb unter 12.0 und 12.1 verliefen auch Reibungslos.
12.2 funktioniert mit dem drm-fbsd12.0-kmod nicht mehr, zumindest nicht mit dem aus Quarterly.
Eigentlich würde ich aber erwarten, dass zumindest jenes aus Latest funktionieren sollte. Tut es das nicht und man wird gezwungen, selbst zu kompilieren, passt da was nicht und dann sollte es eben ein neues und funktionierendes Paket für 12.2 geben.
Ob es das Latest-Paket aber tun würde habe ich nicht getestet und da es die gleiche Version ist, wie im Quarterly, darf das angezweifelt werden.

Wenn ich mich für CURRENT entscheide, ist das natürlich anders. Aber bei einem RELEASE erwarte ich, ohne eigenes Kompilieren auszukommen. Das erscheint mir so irgendwie nicht ganz richtig, wie das gerade gehandhabt wird.

 

[Andy_m4]

meine beiden pkg-only Systeme

Was Du noch machen kannst ist auf einem Rechner zu kompilieren, der den Portstree hat und dann die Paketdatei rüberkopieren und auf den pkg-only Systemen zu installieren:

cd /usr/ports/graphics/drm-fbsd12.0-kmod/
make package

produziert die Datei:
/usr/ports/graphics/drm-fbsd12.0-kmod/work/pkg/drm-fbsd12.0-kmod-4.16.g20200221.txz

Die kopierst Du auf das gewünschte System und machst dann ein
pkg add /PATH/TO/drm-fbsd12.0-kmod-4.16.g20200221.txz

Aber bei einem RELEASE erwarte ich, ohne eigenes Kompilieren auszukommen.

Dazu kann ich nichts sagen. Ich kann Dir nur Vorschläge machen, wie Du Dein Problem lösen könntest.

Das erscheint mir so irgendwie nicht ganz richtig, wie das gerade gehandhabt wird.

Vermutlich gibt es einfach noch keine etablierte Vorgehensweise Packages auch in Unterversionen zu unterscheiden oder das Problem anderweitig zu lösen. Man darf bei solchen Sachen halt auch nicht vergessen, das FreeBSD (wie viele andere Projekte auch) im wesentlichen Freiwilligen getragen wird. Und man hat tendenziell zu wenig Leute als zu viel. Man priorisiert also Dinge, die wichtig erscheinen und stellt alles andere hinten an.
Und dann fallen bestimmte Dinge halt hinten runter. Das kann man doof finden, aber ist nun mal so.

Zum Glück bedeutet aber Open Source auch, das jeder sich einbringen kann. Man kann also nicht nur rummäkeln was alles nicht so gut ist, man kann auch aktiv dazu beitragen die Situation zu verbessern. Das ist so diese Nehmen-und Geben-Geschichte. Weißt schon. :-)

 

[pit234a]

Man kann also nicht nur rummäkeln was alles nicht so gut ist

das stimmt und ich sehe das genau so.
Man kann darüber streiten, ob nun die Unterstützung von Grafik und ihrer Beschleunigung wirklich wichtig sind und ob es nicht sogar als SW von Dritten sowieso überhaupt gar nichts mit FreeBSD zu tun hat.
Es ist jedenfalls meine Sache, wie ich damit umgehen kann und weil ich einer von denen bin, die sowieso nicht vorher lesen, kann ich mich auch nicht über mangelnde Information beschweren, die mir dann die paar Stunden erspart hätte, welche ich nun durch eine eher seltene, unschöne Erfahrung aufbringen musste.
Vielleicht gerade deshalb, weil ich in der Vergangenheit zu sehr verwöhnt worden bin und eigentlich immer alles zuverlässig funktionierte, störte mich diese Ungereimtheit nun besonders und ich finde es nach wie vor unglücklich.

Nachdem ich dann auch noch ein Desaster mit einem missglückten freebsd-update rollback (noch nie gemacht) durchleben musste und damit das System wirklich so zerschoss, dass nicht mal mehr der Single-User-Modus gelingen wollte, kann ich nur sagen, dass ich Dank nomadbsd und ZFS relativ schnell wieder bei 12.1 gelandet bin und wohl auch dort noch eine Weile verharren werde. Vielleicht findet sich dann eine allgemeine Lösung über Pakete, also, im Grunde bräuchte man ja nur das entstehende Paket in einem 12.2 mit einem neuen Namen zu versehen und schon hätte man das.

Ansonsten ist die Idee natürlich gut, auf einem anderen System zu bauen. Das hatte ich früher ja häufiger gemacht.
Nun bin ich mit meinem Hauptrechner auf Latest und baue nur ganz ganz wenig. Ich glaube zwei Ports. Die Angst ist immer, dass man auf Latest eher mal ein derartiges Desaster erleben kann, wie oben angerissen und deshalb möchte ich die Laptops auch als eine Art "Notfall"-System bereit haben, um ohne erst etwas reparieren zu müssen, sofort damit meine Arbeit fortsetzen und beenden zu können, falls das denn mal nötig sein sollte. Deshalb blieb ich damit konservativ auf Quarterly, aber das ist natürlich eher Unsinn. Ich kann ja einfach nur zwei Wochen später updaten oder so und hätte damit auch mein Notfall-System parat.
Mal sehen, wie ich lustig bin.

 

[Andy_m4]

Man kann darüber streiten, ob nun die Unterstützung von Grafik und ihrer Beschleunigung wirklich wichtig sind und ob es nicht sogar als SW von Dritten sowieso überhaupt gar nichts mit FreeBSD zu tun hat.

Wobei diese Diskussion eine eher theoretische ist. Es ist ja weniger die Frage, ob was zum System dazu gehört oder nicht. Es ist eher die Frage, hat jemand die Zeit sich darum zu kümmern.

störte mich diese Ungereimtheit nun besonders und ich finde es nach wie vor unglücklich.

Ist ja durchaus verständlich.
Nur das macht ja niemand, um Nutzer wie Dich zu ärgern.
Die FreeBSD-Leute wollen solche Fehler auch nicht. Und wenns mal doch dazu kommt, würden sie die natürlich auch gern fixen.

Vielleicht findet sich dann eine allgemeine Lösung über Pakete, also, im Grunde bräuchte man ja nur das entstehende Paket in einem 12.2 mit einem neuen Namen zu versehen und schon hätte man das.

Das ist ein schönes Beispiel dafür, das Dinge zwar erst mal einfach scheinen, aber in Wirklichkeit dann doch nicht sind. :-)

Also ja. Im Prinzip könnte man einfach ein Paket drm-fbsd12.2-kmod machen. Aber was sind die Implikationen? Man möchte ja auch bei zukünftigen FreeBSD-Versionen einfach updaten können.
Deswegen gibts ja auch das drm-kmod-Package, was man nehmen soll und was je nach FreeBSD-Version das entsprechende Package als Abhängigkeit hat.

Wie sieht es bei den Ports aus und warum funktioniert das mit der Versionsabhängigkeit da?
Der drm-kmod-Port macht ja eine explizite Abfrage der FreeBSD-Versionsnummer und gestaltet danach seine Abhängigkeit (wie im obigen Posting von mir dargestellt).
Wenn man da eine weitere FreeBSD-Version unterstützen will braucht man nur zwei Zeilen anfügen die dann auf den entsprechend abhängigen Port verweisen und gut ist.

In dem Package drm-kmod was Du baust ist aber eine solche Abfrage nicht drin. Da ist die Abhängigkeit dann fest verdrahtet. Und da es keine unterschiedlichen Paket-Repositories für verschiedene Unterversionen von FreeBSD gibt (sondern nur für die Hauptversionen), hast Du halt dann ein Problem.

Das ließe sich auch durchaus lösen. Man könnte z.B. auch das Package mit nem Packagescript ausstatten was eine Versionsabfrage vornimmt und dann daraus das entsprechend abhängige Package wählt. Aber bisher gibt es das nicht. Das bedeutet, das Problem ist eben nicht trivial und "mal eben" zu lösen, sondern bedarf schon eines kleinen Mehraufwandes. Und dann sind wir wieder bei dem Problem: Wer hat Zeit für sowas

Was man noch machen könnte wäre eine Art Dirty-Hack. Man sagt sich einfach: Wir bauen so ein Paket und stellen es zur Verfügung und der Benutzer muss es dann explizit installieren.
Das heißt aber letztlich auf alles Sch***en was so das Abhäbngigkeits und Upgrade-Management angeht und wo man spätestens beim nächsten Upgrade die User wieder in Probleme laufen lässt.
Das ist halt das blöde daran. Wenn man so ein Package baut, muss man es auch längerfristig supporten.
Bedeutet auch wieder Aufwand. Auch wieder die Frage: Wer hat Zeit für sowas?

Ich hoffe, ich konnte einigermaßen anschaulich darstellen, wo das Problem liegt und warum es nicht leicht zu fixen ist. Ist zugegebenermaßen nicht einfach zu verstehen. :-)

Mal sehen, wie ich lustig bin.

Also wenn man ein vorsichtiger Nutzer ist, dann ist es sicher nicht verkehrt sich Zeit zu lassen mit Upgrades. Über kurz oder lang wird ja mit den Packages alles wieder funktionieren. Spätestens wenn, wie oben angemerkt, 12.1 End-of-Life ist und daher solche Packages durch gegen 12.2 kompilierte Packages ersetzt sind.
Und gerade für Notfallsysteme besteht ja auch kein Druck die zeitnah irgendwie hochziehen zu müssen.