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.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx