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
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
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, 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 dan...@ffwll.ch An: Nicolas Kalkhof nkalk...@web.de Cc: intel-gfx Intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station On Wed, May 20, 2015 at 5:05 PM, Nicolas Kalkhof nkalk...@web.de 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] [81645beb] ? dump_stack+0x40/0x50 [ 20.137663] [81047047] ? warn_slowpath_common+0x77/0xb0 [ 20.137665] [810470c5] ? warn_slowpath_fmt+0x45/0x50 [ 20.137666] [8137d555] ? check_crtc_state+0x8a5/0xfc0 [ 20.137668] [8108d504] ? ktime_get+0x34/0xb0 [ 20.137671] [8138ff29] ? intel_modeset_check_state+0x229/0xb50 [ 20.137673] [81390e38] ? intel_crtc_set_config+0x578/0x650 [ 20.137675] [8131136f] ? drm_mode_set_config_internal+0x5f/0x100 [ 20.137677] [81315cda] ? drm_mode_setcrtc+0x22a/0x5f0 [ 20.137679] [8130766a] ? drm_ioctl+0x15a/0x580 [ 20.137682] [81108ce8] ? do_vfs_ioctl+0x2e8/0x4f0 [ 20.137684] [8103c19b] ? __do_page_fault+0x17b/0x3e0 [ 20.137685] [81108f26] ? SyS_ioctl+0x36/0x80 [ 20.137688] [8164dd9b] ? 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
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 dan...@ffwll.ch An: Nicolas Kalkhof nkalk...@web.de Cc: intel-gfx Intel-gfx@lists.freedesktop.org Betreff: Re: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station On Wed, May 20, 2015 at 6:00 PM, Nicolas Kalkhof nkalk...@web.de 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 dan...@ffwll.ch An: Nicolas Kalkhof nkalk...@web.de Cc: intel-gfx Intel-gfx@lists.freedesktop.org Betreff: Re: [Intel-gfx] still experiencing oops connecting Laptop to docking Station On Wed, May 20, 2015 at 5:05 PM, Nicolas Kalkhof nkalk...@web.de 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] [81645beb] ? dump_stack+0x40/0x50 [ 20.137663] [81047047] ? warn_slowpath_common+0x77/0xb0 [ 20.137665] [810470c5] ? warn_slowpath_fmt+0x45/0x50 [ 20.137666] [8137d555] ? check_crtc_state+0x8a5/0xfc0 [ 20.137668] [8108d504] ? ktime_get+0x34/0xb0 [ 20.137671] [8138ff29] ? intel_modeset_check_state+0x229/0xb50 [ 20.137673] [81390e38] ? intel_crtc_set_config+0x578/0x650 [ 20.137675] [8131136f] ? drm_mode_set_config_internal+0x5f/0x100 [ 20.137677] [81315cda] ? drm_mode_setcrtc+0x22a/0x5f0 [ 20.137679] [8130766a
[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] [81645beb] ? dump_stack+0x40/0x50 [ 20.137663] [81047047] ? warn_slowpath_common+0x77/0xb0 [ 20.137665] [810470c5] ? warn_slowpath_fmt+0x45/0x50 [ 20.137666] [8137d555] ? check_crtc_state+0x8a5/0xfc0 [ 20.137668] [8108d504] ? ktime_get+0x34/0xb0 [ 20.137671] [8138ff29] ? intel_modeset_check_state+0x229/0xb50 [ 20.137673] [81390e38] ? intel_crtc_set_config+0x578/0x650 [ 20.137675] [8131136f] ? drm_mode_set_config_internal+0x5f/0x100 [ 20.137677] [81315cda] ? drm_mode_setcrtc+0x22a/0x5f0 [ 20.137679] [8130766a] ? drm_ioctl+0x15a/0x580 [ 20.137682] [81108ce8] ? do_vfs_ioctl+0x2e8/0x4f0 [ 20.137684] [8103c19b] ? __do_page_fault+0x17b/0x3e0 [ 20.137685] [81108f26] ? SyS_ioctl+0x36/0x80 [ 20.137688] [8164dd9b] ? 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 dan...@ffwll.ch
An: Chandra Konduru chandra.kond...@intel.com
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 chandra.kond...@intel.com
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 chandra.kond...@intel.com
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] [8155c7ab] ? dump_stack+0x40/0x50
[ 35.159248] [810451b7] ? warn_slowpath_common+0x77/0xb0
[ 35.159251] [81045235] ? warn_slowpath_fmt+0x45/0x50
[ 35.159264] [a027f308] ? intel_modeset_check_state+0x208/0xb50
[i915]
[ 35.159278] [a0279dcb] ? __intel_set_mode+0xa8b/0xcb0 [i915]
[ 35.159291] [a0280238] ? intel_crtc_set_config+0x578/0x650 [i915]
[ 35.159303] [a01243d7] ? drm_crtc_check_viewport+0x27/0xf0 [drm]
[ 35.159312] [a012505f] ? drm_mode_set_config_internal+0x5f/0x100
[drm]
[ 35.159321] [a01299ca] ? drm_mode_setcrtc+0x22a/0x5f0 [drm]
[
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 maarten.lankho...@linux.intel.com 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] [8155c7ab] ? dump_stack+0x40/0x50 [ 19.139599] [810451b7] ? warn_slowpath_common+0x77/0xb0 [ 19.139601] [81045235] ? warn_slowpath_fmt+0x45/0x50 [ 19.139607] [a0244875] ? check_crtc_state+0x8a5/0xfc0 [i915] [ 19.139615] [a0257279] ? intel_modeset_check_state+0x229/0xb50 [i915] [ 19.139621] [a0251d1b] ? __intel_set_mode+0xa8b/0xcb0 [i915] [ 19.139628] [a0258188] ? intel_crtc_set_config+0x578/0x650 [i915] [ 19.139631] [a011dc25] ? drm_atomic_helper_plane_set_property+0x85/0xd0 [drm_kms_helper] [ 19.139636] [a00ce01f] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 19.139639] [a011f5a9] ? restore_fbdev_mode+0xb9/0xe0 [drm_kms_helper] [ 19.139641] [a01214ab] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1b/0x60 [drm_kms_helper] [ 19.139647] [a0267c49] ? intel_fbdev_restore_mode+0x19/0x50 [i915] [ 19.139650] [a00c3348] ? drm_lastclose+0x28/0x140 [drm] [ 19.139653] [a00c3780] ? drm_release+0x320/0x520 [drm] [ 19.139655] [810f1767] ? __fput+0x97/0x1f0 [ 19.139657] [8105bfc7] ? task_work_run+0xb7/0xf0 [ 19.139660] [8156398a] ? 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] [8155c7ab] ? dump_stack+0x40/0x50 [ 19.139705] [810451b7] ? warn_slowpath_common+0x77/0xb0 [ 19.139706] [81045235] ? warn_slowpath_fmt+0x45/0x50 [ 19.139711] [a0244875] ? check_crtc_state+0x8a5/0xfc0 [i915] [ 19.139718] [a0257279] ? intel_modeset_check_state+0x229/0xb50 [i915] [ 19.139725] [a0251d1b] ? __intel_set_mode+0xa8b/0xcb0 [i915] [ 19.139731] [a0258188] ? intel_crtc_set_config+0x578/0x650 [i915] [ 19.139733] [a011dc25] ? drm_atomic_helper_plane_set_property+0x85/0xd0 [drm_kms_helper] [ 19.139738] [a00ce01f] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 19.139740] [a011f5a9] ? restore_fbdev_mode+0xb9/0xe0 [drm_kms_helper] [ 19.139742] [a01214ab] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1b/0x60 [drm_kms_helper] [ 19.139748] [a0267c49] ? intel_fbdev_restore_mode+0x19/0x50 [i915] [ 19.139751] [a00c3348] ? drm_lastclose+0x28/0x140 [drm] [
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 dan...@ffwll.ch An: Nicolas Kalkhof nkalk...@web.de 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] [81590365] ? dump_stack+0x40/0x50 [ 143.896223] [81043617] ? warn_slowpath_common+0x77/0xb0 [ 143.896228] [a016bf05] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.896235] [a00efea5] ? drm_atomic_get_connector_state+0x95/0x110 [drm] [ 143.896252] [a0352e8f] ? intel_crtc_set_config+0xc6f/0xfb0 [i915] [ 143.896258] [8112c21b] ? ep_poll_callback+0xeb/0x120 [ 143.896264] [a00eed99] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.896273] [a00d] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.896281] [a00e47fa] ? drm_mode_setcrtc+0x22a/0x5f0 [drm] [ 143.896288] [a00d65ca] ? drm_ioctl+0x15a/0x580 [drm] [ 143.896292] [8106b8cf] ? pick_next_task_fair+0x43f/0x4b0 [ 143.896295] [81103488] ? do_vfs_ioctl+0x2e8/0x4f0 [ 143.896298] [8159288d] ? __schedule+0x24d/0x7c0 [ 143.896301] [811036c6] ? SyS_ioctl+0x36/0x80 [ 143.896303] [811055f2] ? SyS_poll+0x52/0xf0 [ 143.896307] [81595f36] ? 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: [a00eff84] 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:[a00eff84] [a00eff84] 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] [a034c0ac] ? intel_modeset_compute_config+0x3c/0x1090 [i915] [ 143.897166] [8158f7b5] ? printk+0x48/0x4d [ 143.897196] [a0351b49] ? intel_set_mode+0x39/0xa0 [i915] [ 143.897225] [a016bf05] ? drm_atomic_helper_connector_duplicate_state+0x35/0x40 [drm_kms_helper] [ 143.897272] [a00ef362] ? drm_atomic_state_clear+0xb2/0x180 [drm] [ 143.897311] [a0352c3d] ? intel_crtc_set_config+0xa1d/0xfb0 [i915] [ 143.897343] [8112c21b] ? ep_poll_callback+0xeb/0x120 [ 143.897372] [a00eed99] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 [drm] [ 143.897409] [a00d] ? drm_mode_set_config_internal+0x5f/0x100 [drm] [ 143.897447] [a00e47fa] ? drm_mode_setcrtc+0x22a/0x5f0
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
Hello, Ive been trying to enable PC8 on my Haswell i7-4600M Notebook but im 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
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] 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 wont 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 wont 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] 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 dan...@ffwll.ch An:Nicolas Kalkhof nkalk...@web.de Cc:intel-gfx@lists.freedesktop.org Betreff:Re: [Intel-gfx] i915/drm: SNB gpu wont 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 wont 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 wont throttle back then. Any ideas/clues? One issue we know about is when both gpu/cpu arent 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 its not this case, can you benchmark with the cpu frequency fixed to the maximum? Since things previously worked with the old tuning values I dont think its 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
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 daniel.vet...@ffwll.ch Gesendet: Nov 16, 2011 10:14:18 PM An: Nicolas Kalkhof nkalk...@web.de Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default On Wed, Nov 16, 2011 at 21:56, Nicolas Kalkhof nkalk...@web.de 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
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 daniel.vet...@ffwll.ch Gesendet: Nov 17, 2011 10:22:07 AM An: Nicolas Kalkhof nkalk...@web.de 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 nkalk...@web.de 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 daniel.vet...@ffwll.ch Gesendet: Nov 16, 2011 10:14:18 PM An: Nicolas Kalkhof nkalk...@web.de Betreff: Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default On Wed, Nov 16, 2011 at 21:56, Nicolas Kalkhof nkalk...@web.de 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
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 l...@mit.edu Gesendet: Nov 16, 2011 6:24:54 PM An: Keith Packard kei...@keithp.com 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 kei...@keithp.com wrote: On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter daniel.vet...@ffwll.ch 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 dan...@ffwll.ch Gesendet: Nov 7, 2011 7:36:28 PM An: Nicolas Kalkhof nkalk...@web.de 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
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 dan...@ffwll.ch Gesendet: Nov 6, 2011 6:46:54 PM An: Nicolas Kalkhof nkalk...@web.de 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, 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 dan...@ffwll.ch Gesendet: Nov 7, 2011 5:05:12 PM An: Nicolas Kalkhof nkalk...@web.de 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 torva...@linux-foundation.org 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
] 0.00% 0.15% [/usr/bin/wpa_cli] 0.00% 0.15% -Ursprüngliche Nachricht- Von: Daniel Vetter dan...@ffwll.ch Gesendet: Nov 7, 2011 5:56:38 PM An: Nicolas Kalkhof nkalk...@web.de 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,
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 daniel.vet...@ffwll.ch
Gesendet: Nov 6, 2011 1:35:22 PM
An: intel-gfx intel-gfx@lists.freedesktop.org
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 daniel.vet...@ffwll.ch
---
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))
+ spin_lock_irqsave(dev_priv-gt_lock, irqflags);
+ if (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 j...@mindspring.com 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] IRQ [8105c3a0] warn_slowpath_common+0x83/0x9b Oct 22 20:52:59 localhost kernel: [ 939.830941] [8105c3d2] warn_slowpath_null+0x1a/0x1c Oct 22 20:52:59 localhost kernel: [ 939.830952] [a006b624] gen6_gt_force_wake_put+0x29/0x51 [i915] Oct 22 20:52:59 localhost kernel: [ 939.830963] [a006f45f] i915_read32+0x44/0x6b [i915] Oct 22 20:52:59 localhost kernel: [ 939.830975] [a00724a9] i915_hangcheck_elapsed+0xe8/0x1f8 [i915] Oct 22 20:52:59 localhost kernel: [ 939.831027] [81062ddd] irq_exit+0x5d/0xcf Oct 22 20:52:59 localhost kernel: [ 939.831032] [8150de91] smp_apic_timer_interrupt+0x7c/0x8a Oct 22 20:52:59 localhost kernel: [ 939.831036] [8150bd73] apic_timer_interrupt+0x73/0x80 Oct 22 20:52:59 localhost kernel: [ 939.831038] EOI [81014ded] ? paravirt_read_tsc+0x9/0xd Oct 22 20:52:59 localhost kernel: [ 939.831046] [81297075] ? intel_idle+0xe5/0x10c Oct 22 20:52:59 localhost kernel: [ 939.831050] [81297071] ? intel_idle+0xe1/0x10c Oct 22 20:52:59 localhost kernel: [ 939.831054] [813e14fe] cpuidle_idle_call+0x11c/0x1fe Oct 22 20:52:59 localhost kernel: [ 939.831059] [8100e2ef] cpu_idle+0xab/0x101 Oct 22 20:52:59 localhost kernel: [ 939.831063] [814df673] rest_init+0xd7/0xde Oct 22 20:52:59 localhost kernel: [ 939.831067] [814df59c] ? csum_partial_copy_generic+0x16c/0x16c Oct 22 20:52:59 localhost kernel: [ 939.831072] [81d53bb0] start_kernel+0x3dd/0x3ea Oct 22 20:52:59 localhost kernel: [ 939.831076] [81d532c4] x86_64_start_reservations+0xaf/0xb3 Oct 22 20:52:59 localhost kernel: [ 939.831081] [81d53140] ?
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 dan...@ffwll.ch Gesendet: Oct 13, 2011 6:24:34 PM An: Dieter Mummenschanz mummensch...@gmx.net 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 mummensch...@gmx.net 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: [8102fcf2] ? warn_slowpath_common+0x78/0x8c Oct 13 16:40:22 gonzo kernel: [a00ff484] ? gen6_gt_force_wake_get+0x1f/0x3c [i915] Oct 13 16:40:22 gonzo kernel: [a0108d0e] ? i915_rstdby_delays+0x2e/0x77 [i915] Oct 13 16:40:22 gonzo kernel: [810ba9d1] ? seq_read+0x16e/0x355 Oct 13 16:40:22 gonzo kernel: [810a1eaa] ? vfs_read+0xac/0x126 Oct 13 16:40:22 gonzo kernel: [810a1f69] ? sys_read+0x45/0x6e Oct 13 16:40:22 gonzo kernel: [813b3c7b] ? 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 dan...@ffwll.ch An: Dieter Mummenschanz mummensch...@gmx.net 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://f.web.de/?mc=021192
[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: [8102fc96] ? warn_slowpath_common+0x78/0x8c Oct 5 08:58:53 gonzo kernel: [a01094c0] ? gen6_gt_force_wake_put+0x1f/0x45 [i915] Oct 5 08:58:53 gonzo kernel: [a0112795] ? i915_delayfreq_table+0x4c/0x95 [i915] Oct 5 08:58:53 gonzo kernel: [810baa2d] ? seq_read+0x16e/0x355 Oct 5 08:58:53 gonzo kernel: [810a1efa] ? vfs_read+0xac/0x126 Oct 5 08:58:53 gonzo kernel: [810a1fb9] ? sys_read+0x45/0x6e Oct 5 08:58:53 gonzo kernel: [813b3cfb] ? 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 Ian, thx for your reply. ok I give it a try and will report my findings regards nic -Ursprüngliche Nachricht- Von: Ian Romanick i...@freedesktop.org Gesendet: Jul 19, 2011 8:45:53 PM An: Nicolas Kalkhof nkalk...@web.de 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
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 ch...@chris-wilson.co.uk Gesendet: Jul 6, 2011 2:06:38 PM An: Nicolas Kalkhof nkalk...@web.de, 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
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 jbar...@virtuousgeek.org Gesendet: Jun 21, 2011 2:19:29 AM An: Ted Phelps phe...@gnusto.com Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches On Tue, 21 Jun 2011 10:01:35 +1000 Ted Phelps phe...@gnusto.com 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
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 jbar...@virtuousgeek.org Gesendet: Jun 21, 2011 6:55:27 PM An: Nicolas Kalkhof nkalk...@web.de Betreff: Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches On Tue, 21 Jun 2011 18:12:56 +0200 (CEST) Nicolas Kalkhof nkalk...@web.de 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
[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-snaregardsSchon gehrt? WEB.DE hat einen genialen Phishing-Filter in dieToolbar eingebaut! http://produkte.web.de/go/toolbar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
