Forums Neueste Beiträge
 

[systemd] Nach update kein KMS mehr

21/06/2014 - 10:31 von Dominic Valerie Casare | Report spam
Hallo zusammen,

ich bin seit einigen Tagen schon etwas ratlos, frustriert und hoffe, ihr
koennt mir hier einen hilfreichen Tipp geben.

Mein System ist eine neu installierte openSUSE 13.1, also kein update
einer aelteren Version und es lief auch alles prima. Dann machte ich vor
3 Tagen eine kleine update-session mit regulaeren Vorschlaegen und als
ich am naechsten Tag den Rechner hochfuhr, wurde die Grafik nicht mehr
von den per grub2 eingestellten 1400x1050 auf full HD umgeschaltet.

Nun began die Suche danach, was dort passiert war; in der Liste der
Updates vom Vortag fanden sich u.a. auch der systemd samt udev-subsystem
und das ist wohl auch fuer die Aktivierung von KMS zustaendig, nehme ich
zumindest mal an. Also habe ich die ganze Auswahl wieder auf die
vorherige Version downgegradet, allerdings ohne Auswirkungen. Meint:
Beim Booten wird gar kein KMS mehr ausgefuehrt und ich weiss nicht,
warum.

Ein Blick in dmesg und der Vergleich mit einer frueheren, zufaellig
abgespeicherten Version offenbarte mir auch nur diesen Umstand, nicht
jedoch einen Hinweis auf die Ursache:

[dmesg-alt]--
...
[ 1.519986] systemd-udevd[112]: starting version 208
[ 1.537839] [drm] Initialized drm 1.1.0 20060810
[ 1.539890] ACPI: processor limited to max C-state 1
[ 1.545196] [drm] radeon kernel modesetting enabled.
[ 1.545274] checking generic (d0000000 5b0000) vs hw (d0000000
10000000)
[ 1.545279] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
[ 1.545294] Console: switching to colour dummy device 80x25
[ 1.545594] [drm] initializing kernel modesetting (RS880
0x1002:0x9710 0x1458:0xD000).
[ 1.545607] [drm] register mmio base: 0xFDFE0000
[ 1.545608] [drm] register mmio size
...
es folgen noch etwa 50 Zeilen mit starkem Bezug zu [drm]

-

[dmesg-neu]--
...
[ 1.478945] systemd-udevd[112]: starting version 208
[ 1.491951] ohci-pci: OHCI PCI platform driver
[ 1.492139] ohci-pci 0000:00:12.0: OHCI PCI host controller
[ 1.492154] ohci-pci 0000:00:12.0: new USB bus registered, assigned
bus number 3
[ 1.492198] ohci-pci 0000:00:12.0: irq 16, io mem 0xfe02e000
[ 1.495544] ACPI: processor limited to max C-state 1
[ 1.525129] usb 1-2: New USB device found, idVendor24,
idProduct%24
[ 1.525133] usb 1-2: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 1.525275] hub 1-2:1.0: USB hub found
...
bis zum Ende keine Zeile mehr mit [drm] (vorher auch nicht)

-

Bevor ich jetzt aus Verzweiflung irgend etwas radikales versuche, hier
meine Fage: Wie kann ich der Ursache auf den Grund gehen und/oder das
KMS einfach wieder und dauerhaft aktivieren?

TIA
Dominic
 

Lesen sie die antworten

#1 Andreas Hartmann
22/06/2014 - 07:01 | Warnen spam
Hallo Dominic,

[Frage zu in dmesg nicht mehr gefundenem radeon-Module nach reboot nach
Updates auf openSUSE 13.1]

Falls Deine genannten Untersuchungen soweit ok sind, wird das
radeon-Module nicht mehr geladen. Du könntest das ganze mal
verifizieren, indem Du im laufenden System nachschaust, ob das Module
radeon evtl. doch geladen ist, weil es z.B. spàter geladen wurde:

lsmod | grep radeon

-> da sollte was gefunden werden.

(Evtl. (aus welchem Grund auch immer, der fglrx geladen? Bitte mit lsmod
| grep fglrx verifizieren))

Falls nichts gefunden wurde (weder radeon noch fglrx), kannst Du ja mal
als root versuchen, radeon von Hand zu laden:

modprobe radeon

Was passiert jetzt? Evtl. nach Fehlermeldungen im Journal schauen
(journalctl -n 20 - als root)


Wurde evtl. auch der Kernel bei Deiner Updatesession ausgetauscht
(kernel-desktop heißt das Paket)?


Es könnte auch sein, dass die Erstellung des initrd-Files nicht sauber
gelaufen ist. Einfach mal als root

mkinitrd

eingeben. Da werden dann diverse Modules gelistet, die geladen werden
sollen beim Booten. Da sollte auch radeon und sàmtliche zugehörige
Firmwarefiles dabei sein. Zumindest sollte das vollstàndig ohne Fehler
durchlaufen.


Ich hatte beim letzten Update, wo udev und mdadm dabei waren, jedenfalls
Probleme mit der Erstellung des initrd-Files (beide Pakete triggern
das). Der hing bei mir jeweils bis zum Sankt-Nimmerleins-Tag. Hab dann
einfach den unter Zypper laufenden rpm-Prozess hart rausgekillt und
mkinitrd von Hand aufgerufen und alles war gut :-).

Soweit das mal zum weiteren Vorgehen. Evtl. können noch mehr Schritte
eingeleitet werden, ja nach Ergebnissen von oben :-)



Gruß,
Andreas

Ähnliche fragen