Probleme mit xorg-server neuer als Version 21.1.7,1

[MichaZ]

Hallo @all.

Ich habe ein Problem mit dem xorg-server Paket in meinem freeBSD 13.2p1

Versionen oberhalb von xorg-server-21.1.7,1 funktionieren nicht.
Egal ob aus pkg installiert oder aus den Ports selbst gebaut, schaltet sich sich der Bildschirm aus, wenn eigentlich Loginmanager starten sollte.
In den Logs finde ich nichts auffälliges.
Die Grafikkarte ist eine im Ryzen 7 4750G integrierte AMD Renoir.

Auf einem anderen PC mit Uralt-Nvidia gab es keinerlei Probleme.

Hat bitte jemand einen Tipp, wo ich ansetzen muss?

Mfg

Michael

 

[Andy_m4]

xorg-server Paket in meinem freeBSD 13.2p1

Also so mal vorweg als Rückmeldung.
Ich hab hier ebenfalls ein FreeBSD 13.2p1 / AMD64 mit xorg-server-21.1.8_2,1 aus den Packages.
Grafikkarte ist eine AMD und ich benutze den amdgpu-Treiber.
Und ich kann hier keinerlei Probleme feststellen.

Hat bitte jemand einen Tipp, wo ich ansetzen muss?

Ich würde erst mal gucken, ob der amdgpu-Treiber geladen ist:
kldstat |grep amdgpu
Ich nehme mal an, mit "Logs gecheckt" meinst Du
/var/log/Xorg.0.log
?

Außerdem würde ich mal testweise den Login-Manager rausnehmen mich normal auf der "Textkonsole" einloggen und Xorg mit
startx
starten.
Erstens sieht man dann, ob das Problem vielleicht mit dem Login-Manger zusammenhängt (was durchaus mal vorkommen kann). Zweitens gibt einem startx auch noch Hinweise auf der Kommandozeile.

 

[bluescreen]

Hallo !

Da du eine amdgpu nutzt solltest du mal versuchen deinen Loginmanager
der Gruppe video zuzuordnen !

pw groupmod video -M lightdm

Danach mal einen Neustart !

Gruss

 

[bluescreen]

.......

sollte dein Loginmanager GDM sein , solltest du in deiner xorg.conf
dri3 abschalten !

