Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Thu, Jan 30, 2014 at 09:53:54AM -0500, Alan Stern wrote: On Tue, 28 Jan 2014, Daniel Vetter wrote: I think I need a bit more debug output first. Can you please apply the below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from boot? The dmesg output is below. Since you didn't say whether this should go on top of the previous patch or in place of it, I put this in place of the first one. BTW, I had to fix a bug in the patch: @@ -9171,6 +9181,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, *disable_pipes |= 1 intel_crtc-pipe; else *prepare_pipes |= 1 intel_crtc-pipe; + + DRM_DEBUG_KMS([CRTC:%d:%s]: prepare_pipes %u\n, + intel_crtc-base.base.id, + pipe_name(intel_crtc-pipe), + *prepare_pipes); } pipe_name() returns char, not char *. I changed the output format specifier from %s to %c. Ok, I seem to have been truly blind all the time. This seems to have been fallout from commit b6c5164d7bf624f3e1b750787ddb983150c5117c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Apr 12 18:48:43 2013 +0200 drm/i915: Fixup Oops in the pipe config computation Meanwhile we've moved the overall infrastructure ahead again quite a bit, so I think it's time to give the full atomic modeset paths another shot. But I'll be travelling to fosdem the next few days, so this will take a bit of time. As long as there's not real bad side-effects I guess we simply need to live with the WARN for a tad longer. -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] Excessive WARN()s in Intel 915 driver
On Thu, 30 Jan 2014, Daniel Vetter wrote: Ok, I seem to have been truly blind all the time. This seems to have been fallout from commit b6c5164d7bf624f3e1b750787ddb983150c5117c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Apr 12 18:48:43 2013 +0200 drm/i915: Fixup Oops in the pipe config computation Meanwhile we've moved the overall infrastructure ahead again quite a bit, so I think it's time to give the full atomic modeset paths another shot. But I'll be travelling to fosdem the next few days, so this will take a bit of time. As long as there's not real bad side-effects I guess we simply need to live with the WARN for a tad longer. Okay. Let me know when you've got something else ready to test. Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Wed, Jan 8, 2014 at 7:43 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: The log looks fairly clear to me: 1. initially panel fitter is enabled on pipe B, and pipe B is outputting to LVDS and VGA. Border is enabled. 2. pipe A gets enabled outputting to LVDS. This will overwrite the LVDS border bits 3. pipe B is still active so we do the state check, but as the LVDS border bits have been clobbered earlier, the state checker gets angry Meh, I've been fairly dense the entire time. This is indeed the root-cause, with the twist that we're allowing the impossible: Essentially we take away the panel fitter from pipe B to pipe A while it is strictly still in use by pipe B for VGA. Currently no idea how to properly fix this in a not too intrusive way. The other issue is that the encoders connected to pipe B change in the first modeset, but that's not reflected in the pipe masks. -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] Excessive WARN()s in Intel 915 driver
On Tue, Jan 28, 2014 at 06:17:00PM +0100, Daniel Vetter wrote: On Wed, Jan 8, 2014 at 7:43 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: The log looks fairly clear to me: 1. initially panel fitter is enabled on pipe B, and pipe B is outputting to LVDS and VGA. Border is enabled. 2. pipe A gets enabled outputting to LVDS. This will overwrite the LVDS border bits 3. pipe B is still active so we do the state check, but as the LVDS border bits have been clobbered earlier, the state checker gets angry Meh, I've been fairly dense the entire time. This is indeed the root-cause, with the twist that we're allowing the impossible: Essentially we take away the panel fitter from pipe B to pipe A while it is strictly still in use by pipe B for VGA. Currently no idea how to properly fix this in a not too intrusive way. The other issue is that the encoders connected to pipe B change in the first modeset, but that's not reflected in the pipe masks. I think I need a bit more debug output first. Can you please apply the below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from boot? Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 122f87155b8e..554c30e89308 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9144,6 +9144,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, if (connector-new_encoder) *prepare_pipes |= 1 connector-new_encoder-new_crtc-pipe; + + DRM_DEBUG_KMS([CONNECTOR:%d:%s]: prepare_pipes %u\n, + connector-base.base.id, + drm_get_connector_name(connector-base), + *prepare_pipes); } list_for_each_entry(encoder, dev-mode_config.encoder_list, @@ -9159,6 +9164,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, if (encoder-new_crtc) *prepare_pipes |= 1 encoder-new_crtc-pipe; + + DRM_DEBUG_KMS([ENCODER:%d:%s]: prepare_pipes %u\n, + encoder-base.base.id, + drm_get_encoder_name(encoder-base), + *prepare_pipes); } /* Check for pipes that will be enabled/disabled ... */ @@ -9171,6 +9181,11 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, *disable_pipes |= 1 intel_crtc-pipe; else *prepare_pipes |= 1 intel_crtc-pipe; + + DRM_DEBUG_KMS([CRTC:%d:%s]: prepare_pipes %u\n, + intel_crtc-base.base.id, + pipe_name(intel_crtc-pipe), + *prepare_pipes); } -- 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] Excessive WARN()s in Intel 915 driver
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu wrote: Don't bother. I'll redo it using the drm-intel-nightly branch, but I won't have time for a few days. My apologies for the delay in getting around to this. Can you please test the patch i've just posted? http://patchwork.freedesktop.org/patch/18810/ 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] Excessive WARN()s in Intel 915 driver
On Mon, Jan 27, 2014 at 10:30:11AM -0500, Alan Stern wrote: On Mon, 27 Jan 2014, Daniel Vetter wrote: On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu wrote: Don't bother. I'll redo it using the drm-intel-nightly branch, but I won't have time for a few days. My apologies for the delay in getting around to this. Can you please test the patch i've just posted? http://patchwork.freedesktop.org/patch/18810/ I will. By the way, I tried getting an up-to-date version of your drm-intel-nightly branch, and ended up with the following: $ git clone --depth 1 -b drm-intel-nightly http://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: dumb http transport does not support --depth (I can't remember what happened the first time I tried to clone your repository). So I will try running with this patch on top of 3.13. Well, use the git:// link with --depth ... -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] Excessive WARN()s in Intel 915 driver
On Mon, 27 Jan 2014, Daniel Vetter wrote: By the way, I tried getting an up-to-date version of your drm-intel-nightly branch, and ended up with the following: $ git clone --depth 1 -b drm-intel-nightly http://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: dumb http transport does not support --depth (I can't remember what happened the first time I tried to clone your repository). So I will try running with this patch on top of 3.13. Well, use the git:// link with --depth ... $ git clone --depth 1 -b drm-intel-nightly git://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: remote error: access denied or repository not exported: ~danvet/drm-intel/ Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Mon, 27 Jan 2014, Daniel Vetter wrote: On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu wrote: Don't bother. I'll redo it using the drm-intel-nightly branch, but I won't have time for a few days. My apologies for the delay in getting around to this. Can you please test the patch i've just posted? http://patchwork.freedesktop.org/patch/18810/ I will. By the way, I tried getting an up-to-date version of your drm-intel-nightly branch, and ended up with the following: $ git clone --depth 1 -b drm-intel-nightly http://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: dumb http transport does not support --depth (I can't remember what happened the first time I tried to clone your repository). So I will try running with this patch on top of 3.13. Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote: On Mon, 27 Jan 2014, Daniel Vetter wrote: By the way, I tried getting an up-to-date version of your drm-intel-nightly branch, and ended up with the following: $ git clone --depth 1 -b drm-intel-nightly http://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: dumb http transport does not support --depth (I can't remember what happened the first time I tried to clone your repository). So I will try running with this patch on top of 3.13. Well, use the git:// link with --depth ... $ git clone --depth 1 -b drm-intel-nightly git://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: remote error: access denied or repository not exported: ~danvet/drm-intel/ Erhm, http://cgit.freedesktop.org/~danvet/drm-intel/ is the cgit web view, the actual git repo is at http://cgit.freedesktop.org/~danvet/drm-intel/ ... 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] Excessive WARN()s in Intel 915 driver
On Mon, 27 Jan 2014, Daniel Vetter wrote: On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote: On Mon, 27 Jan 2014, Daniel Vetter wrote: By the way, I tried getting an up-to-date version of your drm-intel-nightly branch, and ended up with the following: $ git clone --depth 1 -b drm-intel-nightly http://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: dumb http transport does not support --depth (I can't remember what happened the first time I tried to clone your repository). So I will try running with this patch on top of 3.13. Well, use the git:// link with --depth ... $ git clone --depth 1 -b drm-intel-nightly git://cgit.freedesktop.org/~danvet/drm-intel/ Cloning into 'drm-intel'... fatal: remote error: access denied or repository not exported: ~danvet/drm-intel/ Erhm, http://cgit.freedesktop.org/~danvet/drm-intel/ is the cgit web view, the actual git repo is at http://cgit.freedesktop.org/~danvet/drm-intel/ ... I used git://freedesktop.org/~danvet/drm-intel/ and that worked. I'll post the results when I get a chance to try the patch. Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Mon, Jan 13, 2014 at 03:16:42PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ I posted the output from the default branch in that repository last week: http://marc.info/?l=linux-kernelm=138922294308576w=2 The default branch actually tends to be something stale, you need to explicitly check out drm-intel-nightly ... Have you had time to look at the results yet? It's marked on my todo, but unfortunately haven't gotten around to write the patch yet (and analyze your log some more) ... I'll move it up the prio list a bit. -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] Excessive WARN()s in Intel 915 driver
On Mon, 13 Jan 2014, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ I posted the output from the default branch in that repository last week: http://marc.info/?l=linux-kernelm=138922294308576w=2 Have you had time to look at the results yet? I think it might be the time to file this as a new bug on DRM/Intel at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI BR, Jani. Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Tue, 14 Jan 2014, Daniel Vetter wrote: On Mon, Jan 13, 2014 at 03:16:42PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ I posted the output from the default branch in that repository last week: http://marc.info/?l=linux-kernelm=138922294308576w=2 The default branch actually tends to be something stale, you need to explicitly check out drm-intel-nightly ... Have you had time to look at the results yet? It's marked on my todo, but unfortunately haven't gotten around to write the patch yet (and analyze your log some more) ... I'll move it up the prio list a bit. Don't bother. I'll redo it using the drm-intel-nightly branch, but I won't have time for a few days. Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ I posted the output from the default branch in that repository last week: http://marc.info/?l=linux-kernelm=138922294308576w=2 Have you had time to look at the results yet? Alan Stern ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Excessive WARN()s in Intel 915 driver
Hello, The check_crtc_state() routine in drivers/gpu/drm/i915/intel_display.c contains a whole bunch of WARN() statements (and so do other routines in this source file, but this is the one I'm presently concerned about). Is it really necessary for these to be WARN? I don't see how it does any good, every single time I boot my computer, for the log to get filled with a register dump and stack backtrace: [2.149090] [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0) [2.149091] [ cut here ] [2.149137] WARNING: CPU: 0 PID: 151 at drivers/gpu/drm/i915/intel_display.c:8334 check_crtc_state+0x5d8/0xb90 [i915]() [2.149138] pipe state doesn't match! [2.149145] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video [2.149149] CPU: 0 PID: 151 Comm: systemd-udevd Not tainted 3.11.10-100.fc18.i686 #1 [2.149151] Hardware name: ASUSTeK Computer Inc. UL20A /UL20A , BIOS 207 11/02/2009 [2.149157] f65cb50c c0992345 f65cb54c f65cb53c c0448f14 f80b1af2 [2.149163] f65cb568 0097 f80a95a0 208e f8062cf8 f8062cf8 f666564c f6665000 [2.149168] 0004 f65cb554 c0448fd3 0009 f65cb54c f80b1af2 f65cb568 f65cb7c0 [2.149169] Call Trace: [2.149177] [c0992345] dump_stack+0x41/0x52 [2.149182] [c0448f14] warn_slowpath_common+0x84/0xa0 [2.149221] [f8062cf8] ? check_crtc_state+0x5d8/0xb90 [i915] [2.149259] [f8062cf8] ? check_crtc_state+0x5d8/0xb90 [i915] [2.149264] [c0448fd3] warn_slowpath_fmt+0x33/0x40 [2.149302] [f8062cf8] check_crtc_state+0x5d8/0xb90 [i915] [2.149346] [f806d302] intel_modeset_check_state+0x292/0x770 [i915] [2.149385] [f806d854] intel_set_mode+0x34/0x40 [i915] [2.149424] [f806df5b] intel_crtc_set_config+0x6fb/0x920 [i915] [2.149447] [f7d555eb] drm_mode_set_config_internal+0x4b/0xc0 [drm] [2.149454] [f7d031fd] drm_fb_helper_set_par+0x4d/0xc0 [drm_kms_helper] [2.149459] [c06e0f22] fbcon_init+0x482/0x4d0 [2.149465] [c073fc9e] visual_init+0x9e/0x100 [2.149469] [c0742051] do_bind_con_driver+0x111/0x2d0 [2.149474] [c05b6178] ? sysfs_add_file+0x18/0x20 [2.149477] [c05b6221] ? sysfs_create_file+0x21/0x30 [2.149482] [c074230d] do_take_over_console+0xfd/0x1a0 [2.149485] [c06df7af] do_fbcon_takeover+0x5f/0xc0 [2.149489] [c06e2e7f] fbcon_event_notify+0x58f/0x690 [2.149493] [c05b6135] ? sysfs_add_file_mode+0x85/0xb0 [2.149497] [c099bb63] notifier_call_chain+0x43/0x60 [2.149502] [c046b151] __blocking_notifier_call_chain+0x41/0x80 [2.149505] [c046b1af] blocking_notifier_call_chain+0x1f/0x30 [2.149508] [c06d4ce6] fb_notifier_call_chain+0x16/0x20 [2.149511] [c06d6d05] register_framebuffer+0x1b5/0x2d0 [2.149518] [f7d02f44] drm_fb_helper_initial_config+0x2d4/0x470 [drm_kms_helper] [2.149523] [c0546b48] ? __kmalloc+0x228/0x230 [2.149555] [f803d293] ? i915_write32+0xa3/0x140 [i915] [2.149587] [f803cd72] ? i915_read32+0x52/0x110 [i915] [2.149631] [f808d96e] intel_fbdev_initial_config+0x1e/0x20 [i915] [2.149663] [f8040cfb] i915_driver_load+0xcbb/0xcf0 [i915] [2.149694] [f803e2a0] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] [2.149714] [f7d51553] drm_get_pci_dev+0x133/0x250 [drm] [2.149746] [f803c43b] i915_pci_probe+0x2b/0x60 [i915] [2.149752] [c06bc619] pci_device_probe+0x79/0xb0 [2.149756] [c076b5f9] driver_probe_device+0x79/0x360 [2.149760] [c06bc55e] ? pci_match_device+0x9e/0xb0 [2.149763] [c076b971] __driver_attach+0x91/0xa0 [2.149767] [c076b8e0] ? driver_probe_device+0x360/0x360 [2.149770] [c0769ab2] bus_for_each_dev+0x42/0x80 [2.149773] [c076affe] driver_attach+0x1e/0x20 [2.149776] [c076b8e0] ? driver_probe_device+0x360/0x360 [2.149779] [c076ac2c] bus_add_driver+0xec/0x270 [2.149783] [c06bc410] ? pci_device_shutdown+0x60/0x60 [2.149786] [c076bf6a] driver_register+0x6a/0x160 [2.149790] [c04a23b4] ? smp_call_function_many+0x1f4/0x230 [2.149793] [f7d0d000] ? 0xf7d0cfff [2.149796] [f7d0d000] ? 0xf7d0cfff [2.149800] [c06bb7f3] __pci_register_driver+0x33/0x40 [2.149816] [f7d5176d] drm_pci_init+0xfd/0x110 [drm] [2.149819] [f7d0d000] ? 0xf7d0cfff [2.149850] [f7d0d05e] i915_init+0x5e/0x60 [i915] [2.149854] [c040045a] do_one_initcall+0xda/0x1a0 [2.149856] [f7d0d000] ? 0xf7d0cfff [2.149861] [c04d5191] ? tracepoint_update_probe_range+0x41/0x120 [2.149863] [f7d0d000] ? 0xf7d0cfff [2.149867] [c043d107] ? set_memory_ro+0x37/0x40 [2.149872] [c04a75d6] load_module+0x1bb6/0x2470 [2.149879] [c04a7f37] SyS_init_module+0xa7/0x110 [2.149883] [c051f06b] ? vm_mmap_pgoff+0x8b/0xb0 [2.149889] [c099f60d] sysenter_do_call+0x12/0x28 [2.149891] ---[ end trace d9dbcbe8160eac5c ]--- After all, it's not like there's anything I can do to fix the hardware,
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Wed, Jan 08, 2014 at 05:17:13PM +0100, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ Thanks, Daniel The log looks fairly clear to me: 1. initially panel fitter is enabled on pipe B, and pipe B is outputting to LVDS and VGA. Border is enabled. 2. pipe A gets enabled outputting to LVDS. This will overwrite the LVDS border bits 3. pipe B is still active so we do the state check, but as the LVDS border bits have been clobbered earlier, the state checker gets angry This actually hits another problem we still have. We've changing the pipe for the LVDS port w/o shutting the port down in between. That doesn't sound entirely safe. I wonder if we still have some real issues preventing this change? * intel_modeset_setup_hw_state does not. */ *modeset_pipes = 1 intel_crtc-pipe; - *prepare_pipes = 1 intel_crtc-pipe; DRM_DEBUG_KMS(set mode pipe masks: modeset: %x, prepare: %x, disable: %x\n, *modeset_pipes, *prepare_pipes, *disable_pipes); -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Excessive WARN()s in Intel 915 driver
On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote: On Wed, 8 Jan 2014, Daniel Vetter wrote: On Wed, Jan 08, 2014 at 11:08:08AM -0500, Alan Stern wrote: On Tue, 7 Jan 2014, Daniel Vetter wrote: I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Here you go. This is the dmesg output after booting with drm.debug=0xe. Pay no attention to the AS suffix in the version string; this is pristine 3.13-rc7. That's strange, I've thought we've fixed the last struggling mismatch in the lvds borber bits stuff. Can you please try latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ I prefer not to clone 1.7 GB of git data if at all possible. Can you post (or send to me directly) a patch containing the differences with respect to 3.13-rc7? It should end up being fairly small. Shallow clones should reduce the data tremendously, see git help clone. -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] Excessive WARN()s in Intel 915 driver
On Tue, Jan 7, 2014 at 7:50 PM, Alan Stern st...@rowland.harvard.edu wrote: After all, it's not like there's anything I can do to fix the hardware, is there? And it doesn't look like the pipe state mismatch is going to go away by itself. Or is this a genuine, fixable, software bug? These are genuine software bugs - every time one of these WARNs fires our software tracking and the actual hardware state have diverged, which eventually will lead to really subtle and hard to reproduce bugs. In any case, wouldn't it be good enough for this message to be dev_warn() instead of WARN()? I really want users to report these issues, and excessive WARNs seems to be the only way to get those reports. Please boot with drm.debug=0xe added to your kernel cmdline and reproduce this issues. Also, which precise kernel are you running? Testing latest -rc is always recommended, this state checker code is fairly new and gets constantly extended and bugs fixed ... Yours, 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
