[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
daniel at ffwll.ch
Thu May 5 19:59:01 UTC 2016
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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list