(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 f=
or you?
> > >=20
> > > Actually I remember doing that many years ago when I was a m=
aintainer 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 gi=
ve me a quick
> > > start would be appreciated. I do remember it can take many d=
ays, which I'm
> > > willing to invest as I said. However the fewer days the bett=
er! :)
> >=20
> > It's pretty straight forward.  Just google for "kernel git b=
isect howto".
>=20
> Bisecting between two major stable kernel versions is a nightmare.(Aka
> 4.18.0 - 4.19.0)
>=20
> 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 w=
ith.
> These breakages are usually fixed (or reverted) in later Release Candi=
dates.

This is not always the case; in most cases bisects are pretty smooth.  If y=
ou
run into unrelated problems with a particular commit, you can always skip it
during the bisect (git bisect skip).