All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.