[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+5PVA7hiJCL3nKfvnaXZuwkP54jre9fqS=LSg0Z-=YqwcWMkQ@mail.gmail.com>
Date: Tue, 24 Mar 2015 09:57:54 -0400
From: Josh Boyer <jwboyer@...oraproject.org>
To: Daniel Vetter <daniel@...ll.ch>, Dave Airlie <airlied@...ux.ie>,
Xi Ruoyao <xry111@...look.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Subject: Re: [Intel-gfx] [git pull] drm fixes
On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter <daniel@...ll.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@...ll.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@...oraproject.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@...ll.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
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists