[Arch] Xorg crasht (no screens found) sinds upgrade

[BlueMotion]

Mijn vraag: Hoe krijg ik mijn Xorg/displaydriver weer aan de praat?

Op mijn desktop maak ik al enkele jaren tevreden gebruik van Arch Linux. In die tijd heb ik het wel eens stukgemaakt en weer gerepareerd. Maar nu lukt het me niet meer om mijn systeem weer op de rit te krijgen.

Ergens eind maart had ik het wat druk met studie en werk en heb ik eens achteloos een update gedaan (pacman -Syu) en niet gecontroleerd wat de gevolgen waren. Sindsdien heb ik problemen met het beeld. Bij het laden van de modules bij het booten hoor ik de speakers even kraken en direct daarna gaan de monitoren in slaapstand(geen signaal). Als ik dan even wacht kan ik de machine wel via ssh benaderenmaar ik kan geen sessie openen. (als ik met ssh direct een commando meestuur werkt dat wel, ik kan m dus wel min of meer bedienen).

Op de intel graphics pagina van de befaamde Arch wiki wordt bij troubleshooting aangeraden om de intel_agp en i915 modules te laden, dat lost het probleem echter niet op. Ook de boot parameter video=SVIDEO-1:d lijkt niets uit te halen, net als de Xorg.conf opties die daar staan.

Verder heb ik nog ergens gelezen dat het handig kon zijn om de intel microcode (intel-ucode) te installeren. Dat resulteerde echter in een kernel panic, dus dat heb ik maar weer ongedaan gemaakt

in de logs (xorg, boot, dmesg) vind ik niet echt aanknopingen en nu weet ik even niet meer hoe ik verder moet. Misschien zie ik iets over het hoofd. Hebben jullie een idee?

Ik gebruik trouwens Arch Linux (64 bit) dus, huidige kernel 4.5 en de integrated gpu van de intel i2500K processor voor de graphics

[ Voor 0% gewijzigd door BlueMotion op 04-05-2016 21:49 . Reden: ssh is gefixt ]

[Hero of Time]

Dit klinkt heel erg als een missende driver voor Xorg. Denk aan package namen lijkende op xserver-xorg-video-intel e.d. (dat is de naam die bij Debian gebruikt wordt, Arch zal vast wel een andere hanteren).

Het is vreemd dat je geen normale SSH sessie op kan zetten. Kan je wel naar een TTY wisselen (ctrl+alt+F3 bijvoorbeeld)? Zoniet, start dan eens met de kernel parameter om naar de systemd multiuser.target te gaan, ipv de standaard graphical.target. Dan heb je iig een CLI systeem waar je mee kan werken en verder uitzoeken wat er aan de hand is. En eventueel updaten, mogelijk is het al opgelost maar heb je de update nog niet.

[BlueMotion]

Bedankt voor de tip van de systemd multiuser.target parameter. Het heeft alleen niets geholpen Mijn systeem startte sowieso eerst naar een CLI login, en na het inloggen word er pas een grafische omgeving geladen. Wisselen van tty werkt dus ook niet omdat de video-output er al veel eerder mee stopt.

De video-driver voor Arch heet trouwens xf86-video-intel, bedoel je die? Die had ik gewoon geinstalleerd (zou trouwens niet nodig moeten zijn).

Het is me inmiddels wel gelukt om een normale SSH sessie op te zetten door in .bash_profile eerst te controleren of er wel een display is voordat startx uitgevoerd moet worden Doordat X crashte werd de sessie direct weer verbroken.

De machine is dus weer benaderbaar. Het slechte nieuws is dat een verse update het probleem niet verhelpt..

[Hero of Time]

Kan je anders wat snippets van Xorg.0.log posten? En versies van de verschillende packages (welke xorg, driver) en welke videokaart het is (eventueel met andere specs).

[BlueMotion]

