[Intel-gfx] debugging Haswell eDP black screen after S3

Ben Guthro ben at guthro.net
Tue May 21 19:28:27 CEST 2013

On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, May 21, 2013 at 3:44 PM, Ben Guthro <ben at guthro.net> wrote:
>>> This will break kms since now you have the vbios and the linux kms driver
>>> fighting over the same piece of hw. Does
>>> xset dpms force off
>>> xset dpms force on
>>> cause similar issues?
>> No, these work as expected (on 3.8)
>> I didn't realize that these broke with KMS. I'll stick with the S3 reproduction.
> Ok, so things are at least not terribly broken.
>>> If not please make sure that vbetool isn't badly interfering with the
>>> kernel modeset driver on suspend/resume. At least looking at your dmesg
>>> and reg dumps vbe wreaking havoc with the kms driver seems like a rather
>>> likely scenario. Also, can you please test latest 3.10-rc kernels?
>> 3.10-rc2 doesn't seem to work at all - it boots to a black screen every time.
> That otoh is ugly. Could be that though that this is the same (or a
> similar bug) to your resume issue - in the last few kernel releases
> we've tried very hard to unify the code between initial driver load at
> boot-up and resume.

Perhaps I should qualify "at all"

It seems that it fails somewhat late in the boot process. If I remove
the "boot splash" cli params, I can see it transition into the high
res mode, and seemingly get into init.
However, even if I boot to single user mode, the screen goes black.

Unfortunately, both times I tried to test this, and then reboot, I
ended up at a "grub rescue" prompt, with an unusable system.

> So can you please try to bisect where the boot-up regression has been
> introduced between 3.8 and 3.10-rc2?

I'm not sure I'll be able to do this.
With the failure condition I describe above, I am unable to even ssh
into this machine to debug, nevermind install a new kernel.
This means I need to generate a new kernel, and install kit with that
kernel for every bisection test.

This may be more time than I am able to dedicate to this problem - but I'll try.


> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

More information about the Intel-gfx mailing list