Gnome3 kommt unter FreeBSD mit amdgpu+dri3 nicht klar , is`n bug !!


Gruss

 

[MichaZ]

Hallo !

Da du eine amdgpu nutzt solltest du mal versuchen deinen Loginmanager
der Gruppe video zuzuordnen !

pw groupmod video -M lightdm

Danach mal einen Neustart !

Gruss

Das hat leider nichts gebracht.

 

[MichaZ]

Dummerweise habe ich vorhin wohl 2x das gleiche Logfile betrachtet.

Es sind doch deutliche Unterschiede im Xorg.log

Schaut mal bitte:

 

[cabriofahrer]

Da du eine amdgpu nutzt solltest du mal versuchen deinen Loginmanager
der Gruppe video zuzuordnen !

pw groupmod video -M lightdm

Das habe ich noch nie gehört. Dass man bei AMD und Intel den User der Gruppe "video" zuordnen muss, ist bekannt. Aber jetzt auch den Loginmanager? Wo steht das?

 

[Andy_m4]

Schaut mal bitte

Die Einträge sehen auffällig aus:

[  1416.095] (II) AMDGPU(0): Setting screen physical size to 508 x 317
[  1416.159] (EE) AMDGPU(0): failed to set mode: Cannot allocate memory
[  1416.159] (WW) AMDGPU(0): Failed to set mode on CRTC 0
[  1416.191] (EE) AMDGPU(0): Failed to enable any CRTC

Wie ists denn ohne Login-Manager?
Steht in der /var/log/messages etwas?
Kommt man eigentlich auf eine andere virtuelle Konsole wenn der "Bildschirm aus" ist?

Aber jetzt auch den Loginmanager? Wo steht das?

Könnte theoretisch sein.
In der Gruppe video soll man ja deshalb sein, damit man auch auf entsprechende Video-Devicefile (/dev/drm/0 oder so ähnlich) zugreifen kann. Wenn der Login-Manager als root läuft, ist das kein Problem. Wenn er aber unter einem Benutzeraccount (lightdm) läuft, könnte das natürlich ein Problem sein.

 

[cabriofahrer]

Wenn der Login-Manager als root läuft, ist das kein Problem. Wenn er aber unter einem Benutzeraccount (lightdm) läuft, könnte das natürlich ein Problem sein.

Alle Loginmanager laufen doch als root, auch lightdm. Ich habe nie gehört, dass lightdm unter einem Benutzeraccount läuft? Wie sollte das überhaupt gehen? Man hat doch den Eintrag lightdm_enable="YES" in der /etc/rc.conf, damit wird lightdm automatisch gestartet, bevor man sich überhaupt als Benutzer einloggen kann?

 

[Andy_m4]

Alle Loginmanager laufen doch als root, auch lightdm

Dazu kann ich nichts sagen, da ich lightdm nicht im Einsatz hab.
Man kann aber einfach mal mit ps (ps au) nachgucken unter welchem Nutzeraccount lightdm läuft. Dann weiß man es definitiv und muss nicht sinnfrei umherraten.

Wie sollte das überhaupt gehen?

Na ganz einfach. lightdm wird ganz normal als root via rc-Init gestartet und limitiert sich dann selbst. Ein völlig übliches Verfahren.
Wenn Du z.B. einen Webserver hast, stuft der sich auch üblicherweise runter z.B. auf den Useraccount www.

damit wird lightdm automatisch gestartet, bevor man sich überhaupt als Benutzer einloggen kann?

Benutzeraccounts haben nur mittelbar was mit dem einloggen zu tun. Das ist in erster Linie eine Rechtegeschichte. Du hast auf der einen Seite ein Subjekt (der Nutzeraccount) und der hat Rechte auf bestimmte Objekte (z.B. Dateien - siehe Dateirechte) zuzugreifen.
Alles andere kommt dann quasi on-top.
Selbst auf einem nackten FreeBSD-System hast Du viele Useraccounts (daemon, tty, man, nobody usw.) die nicht dafür gedacht sind, das man sich damit einloggt.

 

[bluescreen]

Moin !

Hat vielleicht noch kein Einzug in FreeBSD gehalten !

Title: xorg-server dropping default suid
Author: Piotr Karbowski <slashbeast@gentoo.org>
Posted: 2020-06-24
Revision: 3
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

Starting 2020-07-15, stable keyworded x11-base/xorg-server will default
to using the logind interface instead of suid by default. resulting in
better security by default through running the server as a regular user
instead of root. However, this will require our users to use a logind
provider such as elogind or systemd. The systemd users and those who are
not using systemd but use desktop profiles can stop reading here, as
they already have a logind provider enabled.

Others, who have neither systemd or desktop profiles enabled will be
required to globally enable 'elogind' USE flag and update the system

# emerge --newuse @world

Afterwards, one will need to re-login, so the PAM can assign a seat. One
can confirm that a seat has been assigned upon login by running:

$ loginctl user-status

Users who do not wish to use logind interface or have rare hardware that
does not use KMS and because of that, require root privileges to
operate, can manually re-enable 'suid' and disable 'elogind' USE flags
in order to preserve the previous behavior. However, please note that
this is heavily discouraged to run X server as root due to security
reasons. The 'suid' USE flag will remain as optional opt-in for the need
of legacy hardware.


Unter gentoo-linux ist es so , wahrscheinlich bei anderen linux-distros auch !!

Gruss

 

[MichaZ]

Wie ists denn ohne Login-Manager?
Steht in der /var/log/messages etwas?
Kommt man eigentlich auf eine andere virtuelle Konsole wenn der "Bildschirm aus" ist?

Zu 1
Ohne Loginmanager als User mit startx siehe Bild unten.
Ohne Loginmanager als root läuft startx in die Abschaltung des Bildschirmes.

Zu 3
Das Ist kein Problem. Mit Strg-Alt-Fx für eine beliebige Konsole geht der Bildschirm sofort wieder an.

Zu2 wird gleich nachgeliefert. ;-)

 

[Andy_m4]

Wie ist überhaupt die Systeminstallation? Nutzt Du Packages oder Ports oder beides? Und wenn Packages, aus dem latest oder aus dem quarterly-Repository?
Hast Du irgendwie eine xorg.conf ?

 

[MichaZ]

Wie ists denn ohne Login-Manager?
Steht in der /var/log/messages etwas?
Kommt man eigentlich auf eine andere virtuelle Konsole wenn der "Bildschirm aus" ist?

Auf die Konsolen kann ich umschalten, kein Problem.

/var/log/messages

Schaue ich nachher an, wenn ich wieder zu Hause bin.

Ohne Loginmanager mit startx, sieht es so aus, wie auf dem angehängten Fotos.

 

[MichaZ]

Hier noch die fehlende /var/log/messages

 

[MichaZ]

Wie ist überhaupt die Systeminstallation? Nutzt Du Packages oder Ports oder beides? Und wenn Packages, aus dem latest oder aus dem quarterly-Repository?
Hast Du irgendwie eine xorg.conf ?

Ich nutze Packages und Ports aus dem quarterly-Repository.
Eine spezielle xorg.conf habe ich nicht

Wegen "1416.159] (EE) AMDGPU(0): failed to set mode: Cannot allocate memory" habe ich versucht, den Grafikspeicher im BIOS von der automatischen Verwaltung (Game Mode) auf einen festen Speicherwert umzustellen, aber auch das brachte nichts.

MfG

Micha

 

[Andy_m4]

Ich nutze Packages und Ports aus dem quarterly-Repository.

Man könnte versuchen auf latest zu wechseln (was insbesondere bei einem Desktop-System ohnehin keine schlechte Idee ist). Falls es irgendein Bug ist, dann wird er da am ehesten gefixt.
Allerdings sind quarterly und latest im Augenblick noch nicht so weit auseinander, so das sich eigentlich kein signifikanter Unterschied zeigen dürfte. Wenn man Boot-Environments nutzt, könnte man das aber mal gefahrlos probieren.

Hier noch die fehlende /var/log/messages

Sieht unauffällig aus.

 

[bluescreen]

Hallo !

Versuch es mal so :

1. Kontrolliere ob im Ordner /boot/modules die Firmware für deine Karte vorhanden ist !
amdgpu_renoir_XXX_bin.ko --> müsten 12 dateien sein
wenn nicht : pkg install graphics/gpu-firmware-amd-kmod graphics/drm-515-kmod

2. In rc.conf folgenden Eintrag : kld_list="amdgpu"

3. In /usr/local/etc/X11/xorg.conf.d/10-amdgpu.conf


#
Section "Device"
Option "DRI3" "True"
Option "TearFree" "True"
Option "VariableRefresh" "True"
Identifier "Card0"
Driver "amdgpu"
EndSection

Section "Module"
Load "glx"
EndSection



Dann mal neustarten ! ( Erst mal manuell , mit startx)

So klappt alles bei meiner AMD-Karte einwandfrei !!

Gruss

 

[MichaZ]

Erstmal ein dickes Dankeschön an alle, die geholfen haben.

Ich habe es mit einem geleerten Boot Environtment probiert und dort funktionierte es.

Dann habe ich in einer Kopie des default BE nur die xorg-Teile deinstalliert, also xorg, xorg-server, xorg-drivers, den Rest (ca 85 Pakete) mit pkg autoremove entfernt.
FreeBSD update, ports update, und dann mit pkg xorg neu installiert.
Sowohl in der Kopie als auch im default-BE funktionierte das Update dann.

Danke euch.

Gruß

Micha