Running on a DELL E6500 Laptop. Using intel graphics stack as distributed with ubuntu saucy (13.10) 64 bit (in fact kubuntu). This means 3.11.0 kernel + ubuntu patches (but tested also with vanilla 3.12.6 with the same issue) xorg-server-video-intel 2.99.904 mesa 9.2.1 libdrm 2.4.46 Issue is the following. 1) Laptop on. 2) Connect an external monitor via displayport -> the external monitor is detected. 3) Suspend laptop 4) Detach external monitor 5) Resume laptop after some time and immediately attach external monitor via display port or attach external monitor via displayport -> the external monitor is NOT DETECTED, xrandr only shows the laptop panel This is a regression with respect to older ubuntu raring graphics stack, where the external monitor on displayport was always detected. Note that after point 5) the system logs report [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling which may be relevant. Also note that after point 5) 6) Wait a couple of minutes 7) Detach external monitor 8) Wait a couple of minutes 9) Attach the external monitor makes the external monitor detected.
Hi Can you please boot with Kernel parameter drm.debug=0xe, reproduce the problem, then run "dmesg" and attach its output here? Also, it would be good to know if this problem happens on 3.13 Kernels. Thanks, Paulo
Since this is a regressino: - Which kernel versions is the last known to work? - Could you please attempt to bisect where this regression has been introduced?
Sorry for the delay in answering the last questions. Unfortunately, it is not completely easy for me because of two reasons: a) I'm not everyday in the location where I can try the laptop with the attached monitor; and, most important b) The bug only happens if in the list 1) Laptop on. 2) Connect an external monitor via displayport -> the external monitor is detected. 3) Suspend laptop 4) Detach external monitor 5) Resume laptop after some time and immediately attach external monitor via display port or attach external monitor via displayport -> the external monitor is NOT DETECTED, xrandr only shows the laptop panel a lot of time passes between 4 and 5. For some weird reason if I try the steps in a quick sequence, the external monitor is detected. This makes me suspicious about the way in which the system verifies the presence of an interrupt storm. In fact suspend -> resume [ no interrupt storm detected ] suspend -> ... a lot of time ... -> resume [ interrupt storm detected ] Another note: when the problem occurs, it is enough to wait exactly 2 minutes to make it go away. Unfortunately, this is too much when you need to give a presentation and the audience is waiting. Last working kernel I tested is 3.8.x. Unfortunately, I cannot test 3.9 and 3.10 on this machine which is a workplace laptop.
How much time is "immediately" in your step 5? Is this while the system is still resuming, or are a few seconds later on also still able to repro the bug? For theories I have two ideas - Disabling the irq also kills the DP hotplug detection logic. - The interrupt storm logic isn't properly reset over a resume. The combination of these might be enough to explain what's going on here ... One more thing: Can you test patches and git trees on this machine?
I need to check again with a long delay. Currently I have tried the following 1) Attaching the external monitor before resuming 2) Resuming and attaching the external monitor within a few secs 3) Resuming and attaching the external monitor after 1-2 minutes in all these cases, the external monitor is not detected. As soon as I can, I will test again leaving more than 2 minutes before attaching the external monitor.
Could you please provide a dmesg with kernel booted with drm.debug=0xe parameter? Also, can you grab the reg dump (intel_reg_dump from intel-gpu-tools) before the suspend-resume and after it? It would be great if you could try our development tree: http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
Sorry. Got so exasperated by the corrupted glyphs (a different GEN4 bug) that I have moved to another machine, so I will not be able to test rapidly. However, I still have the DELL E6500 around, so I will try to test.
(In reply to comment #7) > Sorry. Got so exasperated by the corrupted glyphs (a different GEN4 bug) > that I have moved to another machine, so I will not be able to test rapidly. > > However, I still have the DELL E6500 around, so I will try to test. Timeout, closing. Please reopen the bug if you can still reproduce the bug with the recent kernels. Thanks for the report.
It is OK to close. Cannot test on the DELL anymore. Sorry for the noise and delay.
Closing resolved+worksforme. Reporter commented two years ago that one can close this.
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.