Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

On Jun 13 Zanoni, Paulo R wrote: > Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu: > > On Jun 10 Paulo Zanoni wrote: > > > > > > Since my test machines don't produce FIFO underrun errors, I tested > > > this by >

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

rtheless think it's worth trying, should I test it on top of 4.7-rc3 or on current drm-intel-nightly? -- Stefan Richter -==- -==- -==-= http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.or

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

have fbc completely enabled and > > working, playing videos can result in video artifacts. [...] > > For the time being, disable FBC for Haswell by default. > > In case we want to improve the commit message: > > We also got reports from Steven Honeyman on openbox+roxterm, a

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

On May 08 Stefan Richter wrote: > On May 06 Daniel Vetter wrote: > > On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote: > [...] > > > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s) > > > > This one failed in both runs. Can you p

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

On May 06 Daniel Vetter wrote: > On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote: [...] > > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s) > > This one failed in both runs. Can you please retest with just that using > > # kms_frontbuffer_track

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

On May 08 Stefan Richter wrote: > On May 05 Zanoni, Paulo R wrote: > > 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

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

As expected, i915.enable_fbc=0 works fine. No freeze within 2.5 days uptime; tested on v4.6-rc6. -- Stefan Richter -==- -=-= -=--- http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org

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

n test this sometime soon. -- Stefan Richter -==- -=-= --==- http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

On May 05 Zanoni, Paulo R wrote: > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu: > > 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 s

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

On May 05 Stefan Richter wrote: > Quoting the changelog of the commit: [...] > - 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,

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

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. > > >

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

On May 05 Stefan Richter wrote: > Quoting the changelog of the commit: [...] > - 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.