Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47044 - [linux] i915: black display with modeset=1 when stopping LightDM/nodm

Attached to Project: Arch Linux
Opened by Daniel Hahler (blueyed) - Thursday, 12 November 2015, 00:57 GMT
Last edited by Thomas B├Ąchler (brain0) - Saturday, 30 July 2016, 12:24 GMT
Task Type Bug Report
Category Kernel
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

When running "systemctl stop lightdm.service" from VT1, lightdm gets stopped and the screen turns black.
I can still ssh into the machine and commands/input work (e.g. "sudo reboot"), but nothing gets displayed.

It also happens with "nodm" instead of "LightDM".

It does not happen when using the "fbdev" driver instead of "intel" (or none) in /etc/X11/xorg.conf.d/20-intel.conf, regardless of having used "i915.modeset=1" (the default) or "i915.modeset=0" during boot.

It does not happen when using "startx" with a custom ~/.xinitrc, which I've stopped using "pkill Xorg", but am not sure currently anymore.

It does not happen when using "sleep 5" before the "stop" command, and switching to VT7 before it gets stopped from there.


A weird workaround is to close the lid, let the system suspend and then re-open it, which fixes the display.

The system is a Lenovo X250.

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 2226
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 3000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #6 (rev e3)
00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)



linux 4.2.5-1.
I have just tried it with "linux 4.3-1" from testing, and the issue persists.

I don't remember if it also happens with linux-lts, but would say so - need to verify it though.

It is likely a upstream bug, but I am not sure where to report it, because it's not clear to me what is triggering/causing it. Therefore I'd like to have it confirmed / investigate further.
This task depends upon

Comment by sven (commonuser) - Sunday, 22 November 2015, 14:00 GMT
Don't know if it's related, but I have a similar issue with GDM when it's using Wayland.

It sometimes (1 in 5 or so) happens after logout, the screen turns black and I can't switch to another VT.
Connecting via SSH or reboot via magic keys works. But the screen stays black till reboot.

The problem disappeared after setting GDM to X.
Comment by Who? (maraku) - Saturday, 27 February 2016, 21:54 GMT
I get a black display as well after starting x(using startx) and waiting an hour or putting my computer to suspend.
dmesg doesn't complain about anything when switching to a VT. occasionally(one every ten times or so) the chip will
hang with a [drm] stuck on render ring.
Comment by mattia (nTia89) - Monday, 02 October 2017, 20:07 GMT
is this issue still valid?

Loading...