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:
