From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [git pull] drm fixes for 5.7-rc8/final
Date: Fri, 29 May 2020 06:32:58 -0700 [thread overview]
Message-ID: <20200529133258.GA701871@intel.com> (raw)
In-Reply-To: <CAPM=9tza6oC3tBHaYq+nLGh0fwwZAKR3U-HVvn8jzN9myMz0dA@mail.gmail.com>
On Fri, May 29, 2020 at 12:15:27PM +1000, Dave Airlie wrote:
> 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.
Yes, that was my fault. I also didn't have the selftest on my drm-intel-fixes
build and I confused the build run numbers when checking the
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html?
before sending...
If we have another round next week I will make sure CI runs well before
sending another pull request.
Sorry,
Rodrigo.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [git pull] drm fixes for 5.7-rc8/final
Date: Fri, 29 May 2020 06:32:58 -0700 [thread overview]
Message-ID: <20200529133258.GA701871@intel.com> (raw)
In-Reply-To: <CAPM=9tza6oC3tBHaYq+nLGh0fwwZAKR3U-HVvn8jzN9myMz0dA@mail.gmail.com>
On Fri, May 29, 2020 at 12:15:27PM +1000, Dave Airlie wrote:
> 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.
Yes, that was my fault. I also didn't have the selftest on my drm-intel-fixes
build and I confused the build run numbers when checking the
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html?
before sending...
If we have another round next week I will make sure CI runs well before
sending another pull request.
Sorry,
Rodrigo.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-29 13:34 UTC|newest]
Thread overview: 10+ 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 0:21 ` Dave Airlie
2020-05-29 1:49 ` Linus Torvalds
2020-05-29 1:49 ` Linus Torvalds
2020-05-29 2:02 ` Dave Airlie
2020-05-29 2:02 ` Dave Airlie
2020-05-29 2:15 ` Dave Airlie
2020-05-29 2:15 ` Dave Airlie
2020-05-29 13:32 ` Rodrigo Vivi [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=20200529133258.GA701871@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=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=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 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.