Comment # 11
on bug 109135
from rmuncrief@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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
