On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxx> >> > 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=8218c3f4df3bb1c637c17552405039a6dd3c1ee1 >> > >> > 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 josh _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
