From: Dave Airlie <airlied@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git pull] drm fixes for 5.7-rc8/final
Date: Fri, 29 May 2020 12:15:27 +1000 [thread overview]
Message-ID: <CAPM=9tza6oC3tBHaYq+nLGh0fwwZAKR3U-HVvn8jzN9myMz0dA@mail.gmail.com> (raw)
In-Reply-To: <CAPM=9ty5ce2mm7Di6qvRKy2Jg2Tw-Cd8U6ypN=Abc2NCGmQWWQ@mail.gmail.com>
On Fri, 29 May 2020 at 12:02, Dave Airlie <airlied@gmail.com> wrote:
>
> On Fri, 29 May 2020 at 11:49, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Thu, May 28, 2020 at 5:21 PM Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > Seems to have wound down nicely, a couple of i915 fixes, amdgpu fixes
> > > and minor ingenic fixes.
> >
> > Dave, this doesn't even build. WTF?
> >
> > In drivers/gpu/drm/i915/gt/selftest_lrc.c, there's a
> > engine_heartbeat_disable() function that takes two arguments, but the
> > new "live_timeslice_nopreempt()" gives it only one.
> >
> > I'd blame a merge problem, since the failure is in new code, but the
> > problem exists in your top-of-tree, not just my merge.
> >
> > In fact, it's not even your merge of the i915 tree that is the source
> > of the problem (although the fact that you clearly didn't _test_ the
> > end result most definitely is _part_ of the problem!).
> >
> > Because the problem exists in the commit that introduced that thing:
> > commit 1f65efb624c4 ("drm/i915/gt: Prevent timeslicing into
> > unpreemptable requests").
> >
> > It's garbage, and never compiled.
>
> I thought I'd dropped the ball completely. but I see it's a selftest
> failure, I must not have selftests built in my config here, I don't do
> exhaustive builds randconfig
>
> This has also been built by Intel, but I'm assuming they missed their
> selftest bits as well.
>
> I'll revert that and resend.
I did drop the ball in one way, I see sfr reported it broken this morning
I normally expect stuff coming from Intel has been through their CI,
even their fixes tree generally gets pushed through that system before
I get it, and it usually catches these things.
I might have to push back on intel fixes this late in the day, as
maybe the land on next and cherry-pick to fixes model has made them a
bit lax on how much stuff goes through CI.
I've just drop the whole i915 fixes from the tree and will resend with
it removed.
Dave.
next prev parent reply other threads:[~2020-05-29 2:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 0:21 [git pull] drm fixes for 5.7-rc8/final Dave Airlie
2020-05-29 1:49 ` Linus Torvalds
2020-05-29 2:02 ` Dave Airlie
2020-05-29 2:15 ` Dave Airlie [this message]
2020-05-29 13:32 ` Rodrigo Vivi
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='CAPM=9tza6oC3tBHaYq+nLGh0fwwZAKR3U-HVvn8jzN9myMz0dA@mail.gmail.com' \
--to=airlied@gmail.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).