Created attachment 92495 [details] dmesg output I've recently started experiencing a display bug with my x230 while using the docking station In short, monitor starts flashing off and on; if I open the laptop's lid, I find that display is also flashing. Undock, flashing on the laptop's display is gone. Unplug the DisplayPort cable, dock laptop, and plug in cable back, and things go back to normal. This is Debian sid, xserver-xorg-video-intel 2.21.15, kernel 3.12 The kernel reports, with every flash (I think): [45627.712157] WARNING: CPU: 1 PID: 1719 at /build/linux-xS3nxO/linux-3.12.6/drivers/gpu/drm/i915/intel_display.c:8853 check_crtc_state+0x63f/0xb30 [i915]() [45627.712158] pipe state doesn't match! [45627.787006] WARNING: CPU: 0 PID: 1719 at /build/linux-xS3nxO/linux-3.12.6/drivers/gpu/drm/i915/intel_dp.c:2538 ironlake_crtc_disable+0x17a/0x930 [i915]() I'm not even sure if this is a problem with DRI or the intel driver, please advise what additional info you might need. XRandR ------ Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192 LVDS1 connected (normal left inverted right x axis y axis) 1366x768 60.0 + 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1600x1200 60.0 1680x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 640x480 60.0 720x400 70.1 DP3 disconnected (normal left inverted right x axis y axis)
I thought we had the "DPMS updates whilst off" bug fixed? Maybe try a 3.13 or drm-intel-nightly? Certainly avoided in a more recent ddx.
Hi Chris, I'll try 3.13 ASAP, and wait for the bug to trigger again. I haven't identified what causes it yet, or how to force its appearance.
Also try a newer DDX, please.
Jordi, ping
For the record, I am thinking of bug 68030, which should have been fixed by kernel commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 29 19:15:07 2013 +0100 drm/i915: Only apply DPMS to the encoder if enabled The current test for an attached enabled encoder fails if we have multiple connectors aliased to the same encoder - both connectors believe they own the enabled encoder and so we attempt to both enable and disable DPMS on the encoder, leading to hilarity and an OOPs: which should have been in v3.12.
Hi all, I'm sorry I haven't been able to provide data -- I have been unable to do the requested updates until now, and the issue has stopped happening so often. It did happen just yesterday, though, while running 3.12.8. I have just upgraded to 3.13, and not sure what else you'd want me to test. If I see this again while on 3.13, should I update the intel driver to 2.99.x?
Hmm, could be a different issue if it is showing up in 3.12 as well. And definitely if it persists after updating xf86-video-intel and switching to SNA.
Jordi, how is 3.13 going?
I've been running 3.13(.0) for a month (according to uptime) and I've seen the issue quit a few times. Unfortunately I don't seem able to find the time to upgrade my x server as well. :(
Hi! I've been running 3.14 during April, and I saw the issue every now and then, mostly when redocking after an undock. Tonight I came back from a trip, and no matter what "recovery" combinations I've tried, the flashing is now persistent and won't go away, and I'm unable to use the monitor at all. :( I guess I need to byte the bullet and try to update to a new DDX, as I think the one in Debian unstable is a bit outdated. To what exactly do you need me to upgrade?
Created attachment 98143 [details] 3.14 dmesg call traces
Ok, I think I'm where you want me to be. jordi@penyagolosa:~$ grep -i sna /var/log/Xorg.0.log [ 10.460] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.99.991-0.0.1 (Jordi Mallach <jordi@debian.org>) [ 10.461] (**) intel(0): Option "AccelMethod" "sna" [ 10.465] (II) intel(0): SNA initialized with Ivybridge (gen7, gt2) backend jordi@penyagolosa:~$ uname -a Linux penyagolosa 3.14-trunk-amd64 #1 SMP Debian 3.14.1-1~exp1 (2014-04-17) x86_64 GNU/Linux Things are much better. I *think* they are not perfect, but I'll confirm in the following days, as I'd swear I've gotten some flashing just after this reboot, but after pulling the DP cable out and sticking it in again, things have calmed down, even after two undock/redock cycles. Promising! At least I believe I can get some work done tomorrow. :) I'll keep you posted.
(In reply to comment #11) > Created attachment 98143 [details] > 3.14 dmesg call traces A full dmesg with drm.debug=0xe is usually more helpful.
Created attachment 98166 [details] dmesg with 3.14.1 and intel 2.99.911
Created attachment 98167 [details] X.Org.0.log after flashing
(In reply to comment #13) > (In reply to comment #11) > > Created attachment 98143 [details] > > 3.14 dmesg call traces > > A full dmesg with drm.debug=0xe is usually more helpful. Ah, I see. Just rebooted into that.
So what happens here is that the monitor requests a DP link retraining (which is per-spec), we randomly fail to retrain the link correctly and that repeats ad nauseam. Also we fire off a uevent which causes the DE to query the outputs which fails to detect the DP causing it to switch off the external. On the next uevent, it finds the DP again, causing the DE to re-enable the extended desktop. Also repeat ad nauseam.
Yay, more flashing after coming back from extended away. Even if unsurprisingly Chris seems to be now looking at smoking guns, here's a nice debug kernel log.
Created attachment 98200 [details] dmesg with drm.debug=0xe
Created attachment 98223 [details] [review] Add in a few more failure messages. Can you try with this patch (and drm.debug=0xe) to see when the error first occurs?
(In reply to comment #20) > Created attachment 98223 [details] [review] [review] > Add in a few more failure messages. > > Can you try with this patch (and drm.debug=0xe) to see when the error first > occurs? Hm, I've been trying to build the kernel and failing to do so due to a variety of non-related problems. Please be patient, I hope to have a new kernel by tomorrow.
Created attachment 98363 [details] 3.14.2 + Chris Wilson's extra debug Hm, unless I misunderstand the Debian linux build process, I'd swear the patch was applied: dpkg-source: info: applying bugfix/all/drm_intel_extra_error_messages.patch ----------------------------------------------------------------- ----- building linux_3.14.2-1~jordi1.dsc (user abuild) ----------------------------------------------------------------- However, this attached dmesg makes me suspicious as I don't seem to find any of the new messages.
Created attachment 98464 [details] [review] Add a window for no hpd events after a modeset Can you try this untested patch?
As I said earlier, recovery from the symptoms is a lot easier now than it was just before I upgraded (which was really hard, even cold reboots wouldn't guarantee it), so I've had a chance to find an easy way to trigger this. I've just rebooted into the patched kernel. What I do to trigger is: from X, open lid, the display goes to mirror mode, then go to tty1 (a getty) and close lid. Due to GNOME, logind or whatever, the system thinks it needs to shut down even if there's an external display. After opening the lid again, this bug triggers. What happened now is that the first time it appeared to behave, the system came back with a pair of flashes on the LVDS and then stabilised, and when switching to the X tty, it worked as it should. When I tried again, it did stay in flashing mode until I pulled the DP cable and put it back in.
Created attachment 98541 [details] dmesg after hdp trigger patch
I guess we should compare the OUI and filter out any DP hdp events that didn't actually result in a change ... We need this anyway for DP MST, Dave is working on hacks already.
I have no time to look at this. Assigning to Jani for re-assignment.
(In reply to comment #27) > I have no time to look at this. Assigning to Jani for re-assignment. Done; note that I now do such re-assignments round robin, so Rodrigo got this instead of the next new bug.
Jordi, I think a test of the current drm-intel-nightly branch of [1] (or Linus' v3.17-rc3 or later) would be worth a try. [1] http://cgit.freedesktop.org/drm-intel
Thanks. I can't go and test such an early rc kernel easily as this is my work machine, but if you could give a list of useful commits I might go ahead and try to put them on top of 3.16 if that isn't too messy. I see a series of patches yesterday from Ville that is probably what I should be looking at, but being a total stranger to all of this stuff, pointers appreciated. :)
Also worth mentioning: since I said it was a lot more difficult to reproduce once I upgraded the xorg driver, it's stayed like that: it kicks in every now and then, notably when eg there's a blackout and the laptop loses connection to the (dead) monitor abruptly.
Too many changes to backport, really.
Well, it's been awhile, and we definitely do have changes in this area upstream now, so please re-open if you see this again with the current bits (i.e. drm-intel-nightly branch from freedesktop.org).
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.