Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station
> Hm something seems to be deeply wrong here. And the oops you've captured > still doesn't include the debug messages before things go boom. Can you > please replace the WARN_ON in my previous patch with a BUG_ON? That should > stop the machine at least and hopefully prevents it all from going boom. I've switched WARN_ON to BUG_ON and in deed it appears right before the oops: http://imgur.com/eKFSTYB > And please play around with dmesg -n to get these debug messages to the > console. I really need them to figure out what's going wrong here. Please see attached .bz file. This is the max debug output taken from /proc/kmsg right up to the oops. This is everything I got out of it. Maybe I've missed something to get more debug messages to the console other than setting kernel parameters to drm.debug=0xff log_buf_len=10M LOGLEVEL=8 debug and dmesg config dmesg -n 7 and dmesg -n 8. Any hints? - Nic 4.1-rc4_4.log.tar.bz2 Description: BZip2 compressed data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station
Hi Daniel,
> Ah, Chris hunch against my claim that this is impossible was spot-on. Can
> you please try the below hack please and grab dmesg? Hopefully the kernel
> won't die any more at least.
Unfortunately the patch doesn't keep my machine from crashing.
image of stack trace: http://imgur.com/CV5ho1B
dmesg: http://pastebin.com/T69SPT3g
it seems that the problem now occurs in drm_atomic_get_connector_state.
(gdb) list *drm_atomic_get_connector_state+0x40
0xff0 is in drm_atomic_get_connector_state (drivers/gpu/drm/drm_atomic.c:652).
647 *
648 * Note that we only grab the indexes once we have the right
lock to
649 * prevent hotplug/unplugging of connectors. So removal is no
problem,
650 * at most the array is a bit too large.
651 */
652 if (index >= state->num_connector) {
653 DRM_DEBUG_ATOMIC("Hot-added connector would overflow
state array, restarting\n");
654 return ERR_PTR(-EAGAIN);
655 }
656
(gdb)
HTH
Nic
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station
> This only contains the pile of WARNINGs and not the Oops itself. I guess
> we still need a picture (and you need to change the system console logging
> to make sure the debug stuff shows up to). At least at the bottom of your
> past there's from drm or i915, indicating that the crucial debug info
> didn't make it out before the machine died.
Ok, I've set CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7 to squeeze some more debug info
out of the kernel. For the OOPS I still have to take a picture since kdump
seems to be broken for me.
http://pastebin.com/9mxRgNa2
> I just want the decoded address (which I read from the oops, if you
> recompile the kernel it might have changed so please double check). I.e.
> the above two lines is all the howto you need. But please use "list"
> instead of "break" as Chris suggested.
Gotcha!
gdb) list *drm_atomic_helper_check_modeset+0x2c5
0x955 is in drm_atomic_helper_check_modeset
(drivers/gpu/drm/drm_atomic_helper.c:235).
230 }
231
232 connector_state->best_encoder = new_encoder;
233 idx = drm_crtc_index(connector_state->crtc);
234
235 crtc_state = state->crtc_states[idx];
236 crtc_state->mode_changed = true;
237
238 DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d]\n",
239 connector->base.id,
(gdb)
Address drm_atomic_helper_check_modeset+0x2c5/0x990 is the first line in the
call trace.
One more thing: When I fire up X BEFORE I connect to the docking there are no
OOPSES and I can switch between DP/eDP. As soon as I kill X however my machine
dies.
HTH.
Regards
Nic
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station
> Two things: > - Can you please boot with drm.debug=0xff and enable full debug output > to the console with dmesg -n debug and try to recapture? I'd like to > know what exactly happened right before. There should be lots of debug > output right before the oops. There ya go. dmesg with drm.debug=0xff right to the point where I plugin to my dock and the driver dies: http://pastebin.com/0mWxZ1Nr > - Can you please decode a few symbols: > gdb drivers/gpu/drm/drm_atomic_helper.c > (gdb) break *drm_atomic_helper_check_modeset+0x2c5 I've never tried to debug a kernel module. You know a good howto? ;) Cheers Nic Gesendet: Mittwoch, 20. Mai 2015 um 18:39 Uhr Von: "Daniel Vetter" An: "Nicolas Kalkhof" Cc: intel-gfx Betreff: Re: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station On Wed, May 20, 2015 at 6:00 PM, Nicolas Kalkhof wrote: > Hi Daniel, > > ok here is the first oops showing up on the screen. Image is not too good > though. http://imgur.com/O0kutIE > > Btw. did you take a look at the stacktrace I've posted below complaining > about complaining about pipe state doesn't match? Two things: - Can you please boot with drm.debug=0xff and enable full debug output to the console with dmesg -n debug and try to recapture? I'd like to know what exactly happened right before. There should be lots of debug output right before the oops. - Can you please decode a few symbols: gdb drivers/gpu/drm/drm_atomic_helper.c (gdb) break *drm_atomic_helper_check_modeset+0x2c5 Please also paste around that line and indicate which one it is (since that always moves around). Thanks, Daniel > Gesendet: Mittwoch, 20. Mai 2015 um 17:38 Uhr > Von: "Daniel Vetter" > An: "Nicolas Kalkhof" > Cc: intel-gfx > Betreff: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking > Station > On Wed, May 20, 2015 at 5:05 PM, Nicolas Kalkhof wrote: >> Hallo, >> >> I'm still getting oops with drm-intel-nightly when I try to connect my >> Laptop to its docking station or when I boot up and the Laptop is already >> connected. >> >> kdump doesn't seem to work with current drm-intel-nightly so I've attached >> an Image (sorry for the bad quality). >> http://imgur.com/463ZQny[http://imgur.com/463ZQny] > > Looks like the culprit has already scrolled off the screen and the > oops you've captured is just follow-up fallout. Can you try booting > with pause_on_oops=60 and try to capture the very first oops? > > Thanks, Daniel > >> >> >> My system boots up without Kernel Panic when NOT connected to dock. However >> dmesg still reveals a problem: >> >> [ 20.137622] [drm:intel_connector_check_state] [CONNECTOR:33:eDP-1] >> [ 20.137625] [drm:check_encoder_state] [ENCODER:31:DAC-31] >> [ 20.137626] [drm:check_encoder_state] [ENCODER:32:TMDS-32] >> [ 20.137627] [drm:check_encoder_state] [ENCODER:40:TMDS-40] >> [ 20.137628] [drm:check_encoder_state] [ENCODER:42:DP MST-42] >> [ 20.137629] [drm:check_encoder_state] [ENCODER:43:DP MST-43] >> [ 20.137629] [drm:check_encoder_state] [ENCODER:44:DP MST-44] >> [ 20.137630] [drm:check_encoder_state] [ENCODER:47:TMDS-47] >> [ 20.137630] [drm:check_encoder_state] [ENCODER:49:DP MST-49] >> [ 20.137631] [drm:check_encoder_state] [ENCODER:50:DP MST-50] >> [ 20.137631] [drm:check_encoder_state] [ENCODER:51:DP MST-51] >> [ 20.137632] [drm:check_crtc_state] [CRTC:20] >> [ 20.137640] [drm:check_crtc_state] *ERROR* mismatch in dpll_hw_state.wrpll >> (expected 0x90280202, found 0x) >> [ 20.137641] [ cut here ] >> [ 20.137643] WARNING: CPU: 0 PID: 1086 at >> drivers/gpu/drm/i915/intel_display.c:12114 check_crtc_state+0x8a5/0xfc0() >> [ 20.137643] pipe state doesn't match! >> [ 20.137644] Modules linked in: snd_hda_codec_realtek snd_hda_codec_hdmi >> snd_hda_codec_generic iwlmvm iwlwifi snd_hda_intel snd_hda_codec >> snd_hda_core snd_pcm snd_timer >> [ 20.137651] CPU: 0 PID: 1086 Comm: X Tainted: G W 4.1.0-rc4+ #5 >> [ 20.137652] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW >> (2.31 ) 01/27/2015 >> [ 20.137652] 817c5f10 81645beb >> 880406cb7878 >> [ 20.137654] 81047047 880409d87000 88040be64000 >> 88040bf7 >> [ 20.137655] 0001 88040be64340 810470c5 >> 817f43d3 >> [ 20.137657] Call Trace: >> [ 20.137660] [] ? dump_stack+0x40/0x50 >> [ 20.137663] [] ? warn_slowpath_common+0x77/0xb0 >> [ 20.137665] [] ? warn_slowpath_fmt+0x45/0x50 >> [ 20.137666] [] ? check_crtc_state+
Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station
Hi Daniel, ok here is the first oops showing up on the screen. Image is not too good though. http://imgur.com/O0kutIE Btw. did you take a look at the stacktrace I've posted below complaining about complaining about pipe state doesn't match? Regards Nic Gesendet: Mittwoch, 20. Mai 2015 um 17:38 Uhr Von: "Daniel Vetter" An: "Nicolas Kalkhof" Cc: intel-gfx Betreff: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station On Wed, May 20, 2015 at 5:05 PM, Nicolas Kalkhof wrote: > Hallo, > > I'm still getting oops with drm-intel-nightly when I try to connect my Laptop > to its docking station or when I boot up and the Laptop is already connected. > > kdump doesn't seem to work with current drm-intel-nightly so I've attached an > Image (sorry for the bad quality). http://imgur.com/463ZQny Looks like the culprit has already scrolled off the screen and the oops you've captured is just follow-up fallout. Can you try booting with pause_on_oops=60 and try to capture the very first oops? Thanks, Daniel > > > My system boots up without Kernel Panic when NOT connected to dock. However > dmesg still reveals a problem: > > [ 20.137622] [drm:intel_connector_check_state] [CONNECTOR:33:eDP-1] > [ 20.137625] [drm:check_encoder_state] [ENCODER:31:DAC-31] > [ 20.137626] [drm:check_encoder_state] [ENCODER:32:TMDS-32] > [ 20.137627] [drm:check_encoder_state] [ENCODER:40:TMDS-40] > [ 20.137628] [drm:check_encoder_state] [ENCODER:42:DP MST-42] > [ 20.137629] [drm:check_encoder_state] [ENCODER:43:DP MST-43] > [ 20.137629] [drm:check_encoder_state] [ENCODER:44:DP MST-44] > [ 20.137630] [drm:check_encoder_state] [ENCODER:47:TMDS-47] > [ 20.137630] [drm:check_encoder_state] [ENCODER:49:DP MST-49] > [ 20.137631] [drm:check_encoder_state] [ENCODER:50:DP MST-50] > [ 20.137631] [drm:check_encoder_state] [ENCODER:51:DP MST-51] > [ 20.137632] [drm:check_crtc_state] [CRTC:20] > [ 20.137640] [drm:check_crtc_state] *ERROR* mismatch in dpll_hw_state.wrpll > (expected 0x90280202, found 0x) > [ 20.137641] [ cut here ] > [ 20.137643] WARNING: CPU: 0 PID: 1086 at > drivers/gpu/drm/i915/intel_display.c:12114 check_crtc_state+0x8a5/0xfc0() > [ 20.137643] pipe state doesn't match! > [ 20.137644] Modules linked in: snd_hda_codec_realtek snd_hda_codec_hdmi > snd_hda_codec_generic iwlmvm iwlwifi snd_hda_intel snd_hda_codec snd_hda_core > snd_pcm snd_timer > [ 20.137651] CPU: 0 PID: 1086 Comm: X Tainted: G W 4.1.0-rc4+ #5 > [ 20.137652] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 > ) 01/27/2015 > [ 20.137652] 817c5f10 81645beb > 880406cb7878 > [ 20.137654] 81047047 880409d87000 88040be64000 > 88040bf7 > [ 20.137655] 0001 88040be64340 810470c5 > 817f43d3 > [ 20.137657] Call Trace: > [ 20.137660] [] ? dump_stack+0x40/0x50 > [ 20.137663] [] ? warn_slowpath_common+0x77/0xb0 > [ 20.137665] [] ? warn_slowpath_fmt+0x45/0x50 > [ 20.137666] [] ? check_crtc_state+0x8a5/0xfc0 > [ 20.137668] [] ? ktime_get+0x34/0xb0 > [ 20.137671] [] ? intel_modeset_check_state+0x229/0xb50 > [ 20.137673] [] ? intel_crtc_set_config+0x578/0x650 > [ 20.137675] [] ? drm_mode_set_config_internal+0x5f/0x100 > [ 20.137677] [] ? drm_mode_setcrtc+0x22a/0x5f0 > [ 20.137679] [] ? drm_ioctl+0x15a/0x580 > [ 20.137682] [] ? do_vfs_ioctl+0x2e8/0x4f0 > [ 20.137684] [] ? __do_page_fault+0x17b/0x3e0 > [ 20.137685] [] ? SyS_ioctl+0x36/0x80 > [ 20.137688] [] ? system_call_fastpath+0x16/0x6e > [ 20.137688] ---[ end trace a67764a031b81585 ]--- > > Full dmesg goes here: > http://pastebin.com/fzjnsfyQ[http://pastebin.com/fzjnsfyQ] > > Any Clues? > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx[http://lists.freedesktop.org/mailman/listinfo/intel-gfx] -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch[http://blog.ffwll.ch] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] still experiencing oops connecting Laptop to docking Station
Hallo, I'm still getting oops with drm-intel-nightly when I try to connect my Laptop to its docking station or when I boot up and the Laptop is already connected. kdump doesn't seem to work with current drm-intel-nightly so I've attached an Image (sorry for the bad quality). http://imgur.com/463ZQny My system boots up without Kernel Panic when NOT connected to dock. However dmesg still reveals a problem: [ 20.137622] [drm:intel_connector_check_state] [CONNECTOR:33:eDP-1] [ 20.137625] [drm:check_encoder_state] [ENCODER:31:DAC-31] [ 20.137626] [drm:check_encoder_state] [ENCODER:32:TMDS-32] [ 20.137627] [drm:check_encoder_state] [ENCODER:40:TMDS-40] [ 20.137628] [drm:check_encoder_state] [ENCODER:42:DP MST-42] [ 20.137629] [drm:check_encoder_state] [ENCODER:43:DP MST-43] [ 20.137629] [drm:check_encoder_state] [ENCODER:44:DP MST-44] [ 20.137630] [drm:check_encoder_state] [ENCODER:47:TMDS-47] [ 20.137630] [drm:check_encoder_state] [ENCODER:49:DP MST-49] [ 20.137631] [drm:check_encoder_state] [ENCODER:50:DP MST-50] [ 20.137631] [drm:check_encoder_state] [ENCODER:51:DP MST-51] [ 20.137632] [drm:check_crtc_state] [CRTC:20] [ 20.137640] [drm:check_crtc_state] *ERROR* mismatch in dpll_hw_state.wrpll (expected 0x90280202, found 0x) [ 20.137641] [ cut here ] [ 20.137643] WARNING: CPU: 0 PID: 1086 at drivers/gpu/drm/i915/intel_display.c:12114 check_crtc_state+0x8a5/0xfc0() [ 20.137643] pipe state doesn't match! [ 20.137644] Modules linked in: snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic iwlmvm iwlwifi snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer [ 20.137651] CPU: 0 PID: 1086 Comm: X Tainted: GW 4.1.0-rc4+ #5 [ 20.137652] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 20.137652] 817c5f10 81645beb 880406cb7878 [ 20.137654] 81047047 880409d87000 88040be64000 88040bf7 [ 20.137655] 0001 88040be64340 810470c5 817f43d3 [ 20.137657] Call Trace: [ 20.137660] [] ? dump_stack+0x40/0x50 [ 20.137663] [] ? warn_slowpath_common+0x77/0xb0 [ 20.137665] [] ? warn_slowpath_fmt+0x45/0x50 [ 20.137666] [] ? check_crtc_state+0x8a5/0xfc0 [ 20.137668] [] ? ktime_get+0x34/0xb0 [ 20.137671] [] ? intel_modeset_check_state+0x229/0xb50 [ 20.137673] [] ? intel_crtc_set_config+0x578/0x650 [ 20.137675] [] ? drm_mode_set_config_internal+0x5f/0x100 [ 20.137677] [] ? drm_mode_setcrtc+0x22a/0x5f0 [ 20.137679] [] ? drm_ioctl+0x15a/0x580 [ 20.137682] [] ? do_vfs_ioctl+0x2e8/0x4f0 [ 20.137684] [] ? __do_page_fault+0x17b/0x3e0 [ 20.137685] [] ? SyS_ioctl+0x36/0x80 [ 20.137688] [] ? system_call_fastpath+0x16/0x6e [ 20.137688] ---[ end trace a67764a031b81585 ]--- Full dmesg goes here: http://pastebin.com/fzjnsfyQ Any Clues? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make scaler_id check in check_crtc_state work for all gens
Gesendet: Dienstag, 12. Mai 2015 um 08:40 Uhr
Von: "Daniel Vetter"
An: "Chandra Konduru"
Cc: daniel.vet...@intel.com, intel-gfx@lists.freedesktop.org
Betreff: Re: [Intel-gfx] [PATCH] drm/i915: Make scaler_id check in
check_crtc_state work for all gens
On Mon, May 11, 2015 at 02:35:47PM -0700, Chandra Konduru wrote:
> During check_crtc_state, scaler_id mispatch is being reported for HSW.
> This is applicable for skl+ and not for HSW. It is introduced by
> commit id:
> commit a1b2278e4dfcd2dbea85e319ebf73a6b7b2f180b
> Author: Chandra Konduru
> Date: Tue Apr 7 15:28:45 2015 -0700
>
> drm/i915: skylake panel fitting using shared scalers
>
> This patch will make sure that we leave scaler_id as 0 for platforms
> before skl and set for skl+ only. This way scaler_id check during
> check_crtc_state will pass for both prior to skl and skl+ platforms.
>
> v2:
> -Leave scaler_id as 0 for gen < 9 (Daniel)
>
> Signed-off-by: Chandra Konduru
> References:
> http://lists.freedesktop.org/archives/intel-gfx/2015-May/065741.html
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c297cdc..5c9f358 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9351,6 +9351,12 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> }
>
> pfit_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> +
> + if (INTEL_INFO(dev)->gen >= 9) {
> + pipe_config->scaler_state.scaler_id = -1;
> + pipe_config->scaler_state.scaler_users &= ~(1 << SKL_CRTC_INDEX);
> + }
> +
> if (intel_display_power_is_enabled(dev_priv, pfit_domain)) {
> if (INTEL_INFO(dev)->gen == 9)
> skylake_get_pfit_config(crtc, pipe_config);
> @@ -9358,10 +9364,6 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> ironlake_get_pfit_config(crtc, pipe_config);
> else
> MISSING_CASE(INTEL_INFO(dev)->gen);
> -
> - } else {
> - pipe_config->scaler_state.scaler_id = -1;
> - pipe_config->scaler_state.scaler_users &= ~(1 << SKL_CRTC_INDEX);
> }
>
> if (IS_HASWELL(dev))
> @@ -13248,8 +13250,8 @@ static struct drm_plane
> *intel_primary_plane_create(struct drm_device *dev,
> primary->max_downscale = 1;
> if (INTEL_INFO(dev)->gen >= 9) {
> primary->can_scale = true;
> + state->scaler_id = -1;
> }
> - state->scaler_id = -1;
> primary->pipe = pipe;
> primary->plane = pipe;
> primary->check_plane = intel_check_primary_plane;
> @@ -13431,7 +13433,6 @@ static struct drm_plane
> *intel_cursor_plane_create(struct drm_device *dev,
> cursor->max_downscale = 1;
> cursor->pipe = pipe;
> cursor->plane = pipe;
> - state->scaler_id = -1;
> cursor->check_plane = intel_check_cursor_plane;
> cursor->commit_plane = intel_commit_cursor_plane;
> cursor->disable_plane = intel_disable_cursor_plane;
> @@ -13454,6 +13455,9 @@ static struct drm_plane
> *intel_cursor_plane_create(struct drm_device *dev,
> state->base.rotation);
> }
>
> + if (INTEL_INFO(dev)->gen >=9)
> + state->scaler_id = -1;
> +
> drm_plane_helper_add(&cursor->base, &intel_plane_helper_funcs);
>
> return &cursor->base;
> --
> 1.7.9.5
yeah the error message about mismatch in scaler_state.scaler_id is gone with
this commit however intel_display is still broken:
[ 35.159170] [ cut here ]
[ 35.159195] WARNING: CPU: 1 PID: 1314 at
drivers/gpu/drm/i915/intel_display.c:12023
intel_modeset_check_state+0x208/0xb50 [i915]()
[ 35.159197] active encoder's pipe doesn't match(expected 1, found 0)
[ 35.159198] Modules linked in: snd_hda_codec_hdmi i915 fbcon bitblit
snd_hda_codec_realtek cfbfillrect softcursor font cfbimgblt
snd_hda_codec_generic intel_gtt cfbcopyarea drm_kms_helper drm snd_hda_intel fb
iwlmvm fbdev snd_hda_codec snd_hwdep snd_hda_core snd_pcm iwlwifi
[ 35.159222] CPU: 1 PID: 1314 Comm: X Not tainted 4.1.0-rc3+ #11
[ 35.159223] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31
) 01/27/2015
[ 35.159225] a02df138 8155c7ab
88040b097bc8
[ 35.159229] 810451b7 88040bbf6400 88040ba47000
0001
[ 35.159232] 88040ba47340 88040ba47328 81045235
a02e2588
[ 35.159235] Call Trace:
[ 35.159243] [] ? dump_stack+0x40/0x50
[ 35.159248] [] ? warn_slowpath_common+0x77/0xb0
[ 35.159251] [] ? warn_slowpath_fmt+0x45/0x50
[ 35.159264] [] ? intel_modeset_check_state+0x208/0xb50
[i915]
[ 35.159278] [] ? __intel_set_mode+0xa8b/0xcb0 [i915]
[ 35.159291] [] ? intel_crtc_set_config+0x578/0x650 [i915]
[ 35.159303] [] ? drm_crtc_check_viewport+0x27/0xf0 [drm]
[ 35.159312] [] ? drm_mode_set_config_internal+0x5f/0x100
[drm]
[ 35.159321] [] ? drm_mode_setcrtc+0x22a/0x5f0 [drm]
[ 35.159328] [] ? drm_ioctl+0x15a/0x580 [drm]
[ 35.159333] [] ? do_vfs_ioctl+0x2e8/0x4f0
[ 35.159336]
Re: [Intel-gfx] [i915 dp mst] drm-intel-nightly-2015y-05m-11d dies when monitor at docking station
> Yeah that one is busted unfortunately. I've just pushed out a new -nightly > with an updated patch from Maarten: > commit c363376d3d5586c1e99f92969a7a7baf179206d7 > Author: Maarten Lankhorst > Date: Mon May 11 10:45:15 2015 +0200 > drm/i915: Always keep crtc_state->active in sync with enable No Changes here as well. Still getting complete system hang with a black screen when I boot up having my machine docked. Undocked the kernel boots up however i'm getting a bunch of driver crashes: [ 19.139565] [drm:check_crtc_state [i915]] *ERROR* mismatch in scaler_state.scaler_id (expected 0, found -1) [ 19.139566] [ cut here ] [ 19.139573] WARNING: CPU: 1 PID: 1324 at drivers/gpu/drm/i915/intel_display.c:12084 check_crtc_state+0x8a5/0xfc0 [i915]() [ 19.139574] pipe state doesn't match! [ 19.139574] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek i915 snd_hda_codec_generic iwlmvm fbcon bitblit cfbfillrect cfbimgblt softcursor font intel_gtt cfbcopyarea iwlwifi drm_kms_helper drm snd_hda_intel snd_hda_codec fb fbdev snd_hwdep snd_hda_core snd_pcm [ 19.139586] CPU: 1 PID: 1324 Comm: X Not tainted 4.1.0-rc3+ #11 [ 19.139587] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 19.139587] a02b6f78 8155c7ab 88007fb7b958 [ 19.139589] 810451b7 88040ab0d000 88040aea4800 88040b1d [ 19.139591] 0001 88040aea4b40 81045235 a02aba69 [ 19.139592] Call Trace: [ 19.139597] [] ? dump_stack+0x40/0x50 [ 19.139599] [] ? warn_slowpath_common+0x77/0xb0 [ 19.139601] [] ? warn_slowpath_fmt+0x45/0x50 [ 19.139607] [] ? check_crtc_state+0x8a5/0xfc0 [i915] [ 19.139615] [] ? intel_modeset_check_state+0x229/0xb50 [i915] [ 19.139621] [] ? __intel_set_mode+0xa8b/0xcb0 [i915] [ 19.139628] [] ? intel_crtc_set_config+0x578/0x650 [i915] [ 19.139631] [] ? drm_atomic_helper_plane_set_property+0x85/0xd0 [drm_kms_helper] [ 19.139636] [] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 19.139639] [] ? restore_fbdev_mode+0xb9/0xe0 [drm_kms_helper] [ 19.139641] [] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1b/0x60 [drm_kms_helper] [ 19.139647] [] ? intel_fbdev_restore_mode+0x19/0x50 [i915] [ 19.139650] [] ? drm_lastclose+0x28/0x140 [drm] [ 19.139653] [] ? drm_release+0x320/0x520 [drm] [ 19.139655] [] ? __fput+0x97/0x1f0 [ 19.139657] [] ? task_work_run+0xb7/0xf0 [ 19.139660] [] ? int_signal+0x12/0x17 [ 19.139660] ---[ end trace ed3113b3ea35374f ]--- [ 19.139680] [drm:check_crtc_state [i915]] *ERROR* mismatch in scaler_state.scaler_id (expected 0, found -1) [ 19.139681] [ cut here ] [ 19.139687] WARNING: CPU: 1 PID: 1324 at drivers/gpu/drm/i915/intel_display.c:12084 check_crtc_state+0x8a5/0xfc0 [i915]() [ 19.139687] pipe state doesn't match! [ 19.139688] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek i915 snd_hda_codec_generic iwlmvm fbcon bitblit cfbfillrect cfbimgblt softcursor font intel_gtt cfbcopyarea iwlwifi drm_kms_helper drm snd_hda_intel snd_hda_codec fb fbdev snd_hwdep snd_hda_core snd_pcm [ 19.139696] CPU: 1 PID: 1324 Comm: X Tainted: GW 4.1.0-rc3+ #11 [ 19.139696] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 19.139697] a02b6f78 8155c7ab 88007fb7b958 [ 19.139699] 810451b7 88040ab0d000 88040aea4800 88040b1d [ 19.139700] 0001 88040aea4b40 81045235 a02aba69 [ 19.139701] Call Trace: [ 19.139703] [] ? dump_stack+0x40/0x50 [ 19.139705] [] ? warn_slowpath_common+0x77/0xb0 [ 19.139706] [] ? warn_slowpath_fmt+0x45/0x50 [ 19.139711] [] ? check_crtc_state+0x8a5/0xfc0 [i915] [ 19.139718] [] ? intel_modeset_check_state+0x229/0xb50 [i915] [ 19.139725] [] ? __intel_set_mode+0xa8b/0xcb0 [i915] [ 19.139731] [] ? intel_crtc_set_config+0x578/0x650 [i915] [ 19.139733] [] ? drm_atomic_helper_plane_set_property+0x85/0xd0 [drm_kms_helper] [ 19.139738] [] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 19.139740] [] ? restore_fbdev_mode+0xb9/0xe0 [drm_kms_helper] [ 19.139742] [] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1b/0x60 [drm_kms_helper] [ 19.139748] [] ? intel_fbdev_restore_mode+0x19/0x50 [i915] [ 19.139751] [] ? drm_lastclose+0x28/0x140 [drm] [ 19.139754] [] ? drm_release+0x320/0x520 [drm] [ 19.139755] [] ? __fput+0x97/0x1f0 [ 19.139756] [] ? task_work_run+0xb7/0xf0 [ 19.139757] [] ? int_signal+0x12/0x17 [ 19.139758] ---[ end trace ed3113b3ea353750 ]--- [ 19.139776] [drm:check_crtc_state [i915]] *ERROR* mismatch in scaler_state.scaler_id (expected 0, found -1) [ 19.139777] [ cut here ] [ 19.139782] WARNING: CPU: 1 PID: 1324 at drivers/gpu/drm/i915/intel_display.c:12084 check_crtc_state+0x8a5/0xfc0 [i915]()
Re: [Intel-gfx] [PATCH] drm/i915: Allocate connector state together with the connectors
Hello, the kernel oops reported back in April (http://lists.freedesktop.org/archives/intel-gfx/2015-April/064066.html) is back resulting in the same oops as soon as I connect my Laptop to its docking station or boot with docking already connected. The issue was introduced again somewhere between commit 79114e880c84257bfe5581a84578e84a79f35bac[http://cgit.freedesktop.org/drm-intel/commit/?id=79114e880c84257bfe5581a84578e84a79f35bac] 2015-05-07 07:33:05 and e6d052f03c23e5d2c29d55d88666a6502fa15c90[http://cgit.freedesktop.org/drm-intel/commit/?id=e6d052f03c23e5d2c29d55d88666a6502fa15c90] 2015-05-07 16:14:32 In between were a lot of drm patches however I currently don't have the time to bisect the code down to the bad commit. Hops this helps to pinpoint somewhere near to the issue??! Regards Gesendet: Montag, 13. April 2015 um 11:24 Uhr Von: "Daniel Vetter" An: "Nicolas Kalkhof" Cc: ander.conselvan.de.olive...@intel.com, intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] [PATCH] drm/i915: Allocate connector state together with the connectors On Sat, Apr 11, 2015 at 08:23:06AM +0200, Nicolas Kalkhof wrote: > Hello, > > it seems I got kicked off Cc. Anyway I can confirm that the supplied > patch works an I can hotplug to my docking station and switch between > DP/eDP without Oops. :) Thanks for the test feedback, patch applied. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch[http://blog.ffwll.ch] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allocate connector state together with the connectors
Hello, it seems I got kicked off Cc. Anyway I can confirm that the supplied patch works an I can hotplug to my docking station and switch between DP/eDP without Oops. :) Thanks for the swift help! Kind Regards ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: drm locks up when connecting laptop to docking station
> Which branch are you exactly using - we added calls to this function in > i915 only for the 4.1 -next branch, but you claim that you're running > 4.0-rc kernels ... > -Daniel I'm using the latest drm-intel-nightly from git://anongit.freedesktop.org/drm-intel. I've observed ths issue at some point after merging 4.0-rc4 into drm-intel-nightly (sorry don't remember a date or specific commit) and my machine still locks up with current drm-intel-nightly git. Hope this helps. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: drm locks up when connecting laptop to docking station
Hello, since late 4.0-rc4 / early4.0-rc5 drm-intel branch I'm experiencing lockups every time I try to connect my lenovo t440p laptop to its docking station. [ 143.896172] [ cut here ] [ 143.896182] WARNING: CPU: 0 PID: 1102 at drivers/gpu/drm/drm_atomic_helper.c:2204 drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper]() [ 143.896184] Modules linked in: snd_hda_codec_hdmi i915 snd_hda_codec_realtek snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_controller i2c_algo_bit drm_kms_helper snd_hda_codec drm iwlwifi snd_hwdep snd_pcm intel_gtt snd_timer thinkpad_acpi agpgart snd_hda_core [ 143.896201] CPU: 0 PID: 1102 Comm: X Not tainted 4.0.0-rc7-01086-g91d1586 #1 [ 143.896202] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 143.896203] a0171420 81590365 [ 143.896206] 81043617 fff4 8804098d7d80 8800c9cd3000 [ 143.896209] 0006 8800c9c7a800 a016bf05 [ 143.896212] Call Trace: [ 143.896219] [] ? dump_stack+0x40/0x50 [ 143.896223] [] ? warn_slowpath_common+0x77/0xb0 [ 143.896228] [] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.896235] [] ? drm_atomic_get_connector_state+0x95/0x110 [drm] [ 143.896252] [] ? intel_crtc_set_config+0xc6f/0xfb0 [i915] [ 143.896258] [] ? ep_poll_callback+0xeb/0x120 [ 143.896264] [] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.896273] [] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.896281] [] ? drm_mode_setcrtc+0x22a/0x5f0 [drm] [ 143.896288] [] ? drm_ioctl+0x15a/0x580 [drm] [ 143.896292] [] ? pick_next_task_fair+0x43f/0x4b0 [ 143.896295] [] ? do_vfs_ioctl+0x2e8/0x4f0 [ 143.896298] [] ? __schedule+0x24d/0x7c0 [ 143.896301] [] ? SyS_ioctl+0x36/0x80 [ 143.896303] [] ? SyS_poll+0x52/0xf0 [ 143.896307] [] ? system_call_fastpath+0x16/0x1b [ 143.896309] ---[ end trace 17ff49bc79a1a762 ]--- [ 143.896318] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 143.896362] IP: [] drm_atomic_add_affected_connectors+0x64/0xc0 [drm] [ 143.896403] PGD 406577067 PUD 408c42067 PMD 0 [ 143.896426] Oops: [#1] SMP [ 143.896439] Modules linked in: snd_hda_codec_hdmi i915 snd_hda_codec_realtek snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_controller i2c_algo_bit drm_kms_helper snd_hda_codec drm iwlwifi snd_hwdep snd_pcm intel_gtt snd_timer thinkpad_acpi agpgart snd_hda_core [ 143.896584] CPU: 0 PID: 1102 Comm: X Tainted: GW 4.0.0-rc7-01086-g91d1586 #1 [ 143.896619] Hardware name: LENOVO ENX407/ENX407, BIOS GLET77WW (2.31 ) 01/27/2015 [ 143.896654] task: 88040652b1e0 ti: 880409a9 task.ti: 880409a9 [ 143.896686] RIP: 0010:[] [] drm_atomic_add_affected_connectors+0x64/0xc0 [drm] [ 143.896738] RSP: 0018:880409a93b18 EFLAGS: 00010283 [ 143.896759] RAX: RBX: 8800c9cd3000 RCX: 88040af8ec00 [ 143.896789] RDX: 88040a603e20 RSI: 880408d916a8 RDI: 88040af8eea8 [ 143.896819] RBP: 8800c9c7ab28 R08: 00015700 R09: 880409a93c30 [ 143.896849] R10: 88040dc01500 R11: a00ef362 R12: 88040c38d000 [ 143.896878] R13: 8804098d7d80 R14: 880409a93c34 R15: 88040c38d000 [ 143.896909] FS: 7f13fb95f8c0() GS:88041e20() knlGS: [ 143.896943] CS: 0010 DS: ES: CR0: 80050033 [ 143.896966] CR2: 0008 CR3: 00040bbd7000 CR4: 001406f0 [ 143.896995] Stack: [ 143.897000] 0006 8800c9c7a800 880409a93c30 8804098d7d80 [ 143.897037] a034c0ac 880409a93c2c [ 143.897074] 000c a0171420 089c [ 143.897112] Call Trace: [ 143.897131] [] ? intel_modeset_compute_config+0x3c/0x1090 [i915] [ 143.897166] [] ? printk+0x48/0x4d [ 143.897196] [] ? intel_set_mode+0x39/0xa0 [i915] [ 143.897225] [] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.897272] [] ? drm_atomic_state_clear+0xb2/0x180 [drm] [ 143.897311] [] ? intel_crtc_set_config+0xa1d/0xfb0 [i915] [ 143.897343] [] ? ep_poll_callback+0xeb/0x120 [ 143.897372] [] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.897409] [] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.897447] [] ? drm_mode_setcrtc+0x22a/0x5f0 [drm] [ 143.897479] [] ? drm_ioctl+0x15a/0x580 [drm] [ 143.897505] [] ? pick_next_task_fair+0x43f/0x4b0 [ 143.897532] [] ? do_vfs_ioctl+0x2e8/0x4f0 [ 143.897557] [] ? __schedule+0x24d/0x7c0 [ 143.897580] [] ? SyS_ioctl+0x36/0x80 [ 143.897602] [] ? SyS_poll+0x52/0xf0 [ 143.897625] [] ? system_call_fastpath+0x16/0x1b [ 143.897650] Code: c5 28 03 00 00 48 8d 58 e8 48 39 c5 75 16 eb 47 0f 1f 80 00 00 00 00 48 8b 43 18 48 8d 58 e8 48 39 c5 74 33 48 8
Re: [Intel-gfx] drm/i915: Enabling PC8 on Haswell
On Thu, Dec 26, 2013 at 02:46:18PM -0800, Paulo Zanoni wrote: > As far as I could check, your PCI ID is 0416, so your machine is not > ULT. As far as I know, your machine supports only up to PC7 state. I > may be wrong. Still, I will provide some comments below: You are right, my machine is not ULT. I suppose PC8 only works on ULT CPUs, correct? > To get into Pacakge C8 and deeper states you need all screens to be > disabled. You mentioned X is not running, so what exactly did you do > to disable all the screens? Nohting I just logged in from the console with no X running. So all connected screens have to be disabled for the device to reach PC8 state? > This means: either one or more screens are enabled, or the power well > is enabled, or both. Yeah, power well was enabled by mistake. disabled it but no changes. >> GPU idle: no > Something is submitting work to the GPU. No idea what that could be. > Did you go to the "tunables" tab and switch everything to "good"? All > devices (not only graphics) need to be properly configured for the > machine to reach PC8+. Yeah everything is "good" and still the haswell system is draining 16-18 Watts with no X and no discrete graphics present. That's what puzzels me. Running the exact same Linux/Kernel Configon a Sandy Bridge i7-2620M the power drain is approx 7-8 Watts with power save turned for all tunables. For Haswell powertop shows nice idle states exept the PC states stay at pc2/pc3 and never reach pc7 while Sandy bridge reaches pc7 most of the time. >> Kernel is 3.13-rc4 from ~danvet/drm-intel/drm-intel-nightly >> Params are: i915.i915_enable_rc6=1 pcie_aspm=force >> i915.i915_disable_power_well=0 i915.enable_pc8=1 "acpi_osi=!Windows 2012" >> acpi_backlight=legacy > Why are you using all these options for i915? We recommend to stick to > the defaults since they are the best bug-free setup. Well, the pcie_aspm=force switch reduces power drain approx 4-5 Watts and the other acpi options need to be there for the keyboard/backlight to word. I've already removed the i915 params without effect. Thanks and Regards Nic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: Enabling PC8 on Haswell
Sorry, last post got html infected! Hello, I've been trying to enable PC8 on my Haswell i7-4600M Notebook but i'm not sure if it is working properly. During idle states (No X running) 915_pc8_status tells me that PC8 seems to be disabled: Requirements met: no GPU idle: no Disable count: 3 IRQs disabled: no Enabled: no Is this supposed to be right? Powertop 2.5 reports that Package C-States never go above pc3 while Core C7-HSW and GPU RC6 states are always reached with > 90%. Package | Core | CPU 0 | | C0 active 0.7% | | POLL 0.0% 0.0 ms | | C1E-HSW 0.9% 1.3 ms C2 (pc2) 90.8% | | C3 (pc3) 0.0% | C3 (cc3) 0.4% | C3-HSW 0.4% 0.4 ms C6 (pc6) 0.0% | C6 (cc6) 0.0% | C6-HSW 0.0% 0.0 ms C7 (pc7) 0.0% | C7 (cc7) 97.1% | C7s-HSW 97.5% 5.8 ms | Core | CPU 1 | | C0 active 0.8% | | POLL 0.0% 0.0 ms | | C1E-HSW 0.0% 0.0 ms | | | C3 (cc3) 0.1% | C3-HSW 0.1% 0.3 ms | C6 (cc6) 0.0% | C6-HSW 0.0% 0.0 ms | C7 (cc7) 92.0% | C7s-HSW 92.3% 12.0 ms | GPU | | | | Powered On 0.6% | | RC6 99.4% | | RC6p 0.0% | Kernel is 3.13-rc4 from ~danvet/drm-intel/drm-intel-nightly Params are: i915.i915_enable_rc6=1 pcie_aspm=force i915.i915_disable_power_well=0 i915.enable_pc8=1 "acpi_osi=!Windows 2012" acpi_backlight=legacy dmesg goes here: http://pastebin.ca/2516591 Any ideas? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: Enabling PC8 on Haswell
Hello, I've been trying to enable PC8 on my Haswell i7-4600M Notebook but i'm not sure if it is working properly. During idle states (No X running) 915_pc8_status tells me that PC8 seems to be disabled: Requirements met: no GPU idle: no Disable count: 3 IRQs disabled: no Enabled: no Is this supposed to be right? Powertop 2.5 reports that Package C-States never go above pc3 while Core C7-HSW and GPU RC6 states are always reached with > 90%. Package | Core | CPU 0 | | C0 active 0.7% | | POLL 0.0% 0.0 ms | | C1E-HSW 0.9% 1.3 ms C2 (pc2) 90.8% | | C3 (pc3) 0.0% | C3 (cc3) 0.4% | C3-HSW 0.4% 0.4 ms C6 (pc6) 0.0% | C6 (cc6) 0.0% | C6-HSW 0.0% 0.0 ms C7 (pc7) 0.0% | C7 (cc7) 97.1% | C7s-HSW 97.5% 5.8 ms | Core | CPU 1 | | C0 active 0.8% | | POLL 0.0% 0.0 ms | | C1E-HSW 0.0% 0.0 ms | | | C3 (cc3) 0.1% | C3-HSW 0.1% 0.3 ms | C6 (cc6) 0.0% | C6-HSW 0.0% 0.0 ms | C7 (cc7) 92.0% | C7s-HSW 92.3% 12.0 ms | GPU | | | | Powered On 0.6% | | RC6 99.4% | | RC6p 0.0% | Kernel is 3.13-rc4 from ~danvet/drm-intel/drm-intel-nightly. Params are: i915.i915_enable_rc6=1 pcie_aspm=force i915.i915_disable_power_well=0 i915.enable_pc8=1 "acpi_osi=!Windows 2012" acpi_backlight=legacy dmesg goes here: http://pastebin.ca/2516591 Any ideas? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches
Hi Daniel,ok fixing cpu freq static to max (2700MHz) on both cores does increase performance a little bit however gpu freq reported by /sys/class/drm/card0/gt_cur_freq_mhz stays fixed at 650 MHz.
-Nic
Gesendet: Freitag, 14. September 2012 um 18:44 Uhr
Von: "Daniel Vetter"
An: "Nicolas Kalkhof"
Cc: intel-gfx@lists.freedesktop.org
Betreff: Re: [Intel-gfx] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches
On Fri, Sep 14, 2012 at 06:23:59PM +0200, Nicolas Kalkhof wrote:
> Hello,
>
> the patchset from ~danvet/drm-intel git from earlier september concerning
> forcewake and gpu frequency made my SNB much calmer during idle times. However
> the GPU won't hit the turbo throttle when the load goes up resulting in very
> low framerates during gameplay. Most times the frequency read from /sys/class/
> drm/card0/gt_cur_freq_mhz is stuck to the lowest frequency.
>
> Sysfs yields the following during load spikes:
>
> i915_gen6_forcewake_count: 1
>
> i915_cur_delayinfo:
> GT_PERF_STATUS: 0x0d8a
> RPSTAT1: 0x00040d00
> Render p-state ratio: 13
> Render p-state VID: 138
> Render p-state limit: 255
> CAGF: 650MHz
> RP CUR UP EI: 18814us
> RP CUR UP: 10217us
> RP PREV UP: 43514us
> RP CUR DOWN EI: 0us
> RP CUR DOWN: 0us
> RP PREV DOWN: 0us
> Lowest (RPN) frequency: 650MHz
> Nominal (RP1) frequency: 650MHz
> Max non-overclocked (RP0) frequency: 1300MHz
>
> sensors:
> acpitz-virtual-0
> Adapter: Virtual device
> temp1:+62.0 C (crit = +98.0 C)
> coretemp-isa-
> Adapter: ISA adapter
> Physical id 0: +63.0 C (high = +86.0 C, crit = +100.0 C)
> Core 0: +63.0 C (high = +86.0 C, crit = +100.0 C)
> Core 1: +63.0 C (high = +86.0 C, crit = +100.0 C)
>
> /sys/class/drm/card0/gt_cur_freq_mhz: 650
> /sys/class/drm/card0/gt_max_freq_mhz: 1300
> /sys/class/drm/card0/gt_min_freq_mhz: 650
>
> Kernel Params: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1
> i915.lvds_downclock=1
>
> Setting /sys/class/drm/card0/gt_min_freq_mhz to 1300MHz manually fixes the
> throttling issue however the gpu obviously won't throttle back then.
>
> Any ideas/clues?
One issue we know about is when both gpu/cpu aren't 100% busy the tuning
can get into a death-spiral where we clock down the gpu a bit. Which then
makes the cpu less busy (since in needs to wait more on the gpu),
resulting in the cpu getting downclocked. Which in turn makes the gpu less
busy ...
To check whether it's not this case, can you benchmark with the cpu
frequency fixed to the maximum?
Since things previously worked with the old tuning values I don't think
it's an issue with the up clocking code itself.
-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
[Intel-gfx] i915/drm: SNB gpu won't throttle up with latest forcewake/gpufreq tracepoint drm patches
Hello,the patchset from ~danvet/drm-intel git from earlier september concerning forcewake and gpu frequency made my SNB much calmer during idle times. However the GPU won't hit the turbo throttle when the load goes up resulting in very low framerates during gameplay. Most times the frequency read from /sys/class/drm/card0/gt_cur_freq_mhz is stuck to the lowest frequency.Sysfs yields the following during load spikes:i915_gen6_forcewake_count: 1i915_cur_delayinfo:GT_PERF_STATUS: 0x0d8aRPSTAT1: 0x00040d00Render p-state ratio: 13Render p-state VID: 138Render p-state limit: 255CAGF: 650MHzRP CUR UP EI: 18814usRP CUR UP: 10217usRP PREV UP: 43514usRP CUR DOWN EI: 0usRP CUR DOWN: 0usRP PREV DOWN: 0usLowest (RPN) frequency: 650MHzNominal (RP1) frequency: 650MHzMax non-overclocked (RP0) frequency: 1300MHzsensors:acpitz-virtual-0Adapter: Virtual devicetemp1: +62.0 C (crit = +98.0 C)coretemp-isa-Adapter: ISA adapterPhysical id 0: +63.0 C (high = +86.0 C, crit = +100.0 C)Core 0: +63.0 C (high = +86.0 C, crit = +100.0 C)Core 1: +63.0 C (high = +86.0 C, crit = +100.0 C)/sys/class/drm/card0/gt_cur_freq_mhz: 650/sys/class/drm/card0/gt_max_freq_mhz: 1300/sys/class/drm/card0/gt_min_freq_mhz: 650Kernel Params: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1Setting /sys/class/drm/card0/gt_min_freq_mhz to 1300MHz manually fixes the throttling issue however the gpu obviously won't throttle back then.Any ideas/clues?Best regards,Nic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
Hi Daniel, no problem :). Your patches look good! No hangs or stalls so far with semaphores and rc6 switched on. However I had to disable intel_iommu since it freezes my box shortly after firing up X :(. One other thing still remains: Since the merges for kernel 3.2 came in late october, my cpu/gpu seems to run hotter (approx 10 °C) when idling and after some minutes the cpu load goes up on all cores but the cpu frequency stays low (800 MHz) as well as the gpu (650MHz) and the system is responding well. Yet still additional 5-8 watts are drained from the power supply. Something has to throttle up :(. Oprofile shows that the kernel somewhere hogs the cpu (see dump below). This happens with every kernel from 3.1 up to latest linux-next. I wasn't able to track the bug down yet so I guess I'll better file a bug report on lkml to get someone to verify this. Regards Nic CPU: Intel Sandy Bridge microarchitecture, speed 2.701e+06 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 10 CPU_CLK_UNHALT...| samples| %| -- 2195235 99.7680 vmlinux 3485 0.1584 oprofiled 478 0.0217 libc-2.13.so 393 0.0179 cfbimgblt 221 0.0100 libcrypt-2.13.so 123 0.0056 libncursesw.so.5.9 99 0.0045 iwlwifi 63 0.0029 bash 57 0.0026 cfbfillrect 39 0.0018 bitblit 37 0.0017 ld-2.13.so 27 0.0012 fbcon 25 0.0011 htop 18 8.2e-04 e1000e 10 4.5e-04 acpid 5 2.3e-04 softcursor 4 1.8e-04 fb 4 1.8e-04 i915 3 1.4e-04 libncurses.so.5.9 2 9.1e-05 grep 2 9.1e-05 login 2 9.1e-05 libpam.so.0.83.1 2 9.1e-05 wpa_supplicant 1 4.5e-05 libnss_compat-2.13.so 1 4.5e-05 pam_access.so 1 4.5e-05 wpa_cli 1 4.5e-05 libglib-2.0.so.0.3000.2 1 4.5e-05 libsyslog-ng.so.0.0.0 -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 17, 2011 10:22:07 AM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default >Oops, sorry for wasting your time, wrong branch. Can you try the >for-poland one? And also please try what happens when enabling the >iommu. > >Thanks, Daniel > >On Thu, Nov 17, 2011 at 09:57, Nicolas Kalkhof wrote: >> Daniel, >> >> your ppgtt branch commit hardlocks my machine (SNB Mobile GT2+) as soon as I >> fire up X with a black screen. No crashdumps/syslogs :( Kernel params are: >> intel_iommu=off pcie_aspm=force i915.i915_enable_rc6=1. neither >> i915.semaphores=1 changes that nor does dmesg yield anything fancy. >> >> Regards, >> Nic >> >> >> -Ursprüngliche Nachricht- >> Von: "Daniel Vetter" >> Gesendet: Nov 16, 2011 10:14:18 PM >> An: "Nicolas Kalkhof" >> Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by >> default >> >>>On Wed, Nov 16, 2011 at 21:56, Nicolas Kalkhof wrote: >>>> Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when >>>> decoding videos (vaapi) and running OpenGL apps/games at the same time. >>>> Disabling iommu makes my system relatively stable even with rc6 enabled. I >>>> haven't played with the semaphores however. >>> >>>Can you please try my ppgtt branch from my fdo repo at >>>http://cgit.freedesktop.org/~danvet/drm/ ? Note thought that it'll >>>only work on snb/ivb and that suspend/resume is broken. Also, it won't >>>properly re-enable ppgtt when resetting the gpu after a hang. >>>But testing feedback highly appreciated. >>> >>>Thanks, Daniel >>>-- >>>Daniel Vetter >>>daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> >> >> ___ >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 >> > > > >-- >Daniel Vetter >daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
Daniel, your ppgtt branch commit hardlocks my machine (SNB Mobile GT2+) as soon as I fire up X with a black screen. No crashdumps/syslogs :( Kernel params are: intel_iommu=off pcie_aspm=force i915.i915_enable_rc6=1. neither i915.semaphores=1 changes that nor does dmesg yield anything fancy. Regards, Nic -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 16, 2011 10:14:18 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default >On Wed, Nov 16, 2011 at 21:56, Nicolas Kalkhof wrote: >> Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when >> decoding videos (vaapi) and running OpenGL apps/games at the same time. >> Disabling iommu makes my system relatively stable even with rc6 enabled. I >> haven't played with the semaphores however. > >Can you please try my ppgtt branch from my fdo repo at >http://cgit.freedesktop.org/~danvet/drm/ ? Note thought that it'll >only work on snb/ivb and that suspend/resume is broken. Also, it won't >properly re-enable ppgtt when resetting the gpu after a hang. >But testing feedback highly appreciated. > >Thanks, Daniel >-- >Daniel Vetter >daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when decoding videos (vaapi) and running OpenGL apps/games at the same time. Disabling iommu makes my system relatively stable even with rc6 enabled. I haven't played with the semaphores however. -- Nic -Ursprüngliche Nachricht- Von: "Andrew Lutomirski" Gesendet: Nov 16, 2011 6:24:54 PM An: "Keith Packard" Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default >On Wed, Nov 16, 2011 at 9:16 AM, Keith Packard wrote: >> On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter >> wrote: >> >>> So we need to check whether DMAR is enabled (on the >>> entire system, i.e. the variable exported for the ilk workaround is >>> not good enough) >> >> Can you figure out what *would* be sufficient? Getting semaphores turned >> on for the 99% who aren't enabling VT-d would be a fairly nice >> performance improvement. > >AFAICT my snb laptop has always been stable with semaphores and VT-d >enabled. Is this problem possibly restricted to just desktop >machines? I'm happy to test, since my box that can reproduce the hang >instantly is still around. > >Also, rc6-by-default would be very nice. It decreases the total power >consumption on my laptop from over 13W to around 8W. That's huge. > >--Andy >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Daniel, Bisecting the kernel proved a little time consuming ;) however with the very latest linux.git anf xf86-video-intel the cpu load doesn't seem to go up accodring to top. What I can see is that the SNB draws approx 10-15 watts more when my system is completely idle. My first thought was that rc6 is being disabled but i915_enable_rc6 reports 1. Is there a way I can monitor the gpu frequency or its current power state? Nic -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 7, 2011 7:36:28 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock >On Mon, Nov 07, 2011 at 07:14:35PM +0100, Nicolas Kalkhof wrote: >> ok here is the sysprof result (see below). No cpu/gpu intensive apps are >> running, just the idling desktop. CPU Temperature is low and frequency >> is throttled down to 800 MHz like it should be. The System is responsive >> and behaves normal but top shows full cpu load. Honestly I cannot see >> the reason why X and gkrellm should eat up all the gpu since they >> clearly don't hog the cpu. Maybe the kernel reports wrong cpu stats? >> Then again the load goes down when I kill X! Hope this gives you a clue. > >On a quick look it seems that at least X is busy-spinning in the select >loop and gkrellm seems to be eqally busy doing not much. Have you tried >what happens when you kill gkrellm? > >Otherwise I think it's time for a bit of bisecting. >-Daniel >-- >Daniel Vetter >Mail: dan...@ffwll.ch >Mobile: +41 (0)79 365 57 48 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
r/1:0] 0.00% 0.15% [/usr/bin/wpa_cli] 0.00% 0.15% -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 7, 2011 5:56:38 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock >On Mon, Nov 07, 2011 at 05:39:44PM +0100, Nicolas Kalkhof wrote: >> Hi Daniel, >> >> confirmed. Linus's linux-next.git shows the same behaviour. Until now >> I've used a patched 3.1-rc-6+ Kernel from Dave Airlie's branch >> (git://people.freedesktop.org/~airlied/linux' from Oct 26th.). >> dmesg/syslog shows nothing special, neither does i915_error_state. >> >> Any advice? > >If the behaviour-difference is clear, you could try to bisect this. The >alternative is to use your favourite system profiler and see where the >cycles get wasted (either sysprof or perf). I suggest you'll try whatever >approach your more familiar with first and then switch over to the other >if the first one doesn't yield any clear results. If the difference is >really clear, I'd start with the bisect (aside: don't restrict the bisect >to any subdir, the change causing the regression could equally likely be >somewhere in the core kernel). > >Yours, Daniel >-- >Daniel Vetter >Mail: dan...@ffwll.ch >Mobile: +41 (0)79 365 57 48 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Hi Daniel, Thanks for your Advice. Since it might take some time for the issue to appear I'll try to use a profiler to speed up the bughunt. I don't have any experience in profiling the kernel so this might take some time :( I'll keep you posted. Yours Nic -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 7, 2011 5:56:38 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock >On Mon, Nov 07, 2011 at 05:39:44PM +0100, Nicolas Kalkhof wrote: >> Hi Daniel, >> >> confirmed. Linus's linux-next.git shows the same behaviour. Until now >> I've used a patched 3.1-rc-6+ Kernel from Dave Airlie's branch >> (git://people.freedesktop.org/~airlied/linux' from Oct 26th.). >> dmesg/syslog shows nothing special, neither does i915_error_state. >> >> Any advice? > >If the behaviour-difference is clear, you could try to bisect this. The >alternative is to use your favourite system profiler and see where the >cycles get wasted (either sysprof or perf). I suggest you'll try whatever >approach your more familiar with first and then switch over to the other >if the first one doesn't yield any clear results. If the difference is >really clear, I'd start with the bisect (aside: don't restrict the bisect >to any subdir, the change causing the regression could equally likely be >somewhere in the core kernel). > >Yours, Daniel >-- >Daniel Vetter >Mail: dan...@ffwll.ch >Mobile: +41 (0)79 365 57 48 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Hi Daniel, confirmed. Linus's linux-next.git shows the same behaviour. Until now I've used a patched 3.1-rc-6+ Kernel from Dave Airlie's branch (git://people.freedesktop.org/~airlied/linux' from Oct 26th.). dmesg/syslog shows nothing special, neither does i915_error_state. Any advice? Nic -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 7, 2011 5:05:12 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock >On Mon, Nov 07, 2011 at 02:52:06PM +0100, Nicolas Kalkhof wrote: >> Hi Daniel, >> >> thanks for the git branch. Strange thing is with the patched kernel the >> cpu load goes up after working with my desktop with no obvious reason. >> top shows a high user and system load but no process using up all the >> cpu cores. The cpufreq-daemon clocks the cpu cores down to the minimal >> frequency (800mhz) when idle while top still shows full cpu load but no >> process using up the cpu. The cpu load drops to normal after I kill X >> and immediately goes up again if I restart X. >> >> I'm kinda lost here :( Any Ideas? > >Step one is to check whether -linus master has the same issues. My branch >is based upon > >commit 37be944a0270402f9cda291a930b0286f6dc92f5 >Merge: ca836a2 1717c0e >Author: Linus Torvalds >Date: Fri Oct 28 05:54:23 2011 -0700 > > Merge branch 'drm-core-next' of > git://people.freedesktop.org/~airlied/linux' > >If that doesn't show the same issue, can you please run a bisect (only 13 >commits) to find out which patch introduced this? > >Thanks, Daniel >-- >Daniel Vetter >Mail: dan...@ffwll.ch >Mobile: +41 (0)79 365 57 48 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Hi Daniel, thanks for the git branch. Strange thing is with the patched kernel the cpu load goes up after working with my desktop with no obvious reason. top shows a high user and system load but no process using up all the cpu cores. The cpufreq-daemon clocks the cpu cores down to the minimal frequency (800mhz) when idle while top still shows full cpu load but no process using up the cpu. The cpu load drops to normal after I kill X and immediately goes up again if I restart X. I'm kinda lost here :( Any Ideas? Regards Nic -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Nov 6, 2011 6:46:54 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock >On Sun, Nov 06, 2011 at 06:42:00PM +0100, Nicolas Kalkhof wrote: >> is there a specific git branch availble where I can test your patch? I'm >> also experiencing random forcewake hangs and would like to see if your >> patch helps. > >Please grab the my-next branch from my personal repo: > >http://cgit.freedesktop.org/~danvet/drm/log/?h=my-next > >Yours, Daniel >-- >Daniel Vetter >Mail: dan...@ffwll.ch >Mobile: +41 (0)79 365 57 48 ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Hi Daniel,
is there a specific git branch availble where I can test your patch? I'm also
experiencing random forcewake hangs and would like to see if your patch helps.
Thanks
Nic
-Ursprüngliche Nachricht-
Von: "Daniel Vetter"
Gesendet: Nov 6, 2011 1:35:22 PM
An: intel-gfx
Betreff: [Intel-gfx] [PATCH] drm/i915: protect force_wake_(get|put) with the
gt_lock
>The problem this patch solves is that the forcewake accounting
>necessary for register reads is protected by dev->struct_mutex. But the
>hangcheck and error_capture code need to access registers without
>grabbing this mutex because we hold it while waiting for the gpu.
>So a new lock is required. Because currently the error_state capture
>is called from the error irq handler and the hangcheck code runs from
>a timer, it needs to be an irqsafe spinlock (note that the registers
>used by the irq handler (neglecting the error handling part) only uses
>registers that don't need the forcewake dance).
>
>We could tune this down to a normal spinlock when we rework the
>error_state capture and hangcheck code to run from a workqueue. But
>we don't have any read in a fastpath that needs forcewake, so I've
>decided to not care much about overhead.
>
>This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
>snb on recent kernels - something must have slightly changed the
>timings. On previous kernels it only trigger a WARN about the broken
>locking.
>
>v2: Drop the previous patch for the register writes.
>
>v3: Improve the commit message per Chris Wilson's suggestions.
>
>Signed-Off-by: Daniel Vetter
>---
> drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
> drivers/gpu/drm/i915/i915_dma.c | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 19 +--
> drivers/gpu/drm/i915/i915_drv.h | 10 +++---
> 4 files changed, 27 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>b/drivers/gpu/drm/i915/i915_debugfs.c
>index 5ba63ad..51b21eb 100644
>--- a/drivers/gpu/drm/i915/i915_debugfs.c
>+++ b/drivers/gpu/drm/i915/i915_debugfs.c
>@@ -1320,9 +1320,13 @@ static int i915_gen6_forcewake_count_info(struct
>seq_file *m, void *data)
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> struct drm_device *dev = node->minor->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
>+ unsigned forcewake_count;
>
>- seq_printf(m, "forcewake count = %d\n",
>- atomic_read(&dev_priv->forcewake_count));
>+ spin_lock_irq(&dev_priv->gt_lock);
>+ forcewake_count = dev_priv->forcewake_count;
>+ spin_unlock_irq(&dev_priv->gt_lock);
>+
>+ seq_printf(m, "forcewake count = %d\n", forcewake_count);
>
> return 0;
> }
>diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
>index 2eac955..ab3a3fd 100644
>--- a/drivers/gpu/drm/i915/i915_dma.c
>+++ b/drivers/gpu/drm/i915/i915_dma.c
>@@ -2031,6 +2031,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
>long flags)
> if (!IS_I945G(dev) && !IS_I945GM(dev))
> pci_enable_msi(dev->pdev);
>
>+ spin_lock_init(&dev_priv->gt_lock);
> spin_lock_init(&dev_priv->irq_lock);
> spin_lock_init(&dev_priv->error_lock);
> spin_lock_init(&dev_priv->rps_lock);
>diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>index 548e04b..bab4e08 100644
>--- a/drivers/gpu/drm/i915/i915_drv.c
>+++ b/drivers/gpu/drm/i915/i915_drv.c
>@@ -351,11 +351,12 @@ static void __gen6_gt_force_wake_get(struct
>drm_i915_private *dev_priv)
> */
> void gen6_gt_force_wake_get(struct drm_i915_private *dev_priv)
> {
>- WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
>+ unsigned long irqflags;
>
>- /* Forcewake is atomic in case we get in here without the lock */
>- if (atomic_add_return(1, &dev_priv->forcewake_count) == 1)
>+ spin_lock_irqsave(&dev_priv->gt_lock, irqflags);
>+ if (dev_priv->forcewake_count++ == 0)
> __gen6_gt_force_wake_get(dev_priv);
>+ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags);
> }
>
> static void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
>@@ -369,10 +370,13 @@ static void __gen6_gt_force_wake_put(struct
>drm_i915_private *dev_priv)
> */
> void gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
> {
>- WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
>+ unsigned long irqflags;
>
>- if (atomic_dec_and_test(&dev_priv->forcewake_count))
>+ spin_lock_irqsave(&dev_priv->gt_lock, irqflags);
>+
>+ if (--dev_priv->forcewake_count == 0)
> __gen6_gt_force_wake_put(dev_priv);
>+ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags);
> }
>
> void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
>@@ -603,6 +607,7 @@ int i915_reset(struct drm_device *dev, u8 flags)
> * need to
> */
> bool need_display = true;
>+ unsigned long irqflags;
> int ret;
>
> if (!i915_try_reset)
>@@ -621,8 +626,10 @@ int i915_reset(struct drm_device *dev, u8 flags)
> case 6:
> ret = gen6_do_reset(dev, flags);
> /* If reset with a user forcewake, try to restore */
>- if (atomic_read(&dev_priv->forcewake_count))
>+
Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup
Hi, looks like a known issue with mobile snb chips when rc6 is enabled. Please try to disable rc6 with i915.i915_enable_rc6=0 in your kernel cmd line. This should take care of the wakeup hangs but also causes the gpu to disregard power saving, draining approx 10 watts more from the system. If disabling rc6 makes your system more stable, try the latest kernel drm next branch from Dave Airlie's git: git://people.freedesktop.org/~airlied/linux.git branch:drm-core-next and use the following kernel cmd parameters: intel_iommu=off pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 No Idea if all of these params are effective but this works for me on my lenovo t420 with a i7 2620M. Regards, Nic -Ursprüngliche Nachricht- Von: "James R. Leu" Gesendet: Oct 24, 2011 6:12:21 AM An: intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup >Hello, > >I'm running wow in wine on 64 bit fedora rawhide on a dell vostro 3550 >(i5 with integrated GPU). > >I'm reliably able to produce 2 types of crashes: >- wow freezes, but I can get to text console, in this case I'm able to > grab a kernel stack trace (below) prior to seeing the normal > [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting > 452684 at 452608, next 452686) >- the other is a complete freeze of the system, hard reset required, nothing >logged to /var/log/messages > >Is there any value in me creating a bug report for this, it seems to be a >pretty common issue. >Is there any use in my trying different kernel command line optios for the >i915 driver >or config options to the xorg intel driver? > >I have the various git trees pulled out (I was looking for recent changes that >might be related >to this issue). I'm capable of building and installing from these git trees if >there are specific >bits that I should test. > >Oct 22 20:52:59 localhost kernel: [ 939.830806] [ cut here >] >Oct 22 20:52:59 localhost kernel: [ 939.830814] WARNING: at >drivers/gpu/drm/i915/i915_drv.c:372 gen6_gt_force_wake_put+0x29/0x51 [i915]() >Oct 22 20:52:59 localhost kernel: [ 939.830816] Hardware name: Vostro 3550 >Oct 22 20:52:59 localhost kernel: [ 939.830818] Modules linked in: >snd_seq_dummy fuse ip6table_filter ip6_tables ebtable_nat ebtables xt_state >xt_CHECKSUM iptable_mangle ppdev parport_pc lp parport vboxpci vboxnetadp >vboxnetflt vboxdrv bridge stp llc tun rfcomm bnep ipt_MASQUERADE iptable_nat >nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 snd_hda_codec_hdmi >snd_hda_codec_idt uvcvideo videodev btusb media bluetooth v4l2_compat_ioctl32 >arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm >iwlagn microcode mac80211 dell_laptop iTCO_wdt r8169 i2c_i801 snd_timer >cfg80211 snd mii iTCO_vendor_support dcdbas dell_wmi sparse_keymap soundcore >rfkill snd_page_alloc virtio_net kvm_intel kvm binfmt_misc wmi i915 >drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] >Oct 22 20:52:59 localhost kernel: [ 939.830926] Pid: 0, comm: swapper Tainted: >G WC 3.1.0-0.rc10.git0.1.fc17.x86_64 #1 >Oct 22 20:52:59 localhost kernel: [ 939.830928] Call Trace: >Oct 22 20:52:59 localhost kernel: [ 939.830930] ] >warn_slowpath_common+0x83/0x9b >Oct 22 20:52:59 localhost kernel: [ 939.830941] [] >warn_slowpath_null+0x1a/0x1c >Oct 22 20:52:59 localhost kernel: [ 939.830952] [] >gen6_gt_force_wake_put+0x29/0x51 [i915] >Oct 22 20:52:59 localhost kernel: [ 939.830963] [] >i915_read32+0x44/0x6b [i915] >Oct 22 20:52:59 localhost kernel: [ 939.830975] [] >i915_hangcheck_elapsed+0xe8/0x1f8 [i915] >Oct 22 20:52:59 localhost kernel: [ 939.831027] [] >irq_exit+0x5d/0xcf >Oct 22 20:52:59 localhost kernel: [ 939.831032] [] >smp_apic_timer_interrupt+0x7c/0x8a >Oct 22 20:52:59 localhost kernel: [ 939.831036] [] >apic_timer_interrupt+0x73/0x80 >Oct 22 20:52:59 localhost kernel: [ 939.831038] ] ? >paravirt_read_tsc+0x9/0xd >Oct 22 20:52:59 localhost kernel: [ 939.831046] [] ? >intel_idle+0xe5/0x10c >Oct 22 20:52:59 localhost kernel: [ 939.831050] [] ? >intel_idle+0xe1/0x10c >Oct 22 20:52:59 localhost kernel: [ 939.831054] [] >cpuidle_idle_call+0x11c/0x1fe >Oct 22 20:52:59 localhost kernel: [ 939.831059] [] >cpu_idle+0xab/0x101 >Oct 22 20:52:59 localhost kernel: [ 939.831063] [] >rest_init+0xd7/0xde >Oct 22 20:52:59 localhost kernel: [ 939.831067] [] ? >csum_partial_copy_generic+0x16c/0x16c >Oct 22 20:52:59 localhost kernel: [ 939.831072] [] >start_kernel+0x3dd/0x3ea >Oct 22 20:52:59 localhost kernel: [ 939.831076] [] >x86_64_start_reservations+0xaf/0xb3 >Oct 22 20:52:59 localhost kernel: [ 939.831081] [] ? >early_idt_handlers+0x140/0x140 >Oct 22 20:52:59 localhost kernel: [ 939.831085] [] >x86_64_start_kernel+0x102/0x111 >Oct 22 20:52:59 localhost kernel: [ 939.831088] ---[ end trace >f5cba358bac6b7e5 ]--- > >-- >James R. Leu >j...@mindspring.com
[Intel-gfx] gen6 System freezes When Starting Eclipse using latest xf86-video-intel git (SNA)
Hello, I'm experiencing a total system freeze when I try to start eclipse using the latest xf86-video-intel git with --enable-sna. Older GIT versions (approx 3 days ago) work fine. No debug/syslog output is being produced. Could anyone confirm this issue, please? Regards Nic ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] frequent x crashes with gen6/sna
Hi Daniel, any advice what else to grab besides /sys/kernel/debug/dri/0/i915_error_state and dmesg? after the crash resulting in the forcewake warning (X was gone and I had a completely black screen, had to ssh from a remote machine) the i915_error_state was empty (i.e. no error state collected). Still waiting for the next hang ;). I'll post more debug info asap. Thx and regards, Dieter -Ursprüngliche Nachricht- Von: "Daniel Vetter" Gesendet: Oct 13, 2011 6:24:34 PM An: "Dieter Mummenschanz" Betreff: Re: [Intel-gfx] frequent x crashes with gen6/sna >The attached log shouldn't result in a dead X server - it's the rather >harmless forcewake warning when reading certain debugfs files. Please >grab the next hang. > >Thanks, Daniel > >On Thu, Oct 13, 2011 at 16:55, Dieter Mummenschanz >wrote: >> hi daniel, >> >> roger that. the last x death however was not preceeded by a gpu hang (see >> message log, dmesg.log also attached). Maybe I ran into something different >> than experienced before.No i915_error_state was logged. I remember I ran >> into something similar a couple of days ago and someone provided a patch >> that seemed to work. however I have no idea if the patch has been included >> in the latest Dave's latest drm-next git. >> >> Oct 13 16:40:22 gonzo kernel: WARNING: at >> drivers/gpu/drm/i915/i915_drv.c:354 gen6_gt_force_wake_get+0x1f/0x3c [i915]() >> Oct 13 16:40:22 gonzo kernel: Hardware name: 4236NGG >> Oct 13 16:40:22 gonzo kernel: Modules linked in: i915 fbcon font bitblit >> softcursor drm_kms_helper drm fb fbdev snd_hda_codec_conexant thinkpad_acpi >> nvram e1000e iwlagn intel_agp cfbcopyarea intel_gtt video snd_hda_intel >> backlight agpgart snd_hda_codec cfbimgblt cfbfillrect >> Oct 13 16:40:22 gonzo kernel: Pid: 5164, comm: cat Not tainted 3.1.0-rc4+ #1 >> Oct 13 16:40:22 gonzo kernel: Call Trace: >> Oct 13 16:40:22 gonzo kernel: [] ? >> warn_slowpath_common+0x78/0x8c >> Oct 13 16:40:22 gonzo kernel: [] ? >> gen6_gt_force_wake_get+0x1f/0x3c [i915] >> Oct 13 16:40:22 gonzo kernel: [] ? >> i915_rstdby_delays+0x2e/0x77 [i915] >> Oct 13 16:40:22 gonzo kernel: [] ? seq_read+0x16e/0x355 >> Oct 13 16:40:22 gonzo kernel: [] ? vfs_read+0xac/0x126 >> Oct 13 16:40:22 gonzo kernel: [] ? sys_read+0x45/0x6e >> Oct 13 16:40:22 gonzo kernel: [] ? >> system_call_fastpath+0x16/0x1b >> Oct 13 16:40:22 gonzo kernel: ---[ end trace 056b0c70c095c365 ]--- >> >> Regards, >> Dieter >> >> Original-Nachricht >>> Datum: Thu, 13 Oct 2011 16:00:23 +0200 >>> Von: Daniel Vetter >>> An: Dieter Mummenschanz >>> CC: intel-gfx@lists.freedesktop.org >>> Betreff: Re: [Intel-gfx] frequent x crashes with gen6/sna >> >>> On Thu, Oct 13, 2011 at 03:45:22PM +0200, Dieter Mummenschanz wrote: >>> > hello, >>> > >>> > using latest drm-core-next git from Dave Airlie as well as the latest >>> xf86-video-intel git my system (Sandybridge Mobile (GT2+)) still hangs >>> frequently right before X dies. This happens every time the GPU is under >>> considerable stress, like decoding a va-api stream and running OpenGL apps >>> at the >>> same time. >>> > syslog records the hang: >>> > >>> > kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... >>> GPU hung >>> > kernel: [drm] capturing error event; look for more information in >>> /debug/dri/0/i915_error_state >>> > kernel: [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 >>> (awaiting 3263296 at 3263293, next 3263297) >>> > >>> > after 3-4 seconds the system resumes normal following the X crash a >>> couple of minutes later: >>> > kernel: [drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH >>> > kernel: [drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH >>> > >>> > gpu related module opts are: >>> > i915.i915_enable_rc6=1 pcie_aspm=force i915.i915_enable_fbc=1 >>> i915.lvds_downclock=1 >>> > >>> > at least rc6 enabled is mandatory for me since I ran a mobile gpu. >>> > >>> > any ideas? >>> >>> We have (unfortunately) still a few outstanding issues. To check whether >>> yours is new, please attach the full dmesg and the i915_error_state of the >>> gpu hang. >>> >>> Thanks, Daniel >>> -- >>> Daniel Vetter >>> Mail: dan...@ffwll.ch >>> Mobile: +41 (0)79 365 57 48 >> >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> > > > >-- >Daniel Vetter >daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http:/
[Intel-gfx] gen6_gt_force_wake issue
Hello, current xf86-video-intel git crashex X frequently on my machine (see kernel log). Any Workarounds/Ideas? Regards, Nico Oct 5 08:58:53 gonzo kernel: WARNING: at drivers/gpu/drm/i915/i915_drv.c:372 gen6_gt_force_wake_put+0x1f/0x45 [i915]() Oct 5 08:58:53 gonzo kernel: Hardware name: 4236NGG Oct 5 08:58:53 gonzo kernel: Modules linked in: i915 fbcon font bitblit softcursor drm_kms_helper drm fb fbdev snd_hda_codec_conexant thinkpad_acpi iwlagn cfbcopyarea nvram intel_agp intel_gtt snd_hda_intel agpgart video backlight e1000e cfbimgblt cfbfillrect snd_hda_codec Oct 5 08:58:53 gonzo kernel: Pid: 3358, comm: cat Tainted: G W 3.1.0-rc9 #4 Oct 5 08:58:53 gonzo kernel: Call Trace: Oct 5 08:58:53 gonzo kernel: [] ? warn_slowpath_common+0x78/0x8c Oct 5 08:58:53 gonzo kernel: [] ? gen6_gt_force_wake_put+0x1f/0x45 [i915] Oct 5 08:58:53 gonzo kernel: [] ? i915_delayfreq_table+0x4c/0x95 [i915] Oct 5 08:58:53 gonzo kernel: [] ? seq_read+0x16e/0x355 Oct 5 08:58:53 gonzo kernel: [] ? vfs_read+0xac/0x126 Oct 5 08:58:53 gonzo kernel: [] ? sys_read+0x45/0x6e Oct 5 08:58:53 gonzo kernel: [] ? system_call_fastpath+0x16/0x1b ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi all, ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect that the changes made in drivers/gpu/drm/i915/i915_dma.c are the cause of the problem. http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.0%2Fsnapshots%2Fpatch-3.0-rc7-git1.bz2;z=14 Any Clues? Regards Nic -Ursprüngliche Nachricht- Von: "Nicolas Kalkhof" Gesendet: Jul 19, 2011 9:08:26 PM An: "Ian Romanick" Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games >Hi Ian, > >thx for your reply. ok I give it a try and will report my findings > >regards >nic > >-Ursprüngliche Nachricht- >Von: "Ian Romanick" >Gesendet: Jul 19, 2011 8:45:53 PM >An: "Nicolas Kalkhof" >Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games > >>-----BEGIN PGP SIGNED MESSAGE- >>Hash: SHA1 >> >>On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote: >>> Hi there, >>> >>> I've experienced a strange depth buffer issue recently with OpenGL games >>> (see attached screenshots). It seems that the depth buffer fails on some >>> pixels. This problem was introduced somewhere between >>> Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and >>> mesa are latest git. >>> Could someone please look into it? >> >>That's very odd. Any chance you could bisect to find the bad commit? >>You should be able to just bisect the drivers/gpu/drm directory. I'm a >>bit suspicious that this is a kernel issue. There were only 5 commits >>in drivers/gpu/drm from rc6 to rc7, and none of them should affect any >>Intel GPUs at all. >>-BEGIN PGP SIGNATURE- >>Version: GnuPG v1.4.11 (GNU/Linux) >>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >>iEYEARECAAYFAk4l0OEACgkQX1gOwKyEAw/BWQCfeySgLPcT1bdNxPcTJr/S2aw0 >>vvkAnjS5OJF18pRwrRKaMyG2zoXFqwqB >>=AiSG >>-END PGP SIGNATURE- > > >___ >Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die >Toolbar eingebaut! http://produkte.web.de/go/toolbar >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi,absolutely correct! I've experienced this issue the same way you described during the 2.6.39-rc series in random occurance but much less intensive. however it disappeared during the 3.0-rc series. now the depth/alpha issue occurs instantly after starting the OGL app. I'll try to nail down the bad commit.regards,nicVon: Safety0ff Gesendet: Jul 19, 2011 5:12:15 PMAn: intel-gfx@lists.freedesktop.orgBetreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL gamesOn 19/07/11 02:58 PM, Nicolas Kalkhof wrote:I've experienced a strange depth buffer issue recently with OpenGL games (see attached screenshots). It seems that the depth buffer fails on some pixels. This problem was introduced somewhere between Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and mesa are latest git. Could someone please look into it?I've experienced this issue far earlier than the version stated above (i.e. with 2.39 rc's using mesa and xf86-video-intel from git from that time period). It does not occur constantly in my case, just randomly, and not necessarily from application start (i.e. it sometimes started after it had been running a short period of time). I would have mentioned this earlier if I wasn't having ram issues which make it difficult to have any certainty about problems which occur randomly. Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
Hi Ian, thx for your reply. ok I give it a try and will report my findings regards nic -Ursprüngliche Nachricht- Von: "Ian Romanick" Gesendet: Jul 19, 2011 8:45:53 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote: >> Hi there, >> >> I've experienced a strange depth buffer issue recently with OpenGL games >> (see attached screenshots). It seems that the depth buffer fails on some >> pixels. This problem was introduced somewhere between >> Kernel-3.0.0-rc6-git6 and kernel-3.0.0-rc7. Both xf-86-video-intel and >> mesa are latest git. >> Could someone please look into it? > >That's very odd. Any chance you could bisect to find the bad commit? >You should be able to just bisect the drivers/gpu/drm directory. I'm a >bit suspicious that this is a kernel issue. There were only 5 commits >in drivers/gpu/drm from rc6 to rc7, and none of them should affect any >Intel GPUs at all. >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAk4l0OEACgkQX1gOwKyEAw/BWQCfeySgLPcT1bdNxPcTJr/S2aw0 >vvkAnjS5OJF18pRwrRKaMyG2zoXFqwqB >=AiSG >-END PGP SIGNATURE- ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] gen6 (SNB) garbled window content when scrolling with SNA enabled
Hi,it seems that the xf86-video-intel driver has problems refreshing window content with several java applications like squirrel sql or the oxygen xml editor when SNA is enabled. The window content sometimes does not refresh while scrolling - especially when inline-tooltips are opened. Is this a known issue? Could someone please confirm that?Regards,Nic Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) fonts are completely garbled with latest xf86-video-intel GIT
Hi Chris, yes! you did it again :) -Ursprüngliche Nachricht- Von: "Chris Wilson" Gesendet: Jul 6, 2011 2:06:38 PM An: "Nicolas Kalkhof" , intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] gen6 (SNB) fonts are completely garbled with latest xf86-video-intel GIT >Fixed. >-Chris > >-- >Chris Wilson, Intel Open Source Technology Centre ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] gen6 (SNB) fonts are completely garbled with latest xf86-video-intel GIT
Hi,latest xf86-video-intel completely trashes all fonts on my system with sna enabled. xorg.log reveals nothing interesting.any ideas?regardsnic Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
Thanks for bringing that up. Is there a bug report for this issue? I was just about to file a report myself but I don't want to create any duplicates. @Chris: What do you mean with giving X a kick? Neither mouse nor keyboard are responding anymore. Killing X from a remote ssh is the only option. :( Btw. This only happens with SNA enabled. When using the classic (UXA?), dropping back to framebuffer console works fine. I too have a laptop (T420). Is this issues restricted to mobile systems only? Thanks and regards, nic -Ursprüngliche Nachricht- Von: "Andrew Lutomirski" Gesendet: Jun 21, 2011 8:24:21 PM An: "Chris Wilson" Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >On Tue, Jun 21, 2011 at 2:18 PM, Chris Wilson wrote: >> On Tue, 21 Jun 2011 19:41:52 +0200 (CEST), "Nicolas Kalkhof" >> wrote: >>> However now it seems I'm unable to get my framebuffer console back after I >>> bailed out of X. The screen stays black but my system is still responsive >>> via ssh. This happens without your patch. I'll do some more investigation >>> to make sure I didnt introduce this issue. >> >> No, that's another bug with /dev/dri/card0 not honouring O_NONBLOCK. Give >> X a swift kick and it'll wake up again. >> -Chris > >Any plans on fixing this (and related bugs)? The SNA driver makes X >freeze sometimes for me, and it's hard to recover on a laptop when >ctrl-alt-backspace and even alt-sysrq-v don't seem to give me control >of my system back. > >ssh-ing in and killall -9 Xorg works, but it's not so easy on a laptop. > >--Andy ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
Hi Jesse, I've tried your patch below. It locked up my machine a few seconds after X startup :(. I didn't use any boot parameter. I've changed the parameters during runtime by echoing sysfs. I've filed a bug under https://bugs.freedesktop.org/show_bug.cgi?id=38529[../../jump.htm?goto=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D38529][../../jump.htm?goto=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D38529]. Chris Wilson already proposed a patch that solves the stalling and so far my system runs stable even with SNA enabled in xf86-video-intel. However now it seems I'm unable to get my framebuffer console back after I bailed out of X. The screen stays black but my system is still responsive via ssh. This happens without your patch. I'll do some more investigation to make sure I didnt introduce this issue. Thanks and regards, nic -Ursprüngliche Nachricht- Von: "Jesse Barnes" Gesendet: Jun 21, 2011 6:55:27 PM An: "Nicolas Kalkhof" Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >On Tue, 21 Jun 2011 18:12:56 +0200 (CEST) >"Nicolas Kalkhof" wrote: > >> Hi Jesse, >> >> thanks for the infiormation. I've switched rc6 off by >> echo 0 > /sys/module/i915/parameters/i915_enable_rc6 >> this should do it, right? >> cat /sys/module/i915/parameters/i915_enable_rc6 yields "0" >> >> Are you referring to this patch? https://lkml.org/lkml/2011/6/17/371 >> It should be included in kernel 3.0-rc4 and didn't help here :( > >So there are actually a few things that could go wrong in this area. >The problem may be RC6 related, but it could also be turbo related (our >GPU frequency adjustment code). Can you boot without the module >parameter and try this patch and see what happens (after a cold boot)? > >Thanks, >Jesse > >diff --git a/drivers/gpu/drm/i915/intel_display.c >b/drivers/gpu/drm/i915/intel_d >index 81a9059..3c589cb 100644 >--- a/drivers/gpu/drm/i915/intel_display.c >+++ b/drivers/gpu/drm/i915/intel_display.c >@@ -7788,9 +7788,6 @@ void intel_modeset_init(struct drm_device *dev) > intel_init_emon(dev); > } > >- if (IS_GEN6(dev)) >- gen6_enable_rps(dev_priv); >- > INIT_WORK(&dev_priv->idle_work, intel_idle_update); > setup_timer(&dev_priv->idle_timer, intel_gpu_idle_timer, > (unsigned long)dev); ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
Hi Jesse, thanks for the infiormation. I've switched rc6 off by echo 0 > /sys/module/i915/parameters/i915_enable_rc6 this should do it, right? cat /sys/module/i915/parameters/i915_enable_rc6 yields "0" Are you referring to this patch? https://lkml.org/lkml/2011/6/17/371 It should be included in kernel 3.0-rc4 and didn't help here :( regards nico -Ursprüngliche Nachricht- Von: "Jesse Barnes" Gesendet: Jun 21, 2011 6:06:17 PM An: "Nicolas Kalkhof" , intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >It's i915.i915_enable_rc6=0 for extra added redundancy. You might also >try Daniel Blueman's IRQ fix. > >Jesse > >On Tue, 21 Jun 2011 07:57:13 +0200 (CEST) >"Nicolas Kalkhof" wrote: > >> Hi Folks, ok, I'll give it a try this evening. Just one more thing: Should I >> pass enable_rc6 as a boot parameter like this: "i915.enable_rc6=0" or is it >> set by echoing sysfs (/sys/module/i915/parameters/...)? regards, nico >> >> >> -Ursprüngliche Nachricht- >> Von: "Jesse Barnes" >> Gesendet: Jun 21, 2011 2:19:29 AM >> An: "Ted Phelps" >> Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >> >> >On Tue, 21 Jun 2011 10:01:35 +1000 >> >Ted Phelps wrote: >> > >> >> >> >> Hi Nicolas, >> >> >> >> Nicolas Kalkhof writes: >> >> > SNB GPU still hangs frequently with kernel patches next-20110620 >> >> > raising "drm:i915_hangcheck_ring_idle *ERROR* Hangcheck timer >> >> > elapsed... gen6 bsd ring idle". This happens when multiple >> >> > applications (mplayer decoding vaapi stream and some openGL game) >> >> > running at the same time. With either one running there is no >> >> > stalling. Could someone please confirm the issue? >> >> > >> >> > /sys/module/i915/parameters/semaphores is set to 0 >> >> > xf86-video-intel compiled with --enable-sna >> >> >> >> I haven't tried SNA, but I've seen GPU hangs as well (SNB 2600K). I've >> >> found that disabling RC6 (enable_rc6=0) seems to help. Can you see if >> >> that helps? >> >> >> >> [Note to self: submit a bug report] >> > >> >Please do; and please try to confirm that your GPU hangs are really rc6 >> >related. RC6 provides a huge (multiple Watt) power savings, and we >> >really want it to be robust. >> > >> >-- >> >Jesse Barnes, Intel Open Source Technology Center >> >> >> ___ >> Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die >> Toolbar eingebaut! http://produkte.web.de/go/toolbar >> > > >-- >Jesse Barnes, Intel Open Source Technology Center ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
Hello! sorry, setting i915.enable_rc6=0 didn't work for me. I've filed a bug: https://bugs.freedesktop.org/show_bug.cgi?id=38529 thanks and regards nico -Ursprüngliche Nachricht----- Von: "Nicolas Kalkhof" Gesendet: Jun 21, 2011 7:59:51 AM An: intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >Hi Folks, >ok, I'll give it a try this evening. Just one more thing: Should I pass >enable_rc6 as a boot parameter like this: "i915.enable_rc6=0" or is it set by >echoing sysfs (/sys/module/i915/parameters/...)? > >regards, nico > > >-Ursprüngliche Nachricht- >Von: "Jesse Barnes" >Gesendet: Jun 21, 2011 2:19:29 AM >An: "Ted Phelps" >Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches > >>On Tue, 21 Jun 2011 10:01:35 +1000 >>Ted Phelps wrote: >> >>> >>> Hi Nicolas, >>> >>> Nicolas Kalkhof writes: >>> > SNB GPU still hangs frequently with kernel patches next-20110620 >>> > raising "drm:i915_hangcheck_ring_idle *ERROR* Hangcheck timer >>> > elapsed... gen6 bsd ring idle". This happens when multiple >>> > applications (mplayer decoding vaapi stream and some openGL game) >>> > running at the same time. With either one running there is no >>> > stalling. Could someone please confirm the issue? >>> > >>> > /sys/module/i915/parameters/semaphores is set to 0 >>> > xf86-video-intel compiled with --enable-sna >>> >>> I haven't tried SNA, but I've seen GPU hangs as well (SNB 2600K). I've >>> found that disabling RC6 (enable_rc6=0) seems to help. Can you see if >>> that helps? >>> >>> [Note to self: submit a bug report] >> >>Please do; and please try to confirm that your GPU hangs are really rc6 >>related. RC6 provides a huge (multiple Watt) power savings, and we >>really want it to be robust. >> >>-- >>Jesse Barnes, Intel Open Source Technology Center >___ >Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die >Toolbar eingebaut! http://produkte.web.de/go/toolbar >___ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
Hi Folks, ok, I'll give it a try this evening. Just one more thing: Should I pass enable_rc6 as a boot parameter like this: "i915.enable_rc6=0" or is it set by echoing sysfs (/sys/module/i915/parameters/...)? regards, nico -Ursprüngliche Nachricht- Von: "Jesse Barnes" Gesendet: Jun 21, 2011 2:19:29 AM An: "Ted Phelps" Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches >On Tue, 21 Jun 2011 10:01:35 +1000 >Ted Phelps wrote: > >> >> Hi Nicolas, >> >> Nicolas Kalkhof writes: >> > SNB GPU still hangs frequently with kernel patches next-20110620 >> > raising "drm:i915_hangcheck_ring_idle *ERROR* Hangcheck timer >> > elapsed... gen6 bsd ring idle". This happens when multiple >> > applications (mplayer decoding vaapi stream and some openGL game) >> > running at the same time. With either one running there is no >> > stalling. Could someone please confirm the issue? >> > >> > /sys/module/i915/parameters/semaphores is set to 0 >> > xf86-video-intel compiled with --enable-sna >> >> I haven't tried SNA, but I've seen GPU hangs as well (SNB 2600K). I've >> found that disabling RC6 (enable_rc6=0) seems to help. Can you see if >> that helps? >> >> [Note to self: submit a bug report] > >Please do; and please try to confirm that your GPU hangs are really rc6 >related. RC6 provides a huge (multiple Watt) power savings, and we >really want it to be robust. > >-- >Jesse Barnes, Intel Open Source Technology Center ___ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
hello,SNB GPU still hangs frequently with kernel patches next-20110620 raising "drm:i915_hangcheck_ring_idle *ERROR* Hangcheck timer elapsed... gen6 bsd ring idle". This happens when multiple applications (mplayer decoding vaapi stream and some openGL game) running at the same time. With either one running there is no stalling. Could someone please confirm the issue?/sys/module/i915/parameters/semaphores is set to 0xf86-video-intel compiled with --enable-snaregards Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