Hmm, die xorg log is wel een paarhonderd regels lang. Ik heb gebrobeerd het een beetje ontopic te houden, er staan in ieder geval geen gekke errors/meldingen in. Xorg beweert dat er niets is aangesloten op de video uitgangen, terwijl ik netjes het boot-logo zie en zelfs het keuzemenu van de bootloader. Als ik dan doorstart naar Arch valt het beeld weg, (Starting version ...) en dan is het afgelopen.

Xorg.0.log (gefilterd)

code:

X.Org X Server 1.18.3
Release Date: 2016-04-04
[   277.712] X Protocol Version 11, Revision 0
[   277.712] Build Operating System: Linux 4.2.5-1-ARCH x86_64
[   277.713] Current Operating System: Linux arch 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64
[   277.713] Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=f9cc44d3-dd85-4bc1-8ae6-6c78d865cdad rw quiet add_efi_memmap
[   277.713] Build Date: 05 April 2016  05:24:02PM

[   277.713] Current version of pixman: 0.34.0

[   277.715] (==) ServerLayout "X.org Configured"
[   277.715] (**) |-->Screen "Screen0" (0)
[   277.715] (**) |   |-->Monitor "Monitor0"
[   277.715] (**) |   |-->Device "Card0"
[   277.715] (**) |   |-->GPUDevice "Card0"

[   277.720] (II) Module ABI versions:
[   277.720]    X.Org ANSI C Emulation: 0.4
[   277.720]    X.Org Video Driver: 20.0
[   277.720]    X.Org XInput driver : 22.1
[   277.720]    X.Org Server Extension : 9.0
[   277.721] (--) using VT number 2

[   277.729]    ABI class: X.Org Video Driver, version 20.0

[   277.730] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000

[b][   277.733] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000[/b]

