On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote:
On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: > On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter daniel@ffwll.ch wrote: > > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: > >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer jwboyer@fedoraproject.org wrote: > >> > >> <snip> > >> > >> >> Xi Ruoyao (1): > >> >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb > >> > >> Turns out to be that commit. > >> > >> git bisect start 'drivers/gpu/drm/i915/' > >> # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Merge branch > >> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input > >> git bisect good b314acaccd7e0d55314d96be4a33b5f50d0b3344 > >> # bad: [bc465aa9d045feb0e13b4a8f32cc33c1943f62d6] Linux 4.0-rc5 > >> git bisect bad bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 > >> # bad: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] drm/i915: Ensure > >> plane->state->fb stays in sync with plane->fb > >> git bisect bad 319c1d420a0b62d9dbb88104afebaabc968cdbfa > >> # first bad commit: [319c1d420a0b62d9dbb88104afebaabc968cdbfa] > >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb > >> > >> Doing a straight revert on top of 4.0-rc5 makes things work again, > >> albeit with the WARN_ON(obj->frontbuffer_bits) splat still being > >> there. > > > > Can you please test the tip of drm-fixes: > > > > commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 > > Author: Daniel Vetter daniel.vetter@ffwll.ch > > Date: Fri Feb 27 12:58:13 2015 +0100 > > > > drm: Fixup racy refcounting in plane_force_disable > > > > http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=8218c3... > > > > Because fumble that patch didn't make it to drm-fixes a while ago and > > instead landed in drm-next. > > That seems to have helped with totally different issues a macbook I > have was seeing. However, it still doesn't fix the issue with the > Celeron based NUC machine. > > I built a kernel based on Linus' latest tree as of this morning, > without reverting 319c1d4 and adding the commit you pointed to. The > NUC still won't boot without HDMI connected. With HDMI connected I > still see the trace below. If I do the blacklist and then insmod > dance with HDMI unplugged it shows the same spew I reported yesterday > which starts with the same backtrace. > > I'll try building a kernel with 319c1d4 reverted + your patch. I > suspect things will work fine with that combination because the two > issues are unrelated.
Can you please boot with drm.debug=0xff for the below case and grab complete dmesg? There'll be a lot of crap in the logs, you might need to blow up the logbuf size massively. But that log should contain everything I need to figure out where that framebuffer we're blowing up on is going.
I provided both with HDMI attached and without (via insmod). If you want them emailed directly let me know, but they were large.
Boot with drm.debug=0xff and HDMI connected:
https://jwboyer.fedorapeople.org/pub/drm-ff-dmesg.txt
Boot with drm.debug=0xff without HDMI connected and i915 loaded via manual insmod after boot:
https://jwboyer.fedorapeople.org/pub/drm-ff-no-hdmi-insmod.txt
Here's one more from the macbook I mentioned. It's showing the same kref.h splat:
Ok there's at least one fixup for which we've failed to apply when porting the fb refcounting fix from -next. Can you please cherry-pick
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 Author: Damien Lespiau damien.lespiau@intel.com Date: Thu Feb 5 18:30:20 2015 +0000
drm/i915: Don't try to reference the fb in get_initial_plane_config()From linux-next?
Yes, building now. Will let you know as soon as I test it on both machines.
OK, with that commit applied I no longer get the kref.h splat and the NUC machine boots headless. I still see the backtrace below on both the NUC and the macbook. I have a copy of it with drm.debug=0xff from the NUC here:
https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
Getting better at least :).
On top of what you currently have please also cherry-pick
commit fb9981aa675eb7b398849915364916fd98833cfa Author: Damien Lespiau damien.lespiau@intel.com Date: Thu Feb 5 19:24:25 2015 +0000
drm/i915: Fix atomic state when reusing the firmware fb
from -next. Let's hope this terminates eventually ;-)
Thanks, Daniel