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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
