Created attachment 116010 [details] Xorg log I was told to post here the bug i've already filed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786382 Please, refer to that bug report for details. Now i'll just add missing or less clear informations. uname -m: x86_64 xf86-video-intel: 2.99.917 xserver: 1.17.1 mesa: 10.5.5 libdrm: 2.4.60 uname -r: 4.0.0-1-amd64 This is the debian kernel version scheme. The actual kernel version is: 4.0.2. Distribution: Debian Sid (unstable) Machine: notebook Asus PU301LA (in the original BR there is a typo in the model) CPU: Intel i7 4500U GPU: integrated HD4400 As i said in the original bug report, following the indicated steps, the problem is always reproducible for me. I'll attach later the intel_reg_dumper tool output: now i'm not able to make such test. Cesare.
Created attachment 116011 [details] Xrand --verbose output
Created attachment 116012 [details] intel_reh_dumper before VT switch
Created attachment 116013 [details] intel_reh_dumper after VT switch
I've just attached intel_reg_dumper outputs. Let me know if you need something else. Cesare.
Please add drm.debug=0xe to your kernel command line, reproduce the problem again and attach the output of dmesg here.
As you requested, i booted with drm.debug=0xe, then connected remotely with ssh to save dmesg output. In the attached ZIP there are 3 dmesg: dmesg.1.txt It's exactly what you requested: the last seconds are soon after i've triggered a CTRL-ALT-F1 to switch to VT1. dmesg.2.txt This log is interesting because soon after saving dmesg.1.txt, the PC stopped responding to ssh for several seconds. After then i thought it was freezed so i tried to press the CAPS LOCK key to see if the corresponding led would switch on. With my surprise the LCD display resurrected and the ssh session became responsive again. This log seems to show a return from suspend, even if i've never triggered it. dmesg.3.txt This is similar to dmesg.1.txt: after the return to life of the display, i triggereded two switch: one from VT1 to lightdm login manager (ok, it worked), then a switch back to VT1. The screen went black again, and this log was taken soon after. But now i wasn't able to bring back the LCD to life as before and there weren't any connection trouble. I've waited about ten minute. Cesare.
Created attachment 116028 [details] Three dmesg from the same session
(In reply to Cesare Leonardi from comment #6) > dmesg.2.txt > This log is interesting because soon after saving dmesg.1.txt, the PC > stopped responding to ssh for several seconds. After then i thought it was > freezed so i tried to press the CAPS LOCK key to see if the corresponding > led would switch on. > With my surprise the LCD display resurrected and the ssh session became > responsive again. > This log seems to show a return from suspend, even if i've never triggered > it. Note that it's the first time that i've seen such behaviour, both the apparent freeze and the display that restore itself. And i cannot avoid to note that to reproduce this bug i usually press CTRL-ALT-F1 and that the key to hibernate the PC is Fn-F1. I'm asking myself if i could have pressed Fn together with CTRL or something else that could have triggered the suspend... Even if i think no and the PC apparently stayed powered on. All that to warn about the fact that what happened in the quoted text could be a misleading detail. Cesare.
Could you grab intel-gpu-tools from [1] and run tools/intel_watermark once while the display is working and another time when you have the black screen and attach the output of both runs here? http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Sorry but this is a bit out of my possibilities and knowledge. Aren't that info collectable in other ways?
(In reply to Cesare Leonardi from comment #10) > Sorry but this is a bit out of my possibilities and knowledge. > Aren't that info collectable in other ways? The intel_watermark tool is recent addition to intel-gpu-tools, so it is probably not yet packaged by your distro, but you could give that a try. I'm not aware of any easier way to get this information. The steps for compiling intel-gpu-tools are roughly the listed below. git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools cd intel-gpu-tools ./autogen.sh make (then you can run as root) ./tools/intel_watermarks
It's a bit of a long shot, but do you still see the problem if you add i915.enable_ips=0 to your kernel command line?
Premise: since when i've filed the bug, mesa was updated to 10.5.7, while kernel, X server, X driver and DRM are at the same version. Few days ago intel-gpu-tools 1.11 with "intel_watermark" entered Debian unstable. As Ander requested, i've run that command before and during the black screen but the output is identical (see attachments). Instead adding i915.enable_ips=0 to kernel command line works and resolve the problem for me. Cesare.
Created attachment 116563 [details] intel_watermark when display is ok
Created attachment 116564 [details] intel_watermark after triggering the black screen
(In reply to Cesare Leonardi from comment #13) > Instead adding i915.enable_ips=0 to kernel command line works and resolve > the problem for me. Looks very similar to bug 85583. Could you give the following patch a try? http://patchwork.freedesktop.org/patch/50675/
(In reply to Ander Conselvan de Oliveira from comment #16) > Looks very similar to bug 85583. Could you give the following patch a try? > > http://patchwork.freedesktop.org/patch/50675/ From that link i understand that the patch was included in drm-intel-next-fixes but i don't know if it means that was included in some released version. Today i could say that libdrm2 and libdrm-intel1 entered in Debian but the problem is still there. To test i've temporarly removed the "i915.enable_ips=0" workaround i've learnt here.
IPS is a broadwell feature, it really should not impacting haswell at all. Odd.
Today i've upgraded kernel to 4.1.5 and libdrm to 2.4.63 and now the problem looks resolved: VT switching works again without the "i915.enable_ips=0" trick. For the record my current configuration is: kernel: 4.1.5 xserver: 1.17.2 mesa: 10.6.3 libdrm: 2.4.63 Until today many kernel, mesa and libdrm upgrade made no difference in respect to this bug. I'm almost sure that my last setup was still not working: kernel: 4.1.3 xserver: 1.17.2 mesa: 10.6.3 libdrm: 2.4.62 Cesare.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.