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_disablehttp://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
josh