Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Tue, May 21, 2013 at 1:28 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 21, 2013 at 3:44 PM, Ben Guthro b...@guthro.net wrote: 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. Ok, so things are at least not terribly broken. 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? 3.10-rc2 doesn't seem to work at all - it boots to a black screen every time. That otoh is ugly. Could be that though that this is the same (or a similar bug) to your resume issue - in the last few kernel releases we've tried very hard to unify the code between initial driver load at boot-up and resume. Perhaps I should qualify at all It seems that it fails somewhat late in the boot process. If I remove the boot splash cli params, I can see it transition into the high res mode, and seemingly get into init. However, even if I boot to single user mode, the screen goes black. Unfortunately, both times I tried to test this, and then reboot, I ended up at a grub rescue prompt, with an unusable system. So can you please try to bisect where the boot-up regression has been introduced between 3.8 and 3.10-rc2? I'm not sure I'll be able to do this. With the failure condition I describe above, I am unable to even ssh into this machine to debug, nevermind install a new kernel. This means I need to generate a new kernel, and install kit with that kernel for every bisection test. This may be more time than I am able to dedicate to this problem - but I'll try. Ben It appears I did not CC the list on my last 2 replies. My apologies - I'll re-paste them below. I tried to bisect this, but was unsuccessful, in that I didn't seem to have a reproducible test case to get back into this failure condition. It seemed that it always would succeed for me...which of course makes bisecting near impossible. I tried updating to 3.10-RC3...well, actually to this changeset at the tip of Linus' tree: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58f8bbd2e39c3732c55698494338ee19a92c53a0 I can get X to come up now on this machine - albeit very slowly. Once it comes up, it seems to hang, and respawn I get a lot of these in the log now, as well: [ 392.195734] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Things in the log that look suspicious to me are: [ 34.293452] [drm:intel_pipe_set_base] *ERROR* pin fence failed [ 34.293486] [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 I get the following errors in the X log, that prevent it from coming up: [76.142] (EE) intel(0): failed to set mode: No space left on device [76.142] Fatal server error: [76.142] AddScreen/ScreenInit failed for driver 0 [76.142] [76.142] (EE) Xorg also crashes in the following manner: [ 218.876] (EE) Backtrace: [ 218.880] (EE) 0: X (xorg_backtrace+0x34) [0x7fe44fff9754] [ 218.880] (EE) 1: X (0x7fe44fe44000+0x1b96a9) [0x7fe44fffd6a9] [ 218.880] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fe44f16a000+0xfcb0) [0x7fe44f179cb0] [ 218.880] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7fe44ddcf000+0x148c6b) [0x7fe44df17c6b] [ 218.880] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe44cb5a000+0x17c36) [0x7fe44cb71c36] [ 218.880] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe44cb5a000+0x19857) [0x7fe44cb73857] [ 218.880] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe44cb5a000+0xed429) [0x7fe44cc47429] [ 218.880] (EE) 7: X (0x7fe44fe44000+0x13e8ac) [0x7fe44ff828ac] [ 218.880] (EE) 8: X (0x7fe44fe44000+0x5239e) [0x7fe44fe9639e] [ 218.880] (EE) 9: X (0x7fe44fe44000+0x557a1) [0x7fe44fe997a1] [ 218.880] (EE) 10: X (0x7fe44fe44000+0x4415a) [0x7fe44fe8815a] [ 218.880] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xed) [0x7fe44ddf076d] [ 218.880] (EE) 12: X (0x7fe44fe44000+0x444b1) [0x7fe44fe884b1] [ 218.880] (EE) [ 218.880] (EE) Bus error at address 0x7fe44a6c9080 [ 218.880] Fatal server error: [ 218.881] Caught signal 7 (Bus error). Server aborting [ 218.881] [ 218.881] (EE) I recognize that this isn't terribly helpful without the symbol resolution. I tried installing debug symbols, but they didn't seem to help. Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter dan...@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 b...@guthro.net wrote: On Thu, May 16, 2013 at 9:24 AM, Ben Guthro b...@guthro.net wrote: On Wed, May 15, 2013 at 4:42 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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. 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Tue, May 21, 2013 at 9:44 AM, Ben Guthro b...@guthro.net wrote: On Tue, May 21, 2013 at 4:00 AM, Daniel Vetter dan...@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 b...@guthro.net wrote: On Thu, May 16, 2013 at 9:24 AM, Ben Guthro b...@guthro.net wrote: On Wed, May 15, 2013 at 4:42 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 21, 2013 at 3:44 PM, Ben Guthro b...@guthro.net wrote: 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. Ok, so things are at least not terribly broken. 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? 3.10-rc2 doesn't seem to work at all - it boots to a black screen every time. That otoh is ugly. Could be that though that this is the same (or a similar bug) to your resume issue - in the last few kernel releases we've tried very hard to unify the code between initial driver load at boot-up and resume. Perhaps I should qualify at all It seems that it fails somewhat late in the boot process. If I remove the boot splash cli params, I can see it transition into the high res mode, and seemingly get into init. However, even if I boot to single user mode, the screen goes black. Unfortunately, both times I tried to test this, and then reboot, I ended up at a grub rescue prompt, with an unusable system. So can you please try to bisect where the boot-up regression has been introduced between 3.8 and 3.10-rc2? I'm not sure I'll be able to do this. With the failure condition I describe above, I am unable to even ssh into this machine to debug, nevermind install a new kernel. This means I need to generate a new kernel, and install kit with that kernel for every bisection test. This may be more time than I am able to dedicate to this problem - but I'll try. Ben Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Thu, May 16, 2013 at 9:24 AM, Ben Guthro b...@guthro.net wrote: On Wed, May 15, 2013 at 4:42 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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? 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: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Fri, May 17, 2013 at 7:52 AM, Ben Guthro b...@guthro.net wrote: On Thu, May 16, 2013 at 9:24 AM, Ben Guthro b...@guthro.net wrote: On Wed, May 15, 2013 at 4:42 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Wed, May 15, 2013 at 4:42 PM, Ben Guthro b...@guthro.net wrote: On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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 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: [ 119.676134] ACPI: Low-level resume complete [ 119.676200] PM: Restoring platform NVS memory [ 119.676585] xen-acpi-processor: Uploading Xen processor PM info [ 119.678302] Enabling non-boot CPUs ... [ 119.678351] installing Xen timer for CPU 1 [ 119.678380] cpu 1 spinlock event irq 48 [ 119.679469] CPU1 is up [ 119.679496] installing Xen timer for CPU 2 [ 119.679505] cpu 2 spinlock event irq 55 [ 119.680524] CPU2 is up [ 119.680586] installing Xen timer for CPU 3 [ 119.680590] cpu 3 spinlock event irq 62 [ 119.681463] CPU3 is up [ 119.681482] installing Xen timer for CPU 4 [ 119.681487] cpu 4 spinlock event irq 69 [ 119.682448] CPU4 is up [ 119.682478] installing Xen timer for CPU 5 [ 119.682482] cpu 5 spinlock event irq 76 [ 119.683463] CPU5 is up [ 119.683490] installing Xen timer for CPU 6 [ 119.683494] cpu 6 spinlock event irq 83 [ 119.684483] CPU6 is up [ 119.684512] installing Xen timer for CPU 7 [ 119.684517] cpu 7 spinlock event irq 90 [ 119.685523] CPU7 is up [ 119.685941] ACPI: Waking up from system sleep state S3 [ 120.546804] pci :01:00.0: power state changed by ACPI to D0 [ 120.586931] PM: noirq resume of devices complete after 160.133 msecs [ 120.587261] PM: early resume of devices complete after 0.247 msecs [ 120.587438] xen: registering gsi 16 triggering 0 polarity 1 [ 120.587447] i915 :00:02.0: setting latency timer to 64 [ 120.587449] Already setup the GSI :16 [ 120.587569] xen: registering gsi 22 triggering 0 polarity 1 [ 120.587578] Already setup the GSI :22 [ 120.587749] pciehp :00:1c.2:pcie04: pciehp_resume ENTRY [ 120.587769] pciehp :00:1c.0:pcie04: pciehp_resume ENTRY [ 120.587837] pciehp :00:1c.3:pcie04: pciehp_resume ENTRY [ 120.587868] pciehp :00:1c.4:pcie04: pciehp_resume ENTRY
Re: [Intel-gfx] debugging Haswell eDP black screen after S3
On Tue, May 14, 2013 at 5:01 PM, Ben Guthro b...@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.txt2013-05-14 15:08:44.361997000 + +++ bad_reg.txt 2013-05-14 15:09:20.48000 + @@ -1,5 +1,4 @@ - DCC: 0x (0xf340 0xf37f 0x�� -� ) + DCC: 0x (0xf340 0xf37f 0x��= � ) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) @@ -63,17 +62,17 @@ PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x01061000 CURSOR_A_CONTROL: 0x0427 - CURSOR_A_POSITION: 0x03a3032f + CURSOR_A_POSITION: 0x01bb03fb FPA0: 0x (n = 0, m1 = 0, m2 = 0) FPA1: 0x (n = 0, m1 = 0, m2 = 0) DPLL_A: 0x (disabled, non-dvo, VGA, default clock, unknown mode, p1 = 0, p2 = 0) DPLL_A_MD: 0x -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: 0x (1 active, 1 total) +HBLANK_A: 0x (1 start, 1 end) + HSYNC_A: 0x (1 start, 1 end) +VTOTAL_A: 0x (1 active, 1 total) +VBLANK_A: 0x (1 start, 1 end) + VSYNC_A: 0x (1 start, 1 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x4000 (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 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/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] eDP screen corruption using linux 3.8 xen 4.2
Adding intel-gfx to this thread in the hopes that someone there might have some ideas since the fengzhe.zh...@intel.com address was bouncing. Thread origins, for that list's reference: http://markmail.org/thread/m4jhronecq4fvyk6 On Tue, Mar 5, 2013 at 11:42 AM, Jan Beulich jbeul...@suse.com wrote: On 05.03.13 at 17:33, Ben Guthro b...@guthro.net wrote: I turned up the debug, but didn't see this I am seeing other oops messages in the log now though...not sure if these are related. The first one likely is related (rax being 00aa00aa and apparently used as memory address, and that value very much looks like 2 pixels from a 32-bit pixel map). So I'd guess that there's once again some physical/machine address mixup. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm
I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) - that has an i3 processor (M330) - and intel graphics. This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can also be reproduced using kernels as old as 3.2.23 - and hypervisors as old as 4.0.4 (I have cross posted here, because I am not yet sure if this is a Xen, pvops, or i915 issue - and would appreciate opinions in sorting it out.) The symptoms of the problem exhibit themselves by a lagging mouse in X11 after resume, when using the trackpad. After digging in a bit, the problem seems a bit more insidious - the i915 kworker responsible for hotplug detection (i915_hotplug_work_func) seems to be getting triggered for every PS2 IRQ - every trackpad mouse movement, and keypress triggers tracing (with drm.debug=0x06) like the following: Nov 6 21:41:58 rusting kernel: [ 263.924454] [drm:i915_hotplug_work_func], running encoder hotplug functions Nov 6 21:41:58 rusting kernel: [ 263.924468] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40018, result 0 Nov 6 21:41:58 rusting kernel: [ 263.924472] [drm:intel_crt_detect], CRT not detected via hotplug Nov 6 21:41:58 rusting kernel: [ 263.924475] [drm:output_poll_execute], [CONNECTOR:11:VGA-1] status updated from 2 to 2 Nov 6 21:41:58 rusting kernel: [ 263.926771] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpc Nov 6 21:41:58 rusting kernel: [ 263.926775] [drm:output_poll_execute], [CONNECTOR:14:HDMI-A-1] status updated from 2 to 2 Nov 6 21:41:58 rusting kernel: [ 263.927291] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e Nov 6 21:41:58 rusting kernel: [ 263.944207] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e Nov 6 21:41:58 rusting kernel: [ 263.964201] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003e Nov 6 21:41:58 rusting kernel: [ 263.983694] [drm:intel_dp_detect], DPCD: Nov 6 21:41:58 rusting kernel: [ 263.983704] [drm:output_poll_execute], [CONNECTOR:17:DP-1] status updated from 2 to 2 Additionally, this same trace stack is printed out at a regular 10s interval, after resume - where prior to resuming from S3 it is printed out once at boot time. This kworker consumes a significant portion of the cpu, and essentially grinds Xorg to a halt, until the probing can catch up with the user moving the cursor. There seems to be a mismatch for these IRQ delivery - or at least exhibits the behavior similar to such a problem. Does anyone have any thoughts as to where in the software stack I should start to dig in? Any opinions on which component likely contains the issue is appreciated. /btg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm
On Wed, Nov 7, 2012 at 11:22 AM, Ben Guthro b...@guthro.net wrote: I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) - that has an i3 processor (M330) - and intel graphics. This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can also be reproduced using kernels as old as 3.2.23 - and hypervisors as old as 4.0.4 (I have cross posted here, because I am not yet sure if this is a Xen, pvops, or i915 issue - and would appreciate opinions in sorting it out.) This appears to be unrelated to Xen / pvops, at the moment, after some additional debugging, and appears to be an issue with the i915 driver with older hardware. I'll remove xen-devel, and Konrad from future replies to this thread. Additionally, this same trace stack is printed out at a regular 10s interval, after resume - where prior to resuming from S3 it is printed out once at boot time. 10*HZ seems to be the normal hotplug interval, when an interrupt doesn't fire There seems to be a mismatch for these IRQ delivery - or at least exhibits the behavior similar to such a problem. I was mistaken here. The i8042 IRQ would just start up the IRQ handling - but the i915 driver always thinks it has pending work, and schedules it. It seems that the hotplug mask is not getting cleared in pch_iir (in i915_irq.c) Manually clearing this bit with pch_iir = pch_iir ^ hotplug_mask; in the ironlake_irq_handler() function seems to resolve the issue - making it so I don't get the flurry of hotplug work bogging down the system. ...but is this disabling hotplug detection entirely? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm
On Wed, Nov 7, 2012 at 2:43 PM, Ben Guthro b...@guthro.net wrote:
There seems to be a mismatch for these IRQ delivery - or at least exhibits
the behavior similar to such a problem.
I was mistaken here. The i8042 IRQ would just start up the IRQ handling - but
the i915 driver always thinks it has pending work, and schedules it.
It seems that the hotplug mask is not getting cleared in pch_iir (in
i915_irq.c)
Manually clearing this bit with
pch_iir = pch_iir ^ hotplug_mask;
in the ironlake_irq_handler() function
seems to resolve the issue - making it so I don't get the flurry of hotplug
work bogging down the system.
...but is this disabling hotplug detection entirely?
The attached patch seems to resolve the issue of the interrupt storm
after S3 for this Ibex Peak PCH system.
Could someone comment on whether this will have any unintended side effects?
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..d8f2f79 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -802,8 +802,13 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
/* check event from PCH */
if (de_iir DE_PCH_EVENT) {
- if (pch_iir hotplug_mask)
+ if (pch_iir hotplug_mask) {
queue_work(dev_priv-wq, dev_priv-hotplug_work);
+
+ if (!HAS_PCH_CPT(dev))
+ pch_iir = pch_iir ^ SDE_HOTPLUG_MASK;
+ }
+
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else
hotplug.patch
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] assertion on intel_disable_transcoder
FWIW, I am able to get graphics on the screen now - Apparently only the hdmi port works on HSW right now - which I was unaware of. This stack was a red-herring to that problem. Thanks for the response. Ben On Thu, Sep 27, 2012 at 2:34 AM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Sep 27, 2012 at 06:32:06AM +, Wang, Xingchao wrote: Hi Ben, I have no idea about the resolution, maybe Paulo and Daniel know more details? Oh, it's just an older assert for pre-hsw that we haven't properly disabled yet. Since this code will change quite a bit with Paulo's new way of handling ddi/fdi on haswell, we somehow never bothered with the real fix. Should be quite as soon as Paulo's patchbomb lands. -Daniel Thanks --xingchao From: ben.gut...@gmail.com [mailto:ben.gut...@gmail.com] On Behalf Of Ben Guthro Sent: Wednesday, September 26, 2012 4:43 AM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R; Fu, Michael; Wu, Fengguang Subject: Re: [Intel-gfx] assertion on intel_disable_transcoder I am seeing this same trace (and no video) on multiple Haswell SDP's, with 3.6-rc7 (and earlier kernels) Was there ever a resolution on this? On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao xingchao.w...@intel.com mailto:xingchao.w...@intel.com wrote: Hi, Some update related to this warning. Ironlake_crtc_dpms() will enable/disable crtc which pipe was enabled/disabled there. Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and crtc was disabled, that causes intel_wait_for_vblank() timeout and some assertions. I think it's a bug but I have no clue where/when to enable crtc again. Here's part of dmesg before the warning and the message showing dpms off. [ 19.332220] [drm:intel_lvds_init], LVDS is not present in VBT [ 19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4 [ 19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B [ 19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f [ 19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f [ 19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off [ 19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled [ 19.351826] [ cut here ] [ 19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 19.351849] Hardware name: Shark Bay Client platform [ 19.351850] FDI TX state assertion failure (expected off, current on) [ 19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek snd_hda_codec_hdmi drm_kms_helper drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_rawmidi snd_s eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830 psmouse snd_seq_device usbnet snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc lpc_ich microcode mac_hid video lp parport e1000e usbhid hid [ 19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29 [ 19.351870] Call Trace: [ 19.351876] [8105278f] warn_slowpath_common+0x7f/0xc0 thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Tuesday, August 07, 2012 3:26 PM To: Daniel Vetter; Zanoni, Paulo R Cc: intel-gfx@lists.freedesktop.orgmailto: intel-gfx@lists.freedesktop.org; Fu, Michael; Wu, Fengguang; 'Zhenyu Wang (zhen...@linux.intel.commailto:zhen...@linux.intel.com)'; Zhao, Yakui Subject: assertion on intel_disable_transcoder Hi Daniel/Paulo, It's easy to see such WARNING in dmesg, the DDI port is not disabled prior to disable transcoder. I am not sure it will impact the Pipe/transcoder/DDI-port configurations, anyway after some times WARNING, I could not make HDMI audio work anymore. With intel_audio_dump I could see the related configurations was totally disabled. DDI_BUF_CTL_A 0x0080 DDI Buffer Controler A DDI_BUF_CTL_B 0x DDI Buffer Controler B DDI_BUF_CTL_C 0x0080 DDI Buffer Controler C DDI_BUF_CTL_D 0x DDI Buffer Controler D DDI_BUF_CTL_E 0x8002 DDI Buffer Controler E PIPE_CONF_A 0x PIPE Configuration A PIPE_CONF_B 0x PIPE Configuration B PIPE_CONF_C 0x PIPE Configuration C PIPE_CONF_EDP 0x PIPE Configuration EDP PIPE_DDI_FUNC_CTL_A 0xc4034002 PIPE DDI Function Control A PIPE_DDI_FUNC_CTL_B 0xa0035000 PIPE DDI Function Control B PIPE_DDI_FUNC_CTL_C 0x0003 PIPE DDI Function Control C PIPE_DDI_FUNC_CTL_EDP 0x0003 PIPE DDI Function Control EDP TRANS_CONF0x Transcoder Configuration Thanks --xingchao [ 16.835658
Re: [Intel-gfx] assertion on intel_disable_transcoder
I am seeing this same trace (and no video) on multiple Haswell SDP's, with 3.6-rc7 (and earlier kernels) Was there ever a resolution on this? On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao xingchao.w...@intel.comwrote: Hi, Some update related to this warning. Ironlake_crtc_dpms() will enable/disable crtc which pipe was enabled/disabled there. Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and crtc was disabled, that causes intel_wait_for_vblank() timeout and some assertions. I think it's a bug but I have no clue where/when to enable crtc again. Here's part of dmesg before the warning and the message showing dpms off. [ 19.332220] [drm:intel_lvds_init], LVDS is not present in VBT [ 19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4 [ 19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B [ 19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f [ 19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f [ 19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off [ 19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled [ 19.351826] [ cut here ] [ 19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 19.351849] Hardware name: Shark Bay Client platform [ 19.351850] FDI TX state assertion failure (expected off, current on) [ 19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek snd_hda_codec_hdmi drm_kms_helper drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_rawmidi snd_s eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830 psmouse snd_seq_device usbnet snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc lpc_ich microcode mac_hid video lp parport e1000e usbhid hid [ 19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29 [ 19.351870] Call Trace: [ 19.351876] [8105278f] warn_slowpath_common+0x7f/0xc0 thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Tuesday, August 07, 2012 3:26 PM To: Daniel Vetter; Zanoni, Paulo R Cc: intel-gfx@lists.freedesktop.org; Fu, Michael; Wu, Fengguang; 'Zhenyu Wang (zhen...@linux.intel.com)'; Zhao, Yakui Subject: assertion on intel_disable_transcoder Hi Daniel/Paulo, It's easy to see such WARNING in dmesg, the DDI port is not disabled prior to disable transcoder. I am not sure it will impact the Pipe/transcoder/DDI-port configurations, anyway after some times WARNING, I could not make HDMI audio work anymore. With intel_audio_dump I could see the related configurations was totally disabled. DDI_BUF_CTL_A 0x0080 DDI Buffer Controler A DDI_BUF_CTL_B 0x DDI Buffer Controler B DDI_BUF_CTL_C 0x0080 DDI Buffer Controler C DDI_BUF_CTL_D 0x DDI Buffer Controler D DDI_BUF_CTL_E 0x8002 DDI Buffer Controler E PIPE_CONF_A 0x PIPE Configuration A PIPE_CONF_B 0x PIPE Configuration B PIPE_CONF_C 0x PIPE Configuration C PIPE_CONF_EDP 0x PIPE Configuration EDP PIPE_DDI_FUNC_CTL_A 0xc4034002 PIPE DDI Function Control A PIPE_DDI_FUNC_CTL_B 0xa0035000 PIPE DDI Function Control B PIPE_DDI_FUNC_CTL_C 0x0003 PIPE DDI Function Control C PIPE_DDI_FUNC_CTL_EDP 0x0003 PIPE DDI Function Control EDP TRANS_CONF0x Transcoder Configuration Thanks --xingchao [ 16.835658] [ cut here ] [ 16.835690] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 16.835691] Hardware name: Shark Bay Client platform [ 16.835692] FDI TX state assertion failure (expected off, current on) [ 16.835706] Modules linked in: snd_seq_midi_event i915(+) snd_seq snd_timer drm_kms_helper snd_seq _device ghash_clmulni_intel drm aesni_intel snd cryptd mcs7830 usbnet joydev aes_x86_64 soundcore psm ouse snd_page_alloc hid_generic i2c_algo_bit serio_raw video mac_hid microcode lpc_ich lp parport e10 00e usbhid hid [ 16.835708] Pid: 470, comm: modprobe Not tainted 3.5.0-rc46patches+ #12 [ 16.835709] Call Trace: [ 16.835715] [8105278f] warn_slowpath_common+0x7f/0xc0 [ 16.835718] [81052886] warn_slowpath_fmt+0x46/0x50 [ 16.835728] [a01cc847] assert_fdi_tx+0x87/0x90 [i915] [ 16.835739] [a01d5cf5] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.835748] [a01d641e] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.835756] [a01cdbd8] intel_crtc_dpms+0x48/0x140 [i915] [ 16.835768] [a01d49d5] intel_crtc_disable+0x35/0xb0 [i915] [ 16.835772] [a012d6a5]
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
I'm struggling to get back to a version that works on the Shark Bay / Haswell platform that I have. I did get it to work once...but have since updated the BIOS, so am not sure if that may have an effect on this test. v3.5 also gave a stack (below) - so without a working version, I cannot do the bisecting. Perhaps it is just too early in the Haswell dev cycle for me to try to get this working? [ 16.599822] [ cut here ] [ 16.605099] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.5/drivers/gpu/drm/i915/intel_display.c:976 assert_fdi_tx+0x87/0x90 [i915]() [ 16.619568] Hardware name: Shark Bay Client platform [ 16.625244] FDI TX state assertion failure (expected off, current on) [ 16.632632] Modules linked in: ahci(+) libahci crc32c_intel e1000e(+) ehci_hcd(+) i915(+) drm_kms_helper drm i2c_algo_bit video xhci_hcd intel_agp intel_gtt [ 16.648576] Pid: 142, comm: modprobe Not tainted 3.5.0-orc #14 [ 16.655275] Call Trace: [ 16.658130] [8104f67f] warn_slowpath_common+0x7f/0xc0 [ 16.665023] [8104f776] warn_slowpath_fmt+0x46/0x50 [ 16.665058] usb 1-11: new low-speed USB device number 2 using xhci_hcd [ 16.679111] [a00b8c57] assert_fdi_tx+0x87/0x90 [i915] [ 16.686001] [a00bdd65] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.689451] usb 1-11: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.703942] [a00be48e] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.711309] [a00b9bc8] intel_crtc_dpms+0x48/0x140 [i915] [ 16.718487] [a00c1af5] intel_crtc_disable+0x35/0xb0 [i915] [ 16.721916] usbcore: registered new interface driver usbhid [ 16.721917] usbhid: USB HID core driver [ 16.736714] [a008c6a5] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.746959] [a00c3ba7] intel_modeset_init+0x687/0xe50 [i915] [ 16.754536] [a009cd3a] i915_driver_load+0xa9a/0xb80 [i915] [ 16.761932] [a003aa7b] ? drm_get_minor+0x26b/0x310 [drm] [ 16.769086] [a003ce71] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.776278] [8157801e] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.784065] [a00e5917] i915_pci_probe+0x1b/0x1d [i915] [ 16.791041] [812da410] pci_device_probe+0xb0/0x140 [ 16.797631] [813909be] driver_probe_device+0x7e/0x220 [ 16.804527] [81390c0b] __driver_attach+0xab/0xb0 [ 16.810929] [81390b60] ? driver_probe_device+0x220/0x220 [ 16.818106] [8138ede6] bus_for_each_dev+0x56/0x90 [ 16.824609] [813904ce] driver_attach+0x1e/0x20 [ 16.830814] [81390080] bus_add_driver+0x1a0/0x270 [ 16.837305] [81391166] driver_register+0x76/0x130 [ 16.843805] [812da135] __pci_register_driver+0x55/0xd0 [ 16.850795] [8157bdcd] ? notifier_call_chain+0x4d/0x70 [ 16.857786] [a003d0aa] drm_pci_init+0x11a/0x130 [drm] [ 16.859591] usb 1-12: new low-speed USB device number 3 using xhci_hcd [ 16.872169] [a0116000] ? 0xa0115fff [ 16.878075] [a011608b] i915_init+0x8b/0x8d [i915] [ 16.884568] [8100203f] do_one_initcall+0x3f/0x170 [ 16.887716] usb 1-12: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.901316] [810affcf] sys_init_module+0x8f/0x200 [ 16.907797] [81580069] system_call_fastpath+0x16/0x1b [ 16.914692] ---[ end trace 941488b1333d181e ]--- On Fri, Aug 10, 2012 at 10:21 PM, Ben Guthro b...@guthro.net wrote: I'll try to do this early next week, and report back. On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky b...@bwidawsk.net wrote: On 2012-08-10 09:25, Ben Guthro wrote: Hello, I've been attempting to get a Shark Bay / Haswell platform up running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Yes it is the codebase you should use. It sounds like a regression, can you bisect it? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center
[Intel-gfx] v3.6 haswell regression from v3.5?
Hello, I've been attempting to get a Shark Bay / Haswell platform up running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
specifically, I get the following in my serial console - it is a warning...but seems to coincide with when standard vesa modes are switching over to the higer res KMS modes: [ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake wait timed out [ 15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 15.905161] [drm] Driver supports precise vblank timestamp query. [ 15.912293] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 15.943700] [ cut here ] [ 15.949041] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 15.963591] Hardware name: Shark Bay Client platform [ 15.969288] FDI TX state assertion failure (expected off, current on) [ 15.976678] Modules linked in: crc32c_intel ahci(+) libahci ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video xhci_hcd [ 15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9 [ 15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd [ 16.006609] Call Trace: [ 16.009462] [8105284f] warn_slowpath_common+0x7f/0xc0 [ 16.016356] [81052946] warn_slowpath_fmt+0x46/0x50 [ 16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.032989] [a00c48c7] assert_fdi_tx+0x87/0x90 [i915] [ 16.040070] [a00c9f55] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.047923] [a00ca67e] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.055302] [a00c5a58] intel_crtc_dpms+0x48/0x140 [i915] [ 16.061100] usbcore: registered new interface driver usbhid [ 16.061101] usbhid: USB HID core driver [ 16.073325] [a00cdf95] intel_crtc_disable+0x35/0xb0 [i915] [ 16.080700] [a0095735] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.090943] [a00d00a7] intel_modeset_init+0x6b7/0xf10 [i915] [ 16.098525] [a00a6bba] i915_driver_load+0xa8a/0xb90 [i915] [ 16.105913] [a004372b] ? drm_get_minor+0x26b/0x310 [drm] [ 16.113082] [a0045c21] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.120276] [8158f30e] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.128061] [a00f309b] i915_pci_probe+0x4f/0x57 [i915] [ 16.135039] [812e0d30] pci_device_probe+0xb0/0x140 [ 16.141631] [8139faab] driver_probe_device+0x7b/0x240 [ 16.148525] [8139fd1b] __driver_attach+0xab/0xb0 [ 16.154927] [8139fc70] ? driver_probe_device+0x240/0x240 [ 16.162106] [8139dec6] bus_for_each_dev+0x56/0x90 [ 16.168607] [8139f5de] driver_attach+0x1e/0x20 [ 16.174811] [8139f150] bus_add_driver+0x190/0x290 [ 16.181303] [813a027a] driver_register+0x7a/0x160 [ 16.187805] [812e0a55] __pci_register_driver+0x55/0xd0 [ 16.193436] usb 1-6: new low-speed USB device number 3 using xhci_hcd [ 16.202180] [815930cd] ? notifier_call_chain+0x4d/0x70 [ 16.209173] [a0045e5a] drm_pci_init+0x11a/0x130 [drm] [ 16.216061] [a0125000] ? 0xa0124fff [ 16.221970] [a0125066] i915_init+0x66/0x68 [i915] [ 16.223558] usb 1-6: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.238617] [8100203f] do_one_initcall+0x3f/0x170 [ 16.245104] [810b3dbf] sys_init_module+0x8f/0x200 [ 16.251599] [815973a9] system_call_fastpath+0x16/0x1b [ 16.258494] ---[ end trace 949ccd38b0452265 ]--- On Fri, Aug 10, 2012 at 12:25 PM, Ben Guthro b...@guthro.net wrote: Hello, I've been attempting to get a Shark Bay / Haswell platform up running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
well...it gave me a different stack...but still no graphics: This is with the drm-intel-fixes branch merged in - I thought that branch might help...but it didn't seem to. [ 16.615950] [ cut here ] [ 16.621229] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1119 assert_fdi_tx+0x87/0x90 [i915]() [ 16.635796] Hardware name: Shark Bay Client platform [ 16.641472] FDI TX state assertion failure (expected off, current on) [ 16.648863] Modules linked in: crc32c_intel ahci(+) libahci ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video xhci_hcd [ 16.664808] Pid: 141, comm: modprobe Not tainted 3.6.0-orc #11 [ 16.671503] Call Trace: [ 16.674364] [8105284f] warn_slowpath_common+0x7f/0xc0 [ 16.681250] [81052946] warn_slowpath_fmt+0x46/0x50 [ 16.681305] usb 1-5: new low-speed USB device number 2 using xhci_hcd [ 16.695251] [a00c48f7] assert_fdi_tx+0x87/0x90 [i915] [ 16.702135] [a00c9fd5] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.710013] [a00ca6fe] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.711864] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.727384] [a00c5a88] intel_crtc_dpms+0x48/0x140 [i915] [ 16.734590] [a00ce015] intel_crtc_disable+0x35/0xb0 [i915] [ 16.741932] [a0095735] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.751668] usbcore: registered new interface driver usbhid [ 16.751669] usbhid: USB HID core driver [ 16.763019] [a00d0127] intel_modeset_init+0x6b7/0xf10 [i915] [ 16.770594] [a00a6bba] i915_driver_load+0xa8a/0xb90 [i915] [ 16.777977] [a004372b] ? drm_get_minor+0x26b/0x310 [drm] [ 16.785143] [a0045c21] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.792337] [8158553e] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.800125] [a00f31eb] i915_pci_probe+0x4f/0x57 [i915] [ 16.807096] [812e0d30] pci_device_probe+0xb0/0x140 [ 16.813689] [813997cb] driver_probe_device+0x7b/0x240 [ 16.820582] [81399a3b] __driver_attach+0xab/0xb0 [ 16.826984] [8130] ? driver_probe_device+0x240/0x240 [ 16.834163] [81397be6] bus_for_each_dev+0x56/0x90 [ 16.840664] [813992fe] driver_attach+0x1e/0x20 [ 16.840694] usb 1-6: new low-speed USB device number 3 using xhci_hcd [ 16.854251] [81398e70] bus_add_driver+0x190/0x290 [ 16.860748] [81399f9a] driver_register+0x7a/0x160 [ 16.867247] [812e0a55] __pci_register_driver+0x55/0xd0 [ 16.868830] usb 1-6: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.884396] [8158930d] ? notifier_call_chain+0x4d/0x70 [ 16.891397] [a0045e5a] drm_pci_init+0x11a/0x130 [drm] [ 16.898260] [a0125000] ? 0xa0124fff [ 16.904172] [a0125066] i915_init+0x66/0x68 [i915] [ 16.910666] [8100203f] do_one_initcall+0x3f/0x170 [ 16.917167] [810b3dbf] sys_init_module+0x8f/0x200 [ 16.923652] [8158d5e9] system_call_fastpath+0x16/0x1b [ 16.930548] ---[ end trace fa81da3bacf4c4b0 ]--- On Fri, Aug 10, 2012 at 1:16 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Aug 10, 2012 at 12:51:42PM -0400, Ben Guthro wrote: specifically, I get the following in my serial console - it is a warning...but seems to coincide with when standard vesa modes are switching over to the higer res KMS modes: Can you try to boot with i915.i915_enable_rc6=0 please? -Daniel [ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake wait timed out [ 15.897707] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 15.905161] [drm] Driver supports precise vblank timestamp query. [ 15.912293] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 15.943700] [ cut here ] [ 15.949041] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.2/drivers/gpu/drm/i915/intel_display.c:1118 assert_fdi_tx+0x87/0x90 [i915]() [ 15.963591] Hardware name: Shark Bay Client platform [ 15.969288] FDI TX state assertion failure (expected off, current on) [ 15.976678] Modules linked in: crc32c_intel ahci(+) libahci ehci_hcd(+) e1000e(+) i915(+) drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video xhci_hcd [ 15.992621] Pid: 148, comm: modprobe Not tainted 3.6.0-orc #9 [ 15.993459] usb 1-5: new low-speed USB device number 2 using xhci_hcd [ 16.006609] Call Trace: [ 16.009462] [8105284f] warn_slowpath_common+0x7f/0xc0 [ 16.016356] [81052946] warn_slowpath_fmt+0x46/0x50 [ 16.019911] usb 1-5: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.032989] [a00c48c7] assert_fdi_tx+0x87/0x90 [i915] [ 16.040070] [a00c9f55
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
I'll try to do this early next week, and report back. On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky b...@bwidawsk.net wrote: On 2012-08-10 09:25, Ben Guthro wrote: Hello, I've been attempting to get a Shark Bay / Haswell platform up running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Yes it is the codebase you should use. It sounds like a regression, can you bisect it? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Ironlake eDP training broken in 3.2.2
I'm moving my company's distro from 2.6.38 to 3.2.X (currently 3.2.2) - and have found a regression in i915 that I'm hoping someone here might have a fix for, already. On some older platforms, I'm seeing the stack below that results in the screen never showing anything. Any thoughts, patches, suggestions are appreciated. - Ben Guthro [ 28.064432] [ cut here ] [ 28.064468] WARNING: at /builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071 ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]() [ 28.064472] Hardware name: Latitude E5510 [ 28.064474] eDP VDD not forced on [ 28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C) i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video [ 28.064546] Pid: 309, comm: plymouthd Tainted: GWC O 3.2.2-orc #1 [ 28.064548] Call Trace: [ 28.064557] [8106233f] warn_slowpath_common+0x7f/0xc0 [ 28.064561] [81062436] warn_slowpath_fmt+0x46/0x50 [ 28.064573] [a00cf79f] ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915] [ 28.064584] [a00cf7ff] intel_dp_commit+0x4f/0xb0 [i915] [ 28.064590] [a00700bb] drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper] [ 28.064597] [a0070fbf] drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper] [ 28.064603] [a006dcc0] drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper] [ 28.064614] [a00d77bc] intel_fb_restore_mode+0x1c/0x50 [i915] [ 28.064623] [a00a0da9] i915_driver_lastclose+0x39/0x80 [i915] [ 28.064635] [a0022699] drm_lastclose+0x49/0x300 [drm] [ 28.064643] [a002370d] drm_release+0x4fd/0x6c0 [drm] [ 28.064648] [81164f5a] fput+0xea/0x220 [ 28.064651] [81161926] filp_close+0x66/0x90 [ 28.064654] [81161a02] sys_close+0xb2/0x120 [ 28.064660] [8157f7c2] system_call_fastpath+0x16/0x1b [ 28.064662] ---[ end trace 4d53f99c84fca531 ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Ironlake eDP training broken in 3.2.2
FWIW, I found the following patch that seems to solve the issue, on this platform: https://bugs.freedesktop.org/attachment.cgi?id=56178 linked from: https://bugs.freedesktop.org/show_bug.cgi?id=42263 I was unable to find this committed in any of the dev trees, however. Does this have any known issues on other platforms? On Wed, Feb 1, 2012 at 10:17 AM, Ben Guthro b...@guthro.net wrote: I'm moving my company's distro from 2.6.38 to 3.2.X (currently 3.2.2) - and have found a regression in i915 that I'm hoping someone here might have a fix for, already. On some older platforms, I'm seeing the stack below that results in the screen never showing anything. Any thoughts, patches, suggestions are appreciated. - Ben Guthro [ 28.064432] [ cut here ] [ 28.064468] WARNING: at /builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071 ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]() [ 28.064472] Hardware name: Latitude E5510 [ 28.064474] eDP VDD not forced on [ 28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C) i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt video [ 28.064546] Pid: 309, comm: plymouthd Tainted: G WC O 3.2.2-orc #1 [ 28.064548] Call Trace: [ 28.064557] [8106233f] warn_slowpath_common+0x7f/0xc0 [ 28.064561] [81062436] warn_slowpath_fmt+0x46/0x50 [ 28.064573] [a00cf79f] ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915] [ 28.064584] [a00cf7ff] intel_dp_commit+0x4f/0xb0 [i915] [ 28.064590] [a00700bb] drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper] [ 28.064597] [a0070fbf] drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper] [ 28.064603] [a006dcc0] drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper] [ 28.064614] [a00d77bc] intel_fb_restore_mode+0x1c/0x50 [i915] [ 28.064623] [a00a0da9] i915_driver_lastclose+0x39/0x80 [i915] [ 28.064635] [a0022699] drm_lastclose+0x49/0x300 [drm] [ 28.064643] [a002370d] drm_release+0x4fd/0x6c0 [drm] [ 28.064648] [81164f5a] fput+0xea/0x220 [ 28.064651] [81161926] filp_close+0x66/0x90 [ 28.064654] [81161a02] sys_close+0xb2/0x120 [ 28.064660] [8157f7c2] system_call_fastpath+0x16/0x1b [ 28.064662] ---[ end trace 4d53f99c84fca531 ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v2)
This also didn't fix the Dell E6410. I'll also note this in the bug.
I'm trying to work with some contacts at Dell to get this routed to
the right person as well...but am having limited luck with that, so
far.
On Mon, Jun 28, 2010 at 2:28 AM, Dave Airlie airl...@gmail.com wrote:
On Mon, Jun 28, 2010 at 4:04 PM, Zhenyu Wang zhen...@linux.intel.com wrote:
On 2010.06.28 09:45:14 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
So the previous fix didn't work for everyone, I read the eDP spec and
claims a 20% overhead for encoding, so make sure we take this into account
when working out the bandwidth requirements.
This makes my eDP panel happy also, please test on others.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 6094e42..9830243 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -139,6 +139,12 @@ intel_dp_link_required(struct drm_device *dev,
}
static int
+intel_dp_max_data_rate(int max_link_clock, int max_lanes)
+{
+ return (max_link_clock * max_lanes * 8) / 10;
+}
+
+static int
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -148,7 +154,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_lanes = intel_dp_max_lane_count(intel_encoder);
if (intel_dp_link_required(connector-dev, intel_encoder, mode-clock)
- max_link_clock * max_lanes)
+ intel_dp_max_data_rate(max_link_clock, max_lanes))
return MODE_CLOCK_HIGH;
if (mode-clock 1)
@@ -509,7 +515,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
for (clock = 0; clock = max_clock; clock++) {
- int link_avail = intel_dp_link_clock(bws[clock]) *
lane_count;
+ int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
if (intel_dp_link_required(encoder-dev,
intel_encoder, mode-clock)
= link_avail) {
--
sorry, this is still broken on the 16x9 panel.
'intel_dp_link_required' is 107840*18/8 = 242640, 'intel_dp_max_data_rate' is
27*1*8/10 = 216000. So it will fail in both check.
So this panel is definitely out of spec, according to the eDP table 3.2 and
3.3
Are you sure this is the mode it actually advertises over EDID vs some
crazy mode stored in VBT?
According to the eDP spec it needs 2 lanes and 1.62.
A cvt rb 1600x900 mode would fit okay
cvt -r 1600 900
# 1600x900 59.82 Hz (CVT 1.44M9-R) hsync: 55.40 kHz; pclk: 97.50 MHz
Modeline 1600x900R 97.50 1600 1648 1680 1760 900 903 908 926 +hsync
-vsync
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915: Dell E6410 Ironlake display detection
I posted a similar question to LKML yesterday, but perhaps this is a better forum for this discussion, as it seemed to get lost amongst many other non-graphics related discussions. I have a problematic machine, that I have traced the problem down to what I think is an issue with the i915 detection of the LVDS on the Ironlake chip. The machine in question is a Dell Latitude E6410 - i5 laptop, with the intel Ironlake chip, and the failure condition is such that when the boot sequence switches into KMS mode, the screen goes black, and never comes back. It seems to be very similar to both https://bugs.freedesktop.org/show_bug.cgi?id=28224 and https://bugs.freedesktop.org/show_bug.cgi?id=28070 However, I have tried all of the patches suggested on these bugs, to no avail (yet) My base install is Ubuntu 10.04, and I've spun through a few kernels to try to bisect the problem. Unfortunately, I've been unable to find a kernel that works, but I have settled on linus' 2.6.35rc3 for debugging this... I can get the machine to come up on an external display, if switched at the BIOS screen...but /sys/class/card0 never shows an LVDS...and dmesg doesn't seem to be throwing any errors. If you have any thoughts on what I might try next, in attempting to debug this issue, I'd appreciate any pointers, as the intel cards isn't my particular area of expertise, but am capable enough to read the code... Regards, Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915: Dell E6410 Ironlake display detection
FWIW, I filed a bug here on this issue, to have something to attach the output of various useful info https://bugs.freedesktop.org/show_bug.cgi?id=28746 On Thu, Jun 24, 2010 at 2:55 PM, Ben Guthro ben.guthro+intel-...@gmail.com wrote: I posted a similar question to LKML yesterday, but perhaps this is a better forum for this discussion, as it seemed to get lost amongst many other non-graphics related discussions. I have a problematic machine, that I have traced the problem down to what I think is an issue with the i915 detection of the LVDS on the Ironlake chip. The machine in question is a Dell Latitude E6410 - i5 laptop, with the intel Ironlake chip, and the failure condition is such that when the boot sequence switches into KMS mode, the screen goes black, and never comes back. It seems to be very similar to both https://bugs.freedesktop.org/show_bug.cgi?id=28224 and https://bugs.freedesktop.org/show_bug.cgi?id=28070 However, I have tried all of the patches suggested on these bugs, to no avail (yet) My base install is Ubuntu 10.04, and I've spun through a few kernels to try to bisect the problem. Unfortunately, I've been unable to find a kernel that works, but I have settled on linus' 2.6.35rc3 for debugging this... I can get the machine to come up on an external display, if switched at the BIOS screen...but /sys/class/card0 never shows an LVDS...and dmesg doesn't seem to be throwing any errors. If you have any thoughts on what I might try next, in attempting to debug this issue, I'd appreciate any pointers, as the intel cards isn't my particular area of expertise, but am capable enough to read the code... Regards, Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
