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
