https://bugs.freedesktop.org/show_bug.cgi?id=109135
--- Comment #11 from rmuncr...@humanavance.com ---
(In reply to iive from comment #10)
> (In reply to Alex Deucher from comment #9)
> > (In reply to rmuncrief from comment #8)
> > > (In reply to Alex Deucher from comment #7)
> > > > Can you bisect to figure out what commit broke things for you?
> > >
> > > Actually I remember doing that many years ago when I was a maintainer for
> > > Steam under wine. I'll look and see if I can find a current bisect
> > > tutorial
> > > and give it a try. Any links or tips you can give to help give me a quick
> > > start would be appreciated. I do remember it can take many days, which I'm
> > > willing to invest as I said. However the fewer days the better! :)
> >
> > It's pretty straight forward. Just google for "kernel git bisect howto".
>
> Bisecting between two major stable kernel versions is a nightmare.(Aka
> 4.18.0 - 4.19.0)
>
> Most of the new changes are done before RC1 and it is quite common that
> there are major breakages there, in systems we do not want to bother with.
> These breakages are usually fixed (or reverted) in later Release Candidates.
>
> It may be better to use some of the drm-next repositories, assuming that
> they hold all graphic changes that are going upstream, but are not rebased
> until the final release is done.
Yes, that's the kind of stuff I was worried about. I understand bisect is
simple in theory, but in practice there are usually a lot of problems.
And I already ran into my first and am redoing everything from scratch again. I
was able to cobble together a working PKGBUILD and tested it by compiling
4.18.20 from stable-branch git without any of the ARCH or Manjaro patches. I
did some quick tests with my compiled 4.18.20 to make sure it was working, and
then built 4.19.14 and made sure that one didn't work.
But when I went to do the first bisect it complained about uncommitted files
and aborted. I tried various things and eventually discovered that I probably
should have just executed "git stash", but by that time I couldn't be sure of
the integrity of the build so I just started all over again this morning.
However now I'm more confused because it seems you might be saying I should be
using a 4.19 release candidate instead of a stable build? Like I said, I'm
willing to put in substantial effort to help fix this problem, but I'd like to
waste the least amount of time possible. I also understand there are various
ways to speed things up by disabling unused kernel features, caching, etc. but
I'm from the old school of engineering and am hesitant to modify anything I'm
testing unless absolutely necessary. After all, since it's a completely unknown
problem there's no way to know what's causing it. It could very well be
something completely unexpected that has to do with components one wouldn't
normally consider.
And by the way, by "old school" I mean I started out as a hardware/firmware
designer when the most advanced processors were 8 bits running at 2Mhz! Yes,
that's right, I'm freakin' old! :)
In any case at this point if someone could tell me whether I should be
targeting a stable release or release candidate it would be helpful.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
