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

[Ben Guthro]

On Tue, May 21, 2013 at 9:44 AM, Ben Guthro <ben at guthro.net> wrote:
> On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> 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?
>
> No, these work as expected (on 3.8)
> I didn't realize that these broke with KMS. I'll stick with the S3 reproduction.
>
>>
>> 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.

vbetool was not installed on the system when I took those S3 dumps, so
it seems unlikely to be the root of the problem, IMO.


> 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.
>
> Ben
>
>>
>> Cheers, Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch