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
WARNING: multiple messages have this Message-ID (diff)
From: Josh Boyer <jwboyer@fedoraproject.org> To: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@linux.ie>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>, DRI mailing list <dri-devel@lists.freedesktop.org>, Xi Ruoyao <xry111@outlook.com>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-03-25 19:40 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-20 21:49 [git pull] drm fixes Dave Airlie 2015-03-20 21:49 ` Dave Airlie 2015-03-21 17:50 ` Linus Torvalds 2015-03-23 15:33 ` Josh Boyer 2015-03-23 15:33 ` Josh Boyer 2015-03-23 18:34 ` Josh Boyer 2015-03-23 18:34 ` Josh Boyer 2015-03-24 7:32 ` [Intel-gfx] " Daniel Vetter 2015-03-24 7:32 ` Daniel Vetter 2015-03-24 13:15 ` [Intel-gfx] " Josh Boyer 2015-03-24 13:15 ` Josh Boyer 2015-03-24 13:40 ` [Intel-gfx] " Daniel Vetter 2015-03-24 13:40 ` Daniel Vetter 2015-03-24 13:57 ` Josh Boyer 2015-03-24 13:57 ` Josh Boyer 2015-03-24 14:22 ` [Intel-gfx] " Josh Boyer 2015-03-24 14:22 ` Josh Boyer 2015-03-24 14:34 ` [Intel-gfx] " Daniel Vetter 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:10 ` Josh Boyer 2015-03-24 16:48 ` [Intel-gfx] " Daniel Vetter 2015-03-24 16:48 ` Daniel Vetter 2015-03-24 16:49 ` [Intel-gfx] " Daniel Vetter 2015-03-24 16:54 ` Josh Boyer 2015-03-25 3:49 ` Xi Ruoyao 2015-03-25 3:49 ` Xi Ruoyao 2015-03-25 8:54 ` [Intel-gfx] " Daniel Vetter 2015-03-25 8:54 ` Daniel Vetter 2015-03-25 13:11 ` [Intel-gfx] " Josh Boyer 2015-03-25 14:00 ` Daniel Vetter 2015-03-25 14:00 ` Daniel Vetter 2015-03-25 14:56 ` [Intel-gfx] " Xi Ruoyao 2015-03-25 14:56 ` Xi Ruoyao 2015-03-25 15:12 ` [Intel-gfx] " Xi Ruoyao 2015-03-25 15:12 ` Xi Ruoyao 2015-03-25 15:19 ` [Intel-gfx] " Jani Nikula 2015-03-25 15:19 ` Jani Nikula 2015-03-25 15:26 ` Takashi Iwai 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:50 ` Daniel Vetter 2015-03-25 15:53 ` Josh Boyer 2015-03-25 15:53 ` Josh Boyer 2015-03-25 16:42 ` [Intel-gfx] " Josh Boyer 2015-03-25 16:42 ` Josh Boyer 2015-03-25 17:17 ` [Intel-gfx] " Daniel Vetter 2015-03-25 17:17 ` Daniel Vetter 2015-03-25 17:37 ` [Intel-gfx] " Josh Boyer 2015-03-25 17:37 ` Josh Boyer 2015-03-25 19:40 ` Josh Boyer [this message] 2015-03-25 19:40 ` Josh Boyer 2015-03-25 23:32 ` [Intel-gfx] " Xi Ruoyao 2015-03-25 23:32 ` Xi Ruoyao 2015-03-25 23:45 ` [Intel-gfx] " Xi Ruoyao 2015-03-26 8:41 ` Xi Ruoyao 2015-03-26 8:41 ` Xi Ruoyao 2015-03-26 12:06 ` [Intel-gfx] " Jani Nikula 2015-03-26 12:06 ` Jani Nikula 2015-03-26 12:02 ` 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 8:56 ` Daniel Vetter 2015-03-25 14:34 ` Dave Jones 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 17:23 ` 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.