[   277.760] (II) intel(0): Output VGA1 using monitor section Monitor0
[   277.866] (II) intel(0): Output HDMI1 using monitor section Monitor0
[   277.866] (II) intel(0): Output DP1 has no monitor section
[   277.973] (II) intel(0): Output HDMI2 using monitor section Monitor1
[   277.973] (II) intel(0): Output DP2 has no monitor section
[   278.000] (II) intel(0): EDID for output VGA1
[   278.106] (II) intel(0): EDID for output HDMI1
[   278.106] (II) intel(0): EDID for output DP1
[   278.213] (II) intel(0): EDID for output HDMI2
[   278.213] (II) intel(0): EDID for output DP2
[   278.213] (II) intel(0): Output VGA1 disconnected
[   278.213] (II) intel(0): Output HDMI1 disconnected
[   278.213] (II) intel(0): Output DP1 disconnected
[   278.213] (II) intel(0): Output HDMI2 disconnected
[   278.213] (II) intel(0): Output DP2 disconnected
[   278.213] (WW) intel(0): No outputs definitely connected, trying again...
[   278.213] (II) intel(0): Output VGA1 disconnected
[   278.213] (II) intel(0): Output HDMI1 disconnected
[   278.213] (II) intel(0): Output DP1 disconnected
[   278.213] (II) intel(0): Output HDMI2 disconnected
[   278.213] (II) intel(0): Output DP2 disconnected
[   278.213] (WW) intel(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
[   278.214] (II) intel(0): Allocated new frame buffer 1024x768 stride 4096, tiled

[   278.582] (II) Server terminated successfully (0). Closing log file.

De videochip is dus de intel HD graphics 3000, onderdeel van een core i5 2500k. Verder zijn er een aantal packages voor intel geinstalleerd.

code:

$ pacman -Qs intel
local/lib32-mesa 11.2.1-1
    an open-source implementation of the OpenGL specification (32-bit)
local/libva-intel-driver 1.7.0-1
    VA-API implementation for Intel G45 and HD Graphics family
local/mesa 11.2.1-1
    an open-source implementation of the OpenGL specification
local/phc-intel 0.3.2.12.19-1
    frequency driver for Intel CPUs with undervolting feature
local/sdcc 3.5.0-2
    Retargettable ANSI C compiler (Intel 8051, Maxim 80DS390, Zilog Z80 and the Motorola 68HC08)
local/xf86-video-intel 1:2.99.917+641+ge4ef6e9-1 (xorg-drivers xorg)
    X.org Intel i810/i830/i915/945G/G965+ video drivers

[Hero of Time]

Er staan geen warnings en errors in, anders dan de "Unable to find connected outputs"? Heb je trouwens ook al eens geboot naar een vorige kernel?

[CAPSLOCK2000]

Heb je een /etc/X11/xorg.conf of /etcX11/xorg.conf.d ?

Vroeger was het min of meer verplicht een xorg.conf te hebben, tegenwoordig wordt vrijwel alles automatisch getecteerd. Een oude configuratiefile kan daar mee botsen. Ik adviseer upgraders met problemen daarom om het eens zonder config te proberen.

[BlueMotion]

CAPSLOCK2000 schreef op vrijdag 06 mei 2016 @ 12:19:
Heb je een /etc/X11/xorg.conf of /etcX11/xorg.conf.d ?

Ik had geen files staan in xorg.conf.d, tot ik ergens de tip las om een intel conf file toe te voegen

code:

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "DRI"   "false"
EndSection

Dat hielp echter niets.

de 'gewone' xorg.conf heb ik wel. Die weghalen resulteert slechts in het niet kunnen vinden van monitor sections voor de displays...

Inmiddels heb ik de kernel gedowngrade naar 4.4.1 (Volgens het pacman archief zijn die pakketten van 1 februari, een datum waarvan ik (vrij) zeker weet dat het toen nog werkte). Met deze config ziet xorg de schermen wel, maar:

code:

xrandr: Output DP1 is not disconnected but has no modes
xrandr: Output DP2 is not disconnected but has no modes
xrandr: Output HDMI1 is not disconnected but has no modes

Dat is op zich een verbetering, alleen ik snap nog steeds niet waarom het beeld al wegvalt voordat ik in kan loggen (in de terminal). Tot die tijd zou X toch niet gestart moeten worden?

maar nu eerst een weekje vakantie

[Hero of Time]

X wordt al gestart voordat je op een TTY kan inloggen. Er worden nog een aantal andere services gestart ten tijde van het starten van de display manager (login scherm). Die hebben geen afhankelijkheden van elkaar, dus dat geeft geen probleem.

[BlueMotion]

De kernel-downgrade heeft het probleem nog niet verholpen, maar blijkbaar heeft mijn herinnering me even in de steek gelaten want hier:

https://ask.fedoraproject...-turning-off-during-boot/

heeft iemand het probleem bij versies na 4.4.4, waar ik op 4.4.1 zat. Nadat het downgraden van alle video- en x packages nog niet uithaalde heb ik nog maar een kernel downgrade gedaan naar 4.3.5. Inmiddels heb ik weet mijn vertrouwde tty loginscherm als ik boot. Nu eens kijken of er nog andere gekke dingen zijn en kijken hoe/wanneer ik wel weer kan upgraden.

edit: ik gebruik trouwens ook een HDMI->DVI verloopkabel voor een van de monitoren, de 2e is gewoon DVI

[ Voor 8% gewijzigd door BlueMotion op 16-05-2016 12:58 ]

[Hero of Time]

Als je echt twijfelt aan je schermconfiguratie, kan je natuurlijk altijd die HDMI -> DVI loskoppelen. Maar kijk eerst maar eens wat je nu allemaal naar voren kan krijgen aan foutmeldingen e.d.

[BlueMotion]

Ik krijg nog steeds geen foutmeldingen uit Xorg, maar hij crasht nu direct na het inloggen met mijn .xinitrc

code:

xrandr --output HDMI2 --primary --auto --output HDMI1 --auto --right-of HDMI2

xcompmgr &
devilspie -a &

#exec /usr/bin/awesome >> ~/.cache/awesome/stdout 2>> ~/.cache/awesome/stderr

als ik deze verwijder en dus met de default xinitrc inlog dan doet hij het wel, en krijg een paar xterm vensters te zien.

Nu dacht ik dus dat een van de opdrachten uit mijn xinitrc de boosdoener was, maar als ik die na het inloggen allemaal, in deze volgorde uitvoer, dan krijg ik mijn vertrouwde omgeving gewoon te zien en die lijkt volledig functioneel te zijn.

Ik heb het idee dat xrandr bij het aanroepen door xinit (nog) geen toegang heeft tot de displays, waarna hij stopt en dus x server laat stoppen. Iemand een idee wat ik daar aan kan doen?

[Hero of Time]

Door de xrandr regel uit te laten? Wat krijg je dan?

[BlueMotion]

Als ik de xrandr regel weglaat crasht hij nog steeds, maar als ik vervolgens xcompmgr en devilspie ook weglaat en dus rechtstreeks Awesome opstart kom ik er wel in, maar dan zie ik op beide schermen hetzelfde (en awesome waarschuwt me dat bepaalde dingen niet gelukt zijn omdat er geen scherm 2 gevonden is).

Inmiddels heb ik een verse kopie gemaakt van /etc/X11/xinit/xinitrc en daar de regel voor Awesome aan toegevoegd. Het verschil dat ik merk is dat Skype nu wel opgestart wordt.

Edit: right.. Als ik het xrandr commando 2x achter elkaar in de .xinitrc zet gaat het soms wel goed. Dat was een vrije interpretatie van https://wiki.archlinux.or...ng_X_crash_with_xrasengan

Eens kijken wat er gebeurt als ik er een beetje pauze tussen plak.

[ Voor 23% gewijzigd door BlueMotion op 22-05-2016 13:45 ]

[Hero of Time]

Als het weglaten van xrandr geen verschil geeft, kan het ook een van de andere twee programma's zijn, xcompmgr en devilspie.

Ik heb nooit de noodzaak gehad om m'n GUI via xinitrc te starten, ik gebruik altijd een display manager hiervoor, zoals Slim of LightDM. Is er een specifieke reden waarom je die niet gebruikt/kan gebruiken?

[_JGC_]

BlueMotion schreef op zondag 22 mei 2016 @ 10:54:
Ik krijg nog steeds geen foutmeldingen uit Xorg, maar hij crasht nu direct na het inloggen met mijn .xinitrc

code:

xrandr --output HDMI2 --primary --auto --output HDMI1 --auto --right-of HDMI2

xcompmgr &
devilspie -a &

#exec /usr/bin/awesome >> ~/.cache/awesome/stdout 2>> ~/.cache/awesome/stderr

als ik deze verwijder en dus met de default xinitrc inlog dan doet hij het wel, en krijg een paar xterm vensters te zien.

Nu dacht ik dus dat een van de opdrachten uit mijn xinitrc de boosdoener was, maar als ik die na het inloggen allemaal, in deze volgorde uitvoer, dan krijg ik mijn vertrouwde omgeving gewoon te zien en die lijkt volledig functioneel te zijn.

Ik heb het idee dat xrandr bij het aanroepen door xinit (nog) geen toegang heeft tot de displays, waarna hij stopt en dus x server laat stoppen. Iemand een idee wat ik daar aan kan doen?

Als xinitrc eindigt wordt X gestopt. Met jouw xinitrc start je een paar programma's in de achtergrond en vervolgens sluit X af omdat xinit klaar is.

[BlueMotion]

Hero of Time schreef op zondag 22 mei 2016 @ 14:43:
Als het weglaten van xrandr geen verschil geeft, kan het ook een van de andere twee programma's zijn, xcompmgr en devilspie.

Ik heb nooit de noodzaak gehad om m'n GUI via xinitrc te starten, ik gebruik altijd een display manager hiervoor, zoals Slim of LightDM. Is er een specifieke reden waarom je die niet gebruikt/kan gebruiken?

Scherp. Ik heb nu xcompmgr en devilspie uitgeschakeld en voer dus alleen xrandr uit voordat ik awesome start. Dat lijkt nu meestal wel goed te gaan, wel merk ik dat de netwerk daemon af en toe een schop moet hebben vlak na het inloggen. Dat zou natuurlijk compleet ongerelateerd kunnen zijn, maar dat lijkt er ook op te wijzen dat het laden van modules niet altijd snel genoeg gaat,

Als ik xcompmgr en devilspie handmatig start direct na het inloggen, dan doen ze ook wat ze moeten doen, Blijkbaar zit er in die combinatie iets niet helemaal lekker.

En waarom ik geen display manager gebruik? Ik heb nog niet een reden gevonden om er een nodig te hebben en dus te installeren. Wat is precies het voordeel van een display manager?

_JGC_ schreef op woensdag 25 mei 2016 @ 19:22:
[...]

Als xinitrc eindigt wordt X gestopt. Met jouw xinitrc start je een paar programma's in de achtergrond en vervolgens sluit X af omdat xinit klaar is.

Eeh, met die exec regel als comment is dat inderdaad het geval. Die exec wordt wel uitgevoerd nu. Ik ben blijkbaar ietwat slordig geweest met kopieren..

Nu eerst maar eens wat achterstallig werk doen voordat ik weer een poging ga doen tot upgraden...

[Hero of Time]

BlueMotion schreef op woensdag 25 mei 2016 @ 20:49:
[...]

Scherp. Ik heb nu xcompmgr en devilspie uitgeschakeld en voer dus alleen xrandr uit voordat ik awesome start. Dat lijkt nu meestal wel goed te gaan, wel merk ik dat de netwerk daemon af en toe een schop moet hebben vlak na het inloggen. Dat zou natuurlijk compleet ongerelateerd kunnen zijn, maar dat lijkt er ook op te wijzen dat het laden van modules niet altijd snel genoeg gaat,

Dat kan ook door eventueel dbus verbinding komen, als je NetworkManager gebruikt. Die leunt zwaar op dbus calls en als je NM start voordat je dbus x11 sessie er is, kan 't niet goed z'n werk doen. Maar waarom heb je een grafische netwerk manager op de desktop? Nergens voor nodig, dat ding gaat nergens heen. Gewoon statisch in je config zetten en klaar. CLI, GUI, het boeit niet waar je in zit, je hebt dan gewoon netwerk. Dat was juist een van de grootste nadelen van NetworkManager vroeger, geen GUI betekende geen netwerk totdat je handmatig de zooi aanzwengelde. Altijd leuk als je dus een driver update had oid en je X startte niet meer. Hoe ging je dat fixen? Door een andere versie uit de repo te trekken. Owja, geen netwerk, dus geen repo beschikbaar.
Ik heb op mijn PC en HTPC ook geen manager draaien, gewoon statisch ingesteld en gaan.

En waarom ik geen display manager gebruik? Ik heb nog niet een reden gevonden om er een nodig te hebben en dus te installeren. Wat is precies het voordeel van een display manager?

Ik kan er wel een paar bedenken:
- Makkelijker van DE wisselen
- Je kan de login manager instellen voor automatisch inloggen, of dat je gebruiker al is ingevuld.
- Power opties zonder te hoeven inloggen
- Mogelijkheid tot integratie lockscherm, mits je LightDM gebruikt (met lightlocker)

En er zijn er vast nog wel meer, maar dit is wat ik even zo kan bedenken.

[BlueMotion]

Inmiddels zijn we een paar maanden verder en al die tijd heb ik op de oude kernel gewerkt, tot eind vorige maand.

Op een regenachtige zondagmiddag heb ik eens diep ademgehaald en brutaalweg pacman -Syu gedaan. Na wat horten en stoten lukte de volledige upgrade in 1 keer en wist de intel driver mij te melden dat DRI3 nu standaard is en dat je bij problemen moest terugvallen op DRI2, met daarvoor de voorbeeldconfig erbij. Maar met DRI3 loopt het als een zonnetje.

Ik heb heel sterk het vermoeden dat dat destijds ookal het probleem was. Ik ben in ieder geval weer helemaal bij Nogmaals bedankt voor al het meedenken,