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

[Daniel Vetter]

On Fri, May 17, 2013 at 09:26:18AM -0400, Ben Guthro wrote:
> On Fri, May 17, 2013 at 7:52 AM, Ben Guthro <ben at guthro.net> wrote:
> > On Thu, May 16, 2013 at 9:24 AM, Ben Guthro <ben at guthro.net> wrote:
> >> On Wed, May 15, 2013 at 4:42 PM, Ben Guthro <ben at guthro.net> wrote:
> >>> On Tue, May 14, 2013 at 5:01 PM, Ben Guthro <ben at guthro.net> wrote:
> >>>> I am attempting to debug an issue with some Haswell laptop systems
> >>>> which do not restore their screen after resuming from S3 when running
> >>>> on the stable 3.8 kernel (3.8.13)
> >>>> The backlight is OK, but the screen is just black.
> >>>>
> >>>> In trying to determine what was going wrong, I tried looking at the
> >>>> output of intel_reg_dumper, in a good, and bad case:
> >>>>
> >>>> diff -u good_reg.txt bad_reg.txt
> >>>> --- good_reg.txt        2013-05-14 15:08:44.361997000 +0000
> >>>> +++ bad_reg.txt 2013-05-14 15:09:20.480000000 +0000
> >>>> @@ -1,5 +1,4 @@
> >>>> -                 DCC: 0x00000000 (0x00000000f3400000
> >>>> 0x00000000f37fffff 0x00000000��
> >>>> -� )
> >>>> +                 DCC: 0x00000000 (0x00000000f3400000
> >>>> 0x00000000f37fffff 0x00000000��= � )
> >>>>             CHDECMISC: 0x00000000 (none, ch2 enh disabled, ch1 enh
> >>>> disabled, ch0 enh disabled, flex disabled, ep not present)
> >>>>                C0DRB0: 0x00000000 (0x0000)
> >>>>                C0DRB1: 0x00000000 (0x0000)
> >>>> @@ -63,17 +62,17 @@
> >>>>       PIPEA_DP_LINK_N: 0x00000000
> >>>>         CURSOR_A_BASE: 0x01061000
> >>>>      CURSOR_A_CONTROL: 0x04000027
> >>>> -   CURSOR_A_POSITION: 0x03a3032f
> >>>> +   CURSOR_A_POSITION: 0x01bb03fb
> >>>>                  FPA0: 0x00000000 (n = 0, m1 = 0, m2 = 0)
> >>>>                  FPA1: 0x00000000 (n = 0, m1 = 0, m2 = 0)
> >>>>                DPLL_A: 0x00000000 (disabled, non-dvo, VGA, default
> >>>> clock, unknown mode, p1 = 0, p2 = 0)
> >>>>             DPLL_A_MD: 0x00000000
> >>>> -            HTOTAL_A: 0x0821077f (1920 active, 2082 total)
> >>>> -            HBLANK_A: 0x0821077f (1920 start, 2082 end)
> >>>> -             HSYNC_A: 0x081307af (1968 start, 2068 end)
> >>>> -            VTOTAL_A: 0x045f0437 (1080 active, 1120 total)
> >>>> -            VBLANK_A: 0x045f0437 (1080 start, 1120 end)
> >>>> -             VSYNC_A: 0x044b0441 (1090 start, 1100 end)
> >>>> +            HTOTAL_A: 0x00000000 (1 active, 1 total)
> >>>> +            HBLANK_A: 0x00000000 (1 start, 1 end)
> >>>> +             HSYNC_A: 0x00000000 (1 start, 1 end)
> >>>> +            VTOTAL_A: 0x00000000 (1 active, 1 total)
> >>>> +            VBLANK_A: 0x00000000 (1 start, 1 end)
> >>>> +             VSYNC_A: 0x00000000 (1 start, 1 end)
> >>>>             BCLRPAT_A: 0x00000000
> >>>>          VSYNCSHIFT_A: 0x00000000
> >>>>              DSPBCNTR: 0x00004000 (disabled, pipe A)
> >>>>
> >>>>
> >>>> It appears the registers that are saved, and restored in
> >>>> i915_save_modeset_reg / i915_restore_modeset_reg is not working
> >>>> properly.
> >>>>
> >>>> When I put some debug in, I discovered that it was bailing out of
> >>>> i915_save_modeset_reg early since the DRIVER_MODESET bit was cleared.
> >>>> However, it was set at the end of i915_init()
> >>>> This, of course, confuses me.
> >>>>
> >>>> Am I seeing memory corruption here?
> >>>
> >>> It looks like I misread the code here, inversing an if statement state.
> >>>
> >>> That said, I don't really have any clues as to why the display is
> >>> black after resuming from S3
> >
> > It appears that S3 is not necessary.
> >
> > I can reproduce the black screen with just vbetool:
> > vbetool dpms off
> > vbetool dpms on
> >
> > Does this suggest a bios issue?
> 
> This can be reliably reproduced on this machine, and worked around by
> saving the vbestate, and restoring it after the fact:
> 
> (in a working state)
> vbetool vbestate save > vbe.save
> 
> break the system:
> vbetool dpms off
> vbetool dpms on

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?

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?

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