Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Daniel Vetter]

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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch