Created attachment 127238 [details] dmesg This is on Skylake/4.9pre-rc1. Enabling fbc (enable_fbc=1) on skylake causes near-constant GPU hangs/resets. This is new since 4.8 final. Booting with enable_fbc=0 or enable_fbc=-1 works. I understand this is probably unsupported, but thought it might be useful to point this out. dmesg and cpuinfo attached. This was right after boot with graphical login started. The hangs continue with the same signature after my desktop environment starts.
Created attachment 127239 [details] cpu info
I don't think it will help, but it would be interesting at least to see what /sys/class/drm/card0/error says.
Created attachment 127249 [details] error As requested.
Fwiw, I've applied commit 35ca039e0a45fad3b15834059b4ad6697dbc7484 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 13 11:18:14 2016 +0100 drm/i915: Record the current requests queue for execlists upon hang to drm-intel-nightly that should give a little more detail into the hang (in the error state) here.
Since this is a regression, it would be really really helpful if you could bisect the regression for us. Can you please do this? Thanks, Paulo
OK, that took a long time, but looks like this is it: c58b735fc762e891481e92af7124b85cb0a51fce is the first bad commit commit c58b735fc762e891481e92af7124b85cb0a51fce Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Aug 18 17:16:57 2016 +0100 drm/i915: Allocate rings from stolen If we have stolen available, make use of it for ringbuffer allocation. Previously this was restricted to !llc platforms, as writing to stolen requires a GGTT mapping - but now that we have partial mappable support, the mappable aperture isn't quite so precious so we can use it more freely and ringbuffers are a good user for the otherwise wasted stolen. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-18-chris@chris-wilson.co.uk :040000 040000 1a77b1ba168a72106a74ae5ad3f28a49f40a88b0 2cf3076da77f4753071dfb926e391166a8532354 M drivers
@Chris: how exactly were you able to conclude that it's FBC that clobbers stolena and not the other stolen users? I'm interested in the details so I can investigate more.
Priority changed as regression w/o workaround
(In reply to Greg White from comment #6) > OK, that took a long time, but looks like this is it: > > c58b735fc762e891481e92af7124b85cb0a51fce is the first bad commit > commit c58b735fc762e891481e92af7124b85cb0a51fce > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Aug 18 17:16:57 2016 +0100 > > drm/i915: Allocate rings from stolen > > If we have stolen available, make use of it for ringbuffer allocation. > Previously this was restricted to !llc platforms, as writing to stolen > requires a GGTT mapping - but now that we have partial mappable support, > the mappable aperture isn't quite so precious so we can use it more > freely and ringbuffers are a good user for the otherwise wasted stolen. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Link: > http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-18- > chris@chris-wilson.co.uk > > :040000 040000 1a77b1ba168a72106a74ae5ad3f28a49f40a88b0 > 2cf3076da77f4753071dfb926e391166a8532354 M drivers Thanks a lot for bisecting this! It's really helpful for us! Can you please check if the patches located at https://people.freedesktop.org/~pzanoni/bug98213/ solve the problem for you? It would be really good if you could apply patch 1, then boot with drm.debug=0xe, reproduce the problem and attach dmesg to us. Also, in case you conclude that applying the 5 patches solves the problem for you, it would be important to discover which one of these patches alone solves the problem. Thanks! Paulo
Done. Updated dmesg attached. With the first patch only, it still reproduces. With all 5 applied, and enabled_fbc=1, everything seems fine.
Created attachment 127410 [details] Updated dmesg (first patch only - still failing)
OK, I ran through the patches 1-4. 1,2,3 alone all failed. 4 alone works. If you need me to test just 5, let me know.
(In reply to Greg White from comment #12) > OK, I ran through the patches 1-4. 1,2,3 alone all failed. 4 alone works. > > If you need me to test just 5, let me know. Thanks a lot for testing this! Can you please confirm if https://patchwork.freedesktop.org/patch/117250/ fixes the problem for you? This needs to be applied without the other 5 patches I provided.
OK, I reversed out 004 and applied your new patch. No problems - works great!
Patch merged to drm-intel-next-queued and marked for inclusion in stable. Closing bug. If the problem persists, please reopen. Thanks a lot for bisecting and testing the patches!
closing resolved+fixed. Verified by reporter.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.