Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751350AbbG3FSS (ORCPT ); Thu, 30 Jul 2015 01:18:18 -0400 Received: from mail-ig0-f170.google.com ([209.85.213.170]:38617 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750901AbbG3FSR (ORCPT ); Thu, 30 Jul 2015 01:18:17 -0400 MIME-Version: 1.0 In-Reply-To: <20150730013912.GA4068@thunk.org> References: <20150730004937.GA3133@thunk.org> <20150730013912.GA4068@thunk.org> Date: Wed, 29 Jul 2015 22:18:16 -0700 X-Google-Sender-Auth: jYa0ViRzkWN0GWjCh_FRbCjq4hY Message-ID: Subject: Re: [REGRESSION] Re: i915 driver crashes on T540p if docking station attached From: Linus Torvalds To: "Theodore Ts'o" , intel-gfx , DRI , Daniel Vetter , Mani Nikula , Ander Conselvan de Oliveira , Linux Kernel Mailing List , Linus Torvalds Content-Type: multipart/mixed; boundary=047d7b10c9f9b2d087051c10d4ad Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3341 Lines: 73 --047d7b10c9f9b2d087051c10d4ad Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote: > > It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9 You didn't catch enough of the code line to decode the code, but it's early enough in drm_crtc_index() (just five bytes in) that it's almost certainly the very first dereference, so it's almost guaranteed to be that crtc->dev access as part of list_for_each_entry(), with crtc being NULL. And yes, "->dev" is the very first field, so the offset is zero too (while the "->mode_config" list access would not be at offset zero). And it looks like it is called from drm_atomic_helper_check_modeset(): the reason it has a question mark in the backtrace is because the fault happens before the stack frame has even been set up. There are multiple calls to "drm_crtc_index()" from that function, I can't tell which one it is. Looking at the code generation I get, I think it's because update_connector_routing() gets inlined, and that one does several calls. Most of them look like this: if (connector->state->crtc) { idx = drm_crtc_index(connector->state->crtc); ie they check that the crtc is non-NULL, but that last one does not: connector_state->best_encoder = new_encoder; idx = drm_crtc_index(connector_state->crtc); crtc_state = state->crtc_states[idx]; crtc_state->mode_changed = true; and I suspect the fix might be something like the attached. Totally untested. Ted? This whole "atomic modeset" series has been one royal fuck-up, guys. We've had too many of these kinds of crap issues. Linus --047d7b10c9f9b2d087051c10d4ad Content-Type: text/plain; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icpr1zm40 IGRyaXZlcnMvZ3B1L2RybS9kcm1fYXRvbWljX2hlbHBlci5jIHwgOCArKysrKy0tLQogMSBmaWxl IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9k cml2ZXJzL2dwdS9kcm0vZHJtX2F0b21pY19oZWxwZXIuYyBiL2RyaXZlcnMvZ3B1L2RybS9kcm1f YXRvbWljX2hlbHBlci5jCmluZGV4IDViNTlkNWFkN2QxYy4uYWFjMjEyMjk3YjQ5IDEwMDY0NAot LS0gYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2F0b21pY19oZWxwZXIuYworKysgYi9kcml2ZXJzL2dw dS9kcm0vZHJtX2F0b21pY19oZWxwZXIuYwpAQCAtMjMwLDEwICsyMzAsMTIgQEAgdXBkYXRlX2Nv bm5lY3Rvcl9yb3V0aW5nKHN0cnVjdCBkcm1fYXRvbWljX3N0YXRlICpzdGF0ZSwgaW50IGNvbm5f aWR4KQogCX0KIAogCWNvbm5lY3Rvcl9zdGF0ZS0+YmVzdF9lbmNvZGVyID0gbmV3X2VuY29kZXI7 Ci0JaWR4ID0gZHJtX2NydGNfaW5kZXgoY29ubmVjdG9yX3N0YXRlLT5jcnRjKTsKKwlpZiAoY29u bmVjdG9yX3N0YXRlLT5jcnRjKSB7CisJCWlkeCA9IGRybV9jcnRjX2luZGV4KGNvbm5lY3Rvcl9z dGF0ZS0+Y3J0Yyk7CiAKLQljcnRjX3N0YXRlID0gc3RhdGUtPmNydGNfc3RhdGVzW2lkeF07Ci0J Y3J0Y19zdGF0ZS0+bW9kZV9jaGFuZ2VkID0gdHJ1ZTsKKwkJY3J0Y19zdGF0ZSA9IHN0YXRlLT5j cnRjX3N0YXRlc1tpZHhdOworCQljcnRjX3N0YXRlLT5tb2RlX2NoYW5nZWQgPSB0cnVlOworCX0K IAogCURSTV9ERUJVR19BVE9NSUMoIltDT05ORUNUT1I6JWQ6JXNdIHVzaW5nIFtFTkNPREVSOiVk OiVzXSBvbiBbQ1JUQzolZF1cbiIsCiAJCQkgY29ubmVjdG9yLT5iYXNlLmlkLAo= --047d7b10c9f9b2d087051c10d4ad-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/