From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757317AbcEET7H (ORCPT ); Thu, 5 May 2016 15:59:07 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:35015 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755101AbcEET7E (ORCPT ); Thu, 5 May 2016 15:59:04 -0400 Date: Thu, 5 May 2016 21:59:01 +0200 From: Daniel Vetter To: "Zanoni, Paulo R" Cc: "stefanr@s5r6.in-berlin.de" , "airlied@redhat.com" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Vetter, Daniel" Subject: Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW" Message-ID: <20160505195901.GQ1286@phenom.ffwll.local> Mail-Followup-To: "Zanoni, Paulo R" , "stefanr@s5r6.in-berlin.de" , "airlied@redhat.com" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Vetter, Daniel" References: <20160426210008.2f79fcdf@kant> <20160429100741.6be95385@kant> <20160430155154.597829ca@kant> <20160505194506.63b9c113@kant> <1462474211.29701.21.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1462474211.29701.21.camel@intel.com> X-Operating-System: Linux phenom 4.6.0-rc5+ User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 05, 2016 at 06:50:14PM +0000, Zanoni, Paulo R wrote: > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu: > > On Apr 30 Stefan Richter wrote: > > > > > > On Apr 29 Stefan Richter wrote: > > > > > > > > On Apr 26 Stefan Richter wrote:   > > > > > > > > > > v4.6-rc solidly hangs after a short while after boot, login to > > > > > X11, and > > > > > doing nothing much remarkable on the just brought up X desktop. > > > > > > > > > > Hardware: x86-64, E3-1245 v3 (Haswell), > > > > >           mainboard Supermicro X10SAE, > > > > >           using integrated Intel graphics (HD P4600, i915 > > > > > driver), > > > > >           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI, > > > > >           Intel LAN (i217, igb driver), > > > > >           several IEEE 1394 controllers, some of them behind > > > > >           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI, > > > > > Tundra) > > > > >           and one PCI-to-CardBus bridge (Ricoh) > > > > > > > > > > kernel.org kernel, Gentoo Linux userland > > > > > > > > > > 1. known good:  v4.5-rc5 (gcc 4.9.3) > > > > >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time > > > > > > > > > > 2. known good:  v4.5.2 (gcc 5.2.0) > > > > >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time > > > > > > > > > > I will send my linux-4.6-rc5/.config in a follow-up message.   > > >  .config: http://www.spinics.net/lists/kernel/msg2243444.html > > >    lspci: http://www.spinics.net/lists/kernel/msg2243447.html > > > > > > Some userland package versions, in case these have any bearing: > > > x11-base/xorg-drivers-1.17 > > > x11-base/xorg-server-1.17.4 > > > x11-bas/xorg-x11-7.4-r2 > > Furthermore, there is a single display hooked up via DisplayPort. > > > > > > > > > > > > > After it proved impossible to capture an oops through netconsole, > > > > I > > > > started git bisect.  This will apparently take almost a week, as > > > > git > > > > estimated 13 bisection steps and I will be allowing about 12 > > > > hours of > > > > uptime as a sign for a good kernel.  (In my four or five tests of > > > > bad > > > > kernels before I started bisection, they hung after 3 > > > > minutes...5.5 hours > > > > uptime, with no discernible difference in workload.  Maybe 12 h > > > > cutoff is > > > > even too short...)   > > I took at least 18 hours uptime (usually 24 hours) as a sign for good > > kernels.  During the bisection, bad kernels hung after 3 h, 2 h, 9 > > min, > > 45 min, and 4 min uptime.  Thus I arrived at a98ee79317b4 > > "drm/i915/fbc: > > enable FBC by default on HSW and BDW" as the point where the hangs > > are > > introduced. > > > > Quoting the changelog of the commit: > > Thanks for following the instructions on the commit message! :) > > > > >     Oh, and in case you - the person reading this commit message - > > found > >     this commit through git bisect, please do the following: > >      - Check your dmesg and see if there are error messages > > mentioning > >        underruns around the time your problem started happening. > > > > Well, I always had the followings lines in dmesg: > > [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo > > underrun on pipe A > > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO > > underrun > > Oh, well... I had a patch that would just disable FBC in case we saw a > FIFO underrun, but it was rejected. Maybe this is the time to think > about it again? Otherwise, I can't think of much besides disabling FBC > on HSW until all the underruns and watermarks regressions are fixed > forever. Hm, if it's watermarks then testing with latest drm-intel-nightly would be interesting. We finally managed to land atomic watermark updates (should all be there in 4.7 too): https://cgit.freedesktop.org/drm-intel Cheers, Daniel > > > > > I always got these when I switch on the DisplayPort attached monitor. > > Recently I changed userland from kdm to sddm and noticed that I > > apparently get these when sddm shuts down.  I am not aware of whether > > or not this also already happened with kdm. > > > > However, "around the time your problem started happening" there is > > nothing in dmesg, because "your problem" is a complete hang without > > possibility of disk IO and without netconsole output. > > > >      - Download intel-gpu-tools, compile it, and run: > >        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' > > 2>&1 | tee fbc.txt > >        Then send us the fbc.txt file, especially if you get a > > failure. > >        This will really maximize your chances of getting the bug > > fixed > >        quickly. > > > > Do you need this while FBC is enabled, or can I run it while FBC is > > disabled? > > FBC enabled. Considering your description, my hope is that maybe some > specific subtest will be able to hang your machine, so testing this > again will require only running the specific subtest instead of waiting > 18 hours. > > > > >      - Try to find a reliable way to reproduce the problem, and tell > > us. > > > > The reliable way is to just wait for the kernel to hang after about > > 3 minutes to 5.5 hours.  I have not identified any special activity > > which would trigger the hang. > > > >      - Boot with drm.debug=0xe, reproduce the problem, then send us > > the > >        dmesg file. > > > > I can try this, but I am skeptical about getting any useful kernel > > messages from before the hang. > > Agree. > > > > > PS: > > I am mentioning the following just in case that it has any > > relationship > > with the FBC related kernel freezes.  Maybe it doesn't...  There is > > another recent regression on this PC, but I have not yet figured out > > whether it was introduced by any particular kernel version.  The > > regression is:  When switching from X11 to text console by > > [Ctrl][Alt][Fx] > > or by shutting down sddm, I often only get a blank screen.  I suspect > > that this regression was introduced when I replaced kdm by sddm, but > > I am not sure about that. > > Maybe there is some relationship, since this operation involves a mode > change. You can also try checking dmesg to see if there are underruns > right when you do the change. > > > If you don't want to keep carrying a manual revert, you can just boot > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also, > it would be good to know in case you still somehow see the machine > hangs even with FBC disabled. > > Thanks, > Paulo > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch