Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754266AbdGNNg5 (ORCPT ); Fri, 14 Jul 2017 09:36:57 -0400 Received: from mout.gmx.net ([212.227.17.21]:53926 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753606AbdGNNgz (ORCPT ); Fri, 14 Jul 2017 09:36:55 -0400 Message-ID: <1500039368.5763.12.camel@gmx.de> Subject: Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335 From: Mike Galbraith To: Ilia Mirkin , Peter Zijlstra Cc: LKML , "dri-devel@lists.freedesktop.org" , "nouveau@lists.freedesktop.org" , David Airlie , Ben Skeggs Date: Fri, 14 Jul 2017 15:36:08 +0200 In-Reply-To: References: <1499794333.5315.8.camel@gmx.de> <1499796510.5315.27.camel@gmx.de> <1499853345.23742.8.camel@gmx.de> <1499858703.23742.25.camel@gmx.de> Content-Type: multipart/mixed; boundary="=-QEsAZW81vc9tIYr3HPvB" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 X-Provags-ID: V03:K0:M5go8mZEN1uQEsP+00UzmZI2nd3IcobPDvDO5m4e1AtPmCu0KN4 rIJjXdI3PPR0NMRwgcBy7AX0Utzot+f+bkQeg0gmTkQra1RYJVlWAGbwM5yg1bvZ/S4Zv7b jtc1Ag1Ay39yrYdGunh6wvAdCPDJgOmq/8YxXGelauJxzG3DgxPck+4qHIr7uiSmwmeZ0IM hXWGQMoGGXdgBhy3kdtug== X-UI-Out-Filterresults: notjunk:1;V01:K0:gBleIGzh0eE=:KTT4IhQj5D6kfRtu7cQyVU /Us9Nm6mtT2HTPpOMR2pdkagrzQ571/e8JmalkclZ2QC7zX8NyAK6fL6jDm4qmhbHpXONCFHa FN/4em9doHol/fPtKqedk7LZYq39WtHhFL/KFY8YqurRHOKCjCScbrX4rsO9YChEaMmMGOaUe 4O3nspmbhf8VbZ9E9eZQ0nO6qQ6Dzn0rPuVpxpiHPfFdi7kUNAO0RzNt0l9LCfB8GYI62RV8M zWovNqpgnoUbP0MrUwoj0NvSUChDx9vcRsTyEYHi7iYoYhWShP7RD9QAQzWHgoOagMZ1o50/l r79bS4Rz4v2e941swIB2St8if7Hg9HjtKNhnL9reOWLeECPcEJyNYxF2Wra/LXTxqvmrPCG3g SMtMdBOJj33GZwknz4hdhU0zjFzZYVt2FQTJnGnH8v3186pHpWxltHCeJVNVqR0rTttgo30ys WZbD+8x+iz+DEvFFi0qwQ6q20QJLVVGHZGM+LkldloCGB/SanK447LcHbYfGBgo9WEqMOGsdj 1vofRFdxtvH1+g6ZJcir2Dyeu3KICIaZpZhxSZzI0voMp26Ac0KaDhP6U5A1iyy6zSTKYSe+M 901aqcUO9Yy1LFVZ/eMtb3XAdG/lPNI9m9E8FXlenypW6d71QokV8GVd6M0OAWkOcqKWiSZY2 C1cD8SjKzmIBKOsuRyG1oBic+BNI5L4rVaeJpRXaG0j+jC5Y0pn58FRp8Z2lssLGrKyvVUs3X Rmph8VHBty6KEJiF/QlS2Rp6tWRZuxnGISpF1+odi7B62+Ai3RPeGglcti7J/qFCT5ULitV3E XG1NbeyoM+9OvD+IYsogiOFx70fMg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4512 Lines: 100 --=-QEsAZW81vc9tIYr3HPvB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's no= t > >> > too much trouble, a bisect would be pretty useful. > >> > >> Bisection seemingly went fine, but the result is odd. > >> > >> e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit > > > > But it really really is bad. Looking at gitk fork in the road leading > > to it... > > > > 52d9d38c183b drm/sti:fix spelling mistake: "compoment" -> "component" -= good > > e4e818cc2d7c drm: make drm_panel.h self-contained -= good > > 9cf8f5802f39 drm: add missing declaration to drm_blend.h -= good > > > > Before the git highway splits, all is well. The lane with commits > > works fine at both ends, but e98c58e55f68 is busted. Merge arfifact? >=20 > Hmmm... that tree does not appear to have gotten a v4.12 backmerge at > any point. The last backmerge from Linus as far as I can tell was > v4.11-rc7. Could be an interaction with some out-of-tree change. Ok, a network outage gave me time to go hunting. =C2=A0Indeed it is a bad interaction with the tree DRM merged into. =C2=A0All DRM did was to slip a WARN_ON_ONCE() that nouveau triggers into a kernel module where such things no longer warn, they blow the box out of the water. =C2=A0I made a dinky testcase module (attached), and bisected to the real root.... 19d436268dde95389c616bb3819da73f0a8b28a8 is the first bad commit commit 19d436268dde95389c616bb3819da73f0a8b28a8 Author: Peter Zijlstra Date: Sat Feb 25 08:56:53 2017 +0100 debug: Add _ONCE() logic to report_bug() =20 Josh suggested moving the _ONCE logic inside the trap handler, using a bit in the bug_entry::flags field, avoiding the need for the extra variable. =20 Sadly this only works for WARN_ON_ONCE(), since the others have printk() statements prior to triggering the trap. =20 Still, this saves a fair amount of text and some data: =20 text data filename 10682460 4530992 defconfig-build/vmlinux.orig 10665111 4530096 defconfig-build/vmlinux.patched =20 Suggested-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar :040000 040000 9f47f66ec4c234f6ee8e2a09e991c95fe47cf2c1 3e92aa9e77b39ed075a= e2c3bdf041d92ef898f62 M arch :040000 040000 34f70b73d40c82533dd7df9b289106be69e2fa8d dd5d7248694a36b3e17= 0f2dca5d9c4121535a990 M include :040000 040000 f6e627b0d378f0a00d2987fdd0c7b215306e6e3c b360d4ee2579744cce5= 30184d7dab13493f73ee0 M lib=C2=A0 --=-QEsAZW81vc9tIYr3HPvB Content-Disposition: attachment; filename="warn_on_once.patch" Content-Type: text/x-patch; name="warn_on_once.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 LS0tCiBrZXJuZWwvTWFrZWZpbGUgfCAgICAyICsrCiBrZXJuZWwvZm9vLmMgICAgfCAgIDE1ICsr KysrKysrKysrKysrKwogMiBmaWxlcyBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspCgotLS0gYS9r ZXJuZWwvTWFrZWZpbGUKKysrIGIva2VybmVsL01ha2VmaWxlCkBAIC0xMTEsNiArMTExLDggQEAg b2JqLSQoQ09ORklHX01FTUJBUlJJRVIpICs9IG1lbWJhcnJpZXIubwogCiBvYmotJChDT05GSUdf SEFTX0lPTUVNKSArPSBtZW1yZW1hcC5vCiAKK29iai1tICs9IGZvby5vCisKICQob2JqKS9jb25m aWdzLm86ICQob2JqKS9jb25maWdfZGF0YS5oCiAKIHRhcmdldHMgKz0gY29uZmlnX2RhdGEuZ3oK LS0tIC9kZXYvbnVsbAorKysgYi9rZXJuZWwvZm9vLmMKQEAgLTAsMCArMSwxNSBAQAorI2luY2x1 ZGUgPGxpbnV4L21vZHVsZS5oPgorI2luY2x1ZGUgPGxpbnV4L2J1Zy5oPgorCitzdGF0aWMgaW50 IF9faW5pdCBmb29faW5pdCh2b2lkKQoreworCXByaW50ayhLRVJOX0lORk8gImZvbzogbW9kdWxl IGxvYWRlZFxuIik7CisJV0FSTl9PTl9PTkNFKDEpOworCXJldHVybiAwOworfQorCitzdGF0aWMg dm9pZCBfX2V4aXQgZm9vX2V4aXQodm9pZCkgeyB9CisKK21vZHVsZV9pbml0KGZvb19pbml0KTsK K21vZHVsZV9leGl0KGZvb19leGl0KTsKK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsK --=-QEsAZW81vc9tIYr3HPvB--