From: Josh Boyer <jwboyer@fedoraproject.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@linux.ie>, Xi Ruoyao <xry111@outlook.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [git pull] drm fixes
Date: Wed, 25 Mar 2015 15:40:14 -0400 [thread overview]
Message-ID: <20150325194014.GA24556@vader> (raw)
In-Reply-To: <CA+5PVA4hEa21EBHuxHb2Z+FCmfRwFuyK0Z=Zv=pvqmJBuZVN6Q@mail.gmail.com>
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>> >> Yeah that fail looks like we're freeing an fb that's still in use.
>>> >> Hilarity happens and since that happens under console_lock at boot-up your
>>> >> machine dies.
>>> >>
>>> >> Does that machine die the same way in drm-intel-nightly/linux-next?
>>> >
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build. The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more. I'll let you know if that fixes
>>> > anything. Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first. It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel. Confused. Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> + primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
>Hey, that seems to do the trick on the NUC machine. Boots without
>HDMI connected and there are no backtraces. Nice!
>
>Let me go and munge it around for a backport on top of -rc5 with the
>rest of the pile and see if both the macbook and NUC machines work
>then. Will be a bit for it to build.
OK, that helped on all my machines I have. No backtraces and they all
boot again as I would expect. For the record, here is what I have on
top of -rc5:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 177714a9d778..778e7fa41c17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2439,6 +2439,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
return;
if (intel_alloc_plane_obj(intel_crtc, plane_config)) {
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
update_state_fb(intel_crtc->base.primary);
return;
}
@@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
drm_framebuffer_reference(c->primary->fb);
intel_crtc->base.primary->fb = c->primary->fb;
+ intel_crtc->base.primary->state->crtc = &intel_crtc->base;
+ intel_crtc->base.primary->crtc = &intel_crtc->base;
obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
next prev parent reply other threads:[~2015-03-25 19:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 21:49 [git pull] drm fixes Dave Airlie
2015-03-21 17:50 ` Linus Torvalds
2015-03-23 15:33 ` Josh Boyer
2015-03-23 18:34 ` Josh Boyer
2015-03-24 7:32 ` [Intel-gfx] " Daniel Vetter
2015-03-24 13:15 ` Josh Boyer
2015-03-24 13:40 ` Daniel Vetter
2015-03-24 13:57 ` Josh Boyer
2015-03-24 14:22 ` Josh Boyer
2015-03-24 14:34 ` Daniel Vetter
2015-03-24 14:46 ` Josh Boyer
2015-03-24 16:10 ` Josh Boyer
2015-03-24 16:48 ` Daniel Vetter
2015-03-24 16:49 ` Daniel Vetter
2015-03-24 16:54 ` Josh Boyer
2015-03-25 3:49 ` Xi Ruoyao
2015-03-25 8:54 ` Daniel Vetter
2015-03-25 13:11 ` Josh Boyer
2015-03-25 14:00 ` Daniel Vetter
2015-03-25 14:56 ` Xi Ruoyao
2015-03-25 15:12 ` Xi Ruoyao
2015-03-25 15:19 ` Jani Nikula
2015-03-25 15:26 ` Takashi Iwai
2015-03-25 15:37 ` Josh Boyer
2015-03-25 15:50 ` Daniel Vetter
2015-03-25 15:53 ` Josh Boyer
2015-03-25 16:42 ` Josh Boyer
2015-03-25 17:17 ` Daniel Vetter
2015-03-25 17:37 ` Josh Boyer
2015-03-25 19:40 ` Josh Boyer [this message]
2015-03-25 23:32 ` Xi Ruoyao
2015-03-25 23:45 ` Xi Ruoyao
2015-03-26 8:41 ` Xi Ruoyao
2015-03-26 12:06 ` Jani Nikula
2015-03-26 12:02 ` Jani Nikula
2015-03-24 1:41 ` Dave Jones
2015-03-25 8:56 ` Daniel Vetter
2015-03-25 14:34 ` Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2015-02-27 4:42 Dave Airlie
2015-03-01 5:40 ` Linus Torvalds
2015-03-01 6:08 ` Linus Torvalds
2015-03-01 7:27 ` Linus Torvalds
2015-03-01 20:35 ` Linus Torvalds
2015-03-01 21:00 ` Linus Torvalds
2015-03-02 1:59 ` Linus Torvalds
2015-03-02 9:04 ` Daniel Vetter
2015-03-02 16:53 ` Linus Torvalds
2015-03-02 17:23 ` [Intel-gfx] " Daniel Vetter
2015-03-02 9:44 ` Paul Bolle
2015-03-02 10:33 ` [Intel-gfx] " Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150325194014.GA24556@vader \
--to=jwboyer@fedoraproject.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=xry111@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox