Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756437AbdGKSWx (ORCPT ); Tue, 11 Jul 2017 14:22:53 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:33677 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756421AbdGKSWu (ORCPT ); Tue, 11 Jul 2017 14:22:50 -0400 MIME-Version: 1.0 In-Reply-To: <1499796510.5315.27.camel@gmx.de> References: <1499794333.5315.8.camel@gmx.de> <1499796510.5315.27.camel@gmx.de> From: Ilia Mirkin Date: Tue, 11 Jul 2017 14:22:49 -0400 X-Google-Sender-Auth: zTMWLefjxLd_Wk4YDG8gOCa9TTY Message-ID: Subject: Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335 To: Mike Galbraith Cc: LKML , "dri-devel@lists.freedesktop.org" , "nouveau@lists.freedesktop.org" , David Airlie , Ben Skeggs Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1555 Lines: 40 On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) > 01:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1 > >> 2. What displays, if any, you have plugged into the NVIDIA board when >> this happens? > > A Philips 273V, via DVI. > >> 3. Any boot parameters, esp relating to ACPI, PM, or related? > > None for those, what's there that will be unfamiliar to you are for > patches that aren't applied. > > nortsched hpc_cpusets skew_tick=1 ftrace_dump_on_oops audit=0 > nodelayacct cgroup_disable=memory rtkthreads=1 rtworkqueues=2 panic=60 > ignore_loglevel crashkernel=256M,high OK, thanks. So in other words, a fairly standard desktop with a PCIe board plugged in. No funny business. (Laptops can create a ton of additional weirdness, which I assumed you had since you were talking about STR.) My best guess is that gf119_head_vblank_put either has a bogus head id (should be in the 0..3 range) which causes it to do an out-of-bounds read on MMIO space, or that the MMIO mapping has already been removed by the time nouveau_display_suspend runs. Adding Ben Skeggs for additional insight. Some display stuff did change for 4.13 for GM20x+ boards. If it's not too much trouble, a bisect would be pretty useful. Cheers, -ilia