i915: black screen after blank when LID is closed on Linux >= 3.1

Hi, since Linux 3.1 I'm having some problems with i915 driver on HP nc6120 with 915GM chipset. The display goes black after the kernel tries to blank screen while LID is closed (see steps to reproduce to more detailed description). Currently I'm using Linux 3.7-rc6 with KMS enabled and disabled A

i915: black screen after blank when LID is closed on Linux >= 3.1

27; > loose track of it? Yes, I will add a bug report there. > > A few questions and things to test below. > > On Thu, Nov 22, 2012 at 7:54 PM, Krzysztof Mazur > wrote: > > since Linux 3.1 I'm having some problems with i915 driver on HP nc6120 > > with 915GM

i915: black screen after blank when LID is closed on Linux >= 3.1

On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote: > Hi, > > > Since a dpms ioctl call tends to follow a modeset, this likely only > results in that dpms call enabling the hw again. Can you please add > drm.debug=0xe to your kernel cmdline and boot into a 3.6 with this > hack applied,

i915: black screen after blank when LID is closed on Linux >= 3.1

Hi, since Linux 3.1 I'm having some problems with i915 driver on HP nc6120 with 915GM chipset. The display goes black after the kernel tries to blank screen while LID is closed (see steps to reproduce to more detailed description). Currently I'm using Linux 3.7-rc6 with KMS enabled and disabled A

Re: i915: black screen after blank when LID is closed on Linux >= 3.1

27; > loose track of it? Yes, I will add a bug report there. > > A few questions and things to test below. > > On Thu, Nov 22, 2012 at 7:54 PM, Krzysztof Mazur > wrote: > > since Linux 3.1 I'm having some problems with i915 driver on HP nc6120 > > with 915GM

Re: i915: black screen after blank when LID is closed on Linux >= 3.1

On Thu, Nov 22, 2012 at 09:17:54PM +0100, Daniel Vetter wrote: > Hi, > > > Since a dpms ioctl call tends to follow a modeset, this likely only > results in that dpms call enabling the hw again. Can you please add > drm.debug=0xe to your kernel cmdline and boot into a 3.6 with this > hack applied,

drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

Hi, the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), which in case of i915 DRM driver effectively calls intel_get_load_detect_pipe() that tries to lock crtc->mutex again. This causes a deadlock, a

Re: drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote: > On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: > > Hi, > > > > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling > > drm_mode

drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote: > On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: > > Hi, > > > > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling > > drm_mode

drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

Hi, the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), which in case of i915 DRM driver effectively calls intel_get_load_detect_pipe() that tries to lock crtc->mutex again. This causes a deadlock, a