On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them and I forgot to change.
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
I've got an HDMI device from the laboratory. I'll help to test the solution.
At least, my machine boots well and there is no WARNINGs in kernel log. I will do more tests.