[Intel-gfx] [git pull] drm fixes

[Josh Boyer]

On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel at 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 at 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 at 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 at 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=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

Here's one more from the macbook I mentioned.  It's showing the same
kref.h splat:

https://jwboyer.fedorapeople.org/pub/drm-ff-macbook.txt

josh