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

[Ben Guthro]

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

The following brings the screen back, but in a low resolution corner of X:
vbetool vbestate restore < vbe.save

And then we can get the full resolution back with the following:
xrandr --output eDP1 --off
xrandr --output eDP1 --auto


This is clearly not an ideal solution to make a product out of.

Does this point to a BIOS issue?


Is anyone out there?





>
>
>
>>>
>>> Is this an eDP training issue? Are there any changesets I can try backporting?
>>> I tried this, but it didn't seem to help:
>>> https://patchwork.kernel.org/patch/2516601/
>>
>>
>> Below is a serial dump with drm.debug=4, after resuming from S3
>>
>> If anyone sees anything awry, being pointed in the right direction
>> would be appreciated: