<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - r600g (HD 6950 Cayman) fails piglit tests and hangs system" href="https://bugs.freedesktop.org/show_bug.cgi?id=62959#c53">Comment # 53</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - r600g (HD 6950 Cayman) fails piglit tests and hangs system" href="https://bugs.freedesktop.org/show_bug.cgi?id=62959">bug 62959</a> from <a class="email" href="mailto:alexandre.f.demers@gmail.com" title="Alexandre Demers <alexandre.f.demers@gmail.com>"> Alexandre Demers</a> <pre>(In reply to <a href="show_bug.cgi?id=62959#c52">comment #52</a>) > W.r.t. bisecting I found the info at <a href="http://webchick.net/node/99">http://webchick.net/node/99</a>. > Next week I do not have to go to work so I could give it a try. > Where do I get the sources from? > And what sha1's refer to all radeon commits in 3.7-rc1?? You will get the source from git.kernel.org. The first sync will take a while. Something like this should allow you to get the whole Linus linux tree into the linux-git folder: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git Your link seems about how to use git seems good. However, I would skip to bisecting since you already have a known good and a known bad versions. You'll have to sync your tree to a known good or bad version (assuming you didn't change the code or that you are willing to loose your changes): git reset --hard v3.7.5 You are now ready to bisect: git bisect start Tag this known bad version as "bad": git bisect bad This will tag the current version in the git tree as bad OR you can use "git bisect bad v3.7.5" to tag a specific tag. You can do the same with a specific commit Tag the known good version as "good": git bisect good v3.6.11 Git will do its work and let you know how many iterations will be needed to find the first bad commit. It will then sync to a new commit. You have to compile this kernel, install it and test it. Each time you are sure a given kernel is good or bad, you will have to tell git by using "git bisect good" or "git bisect bad". Git will move to the next iteration and you will have to configure, compile, install and test again until you end up identifying the first bad commit. The nearer you will get to the end of bisection, the faster it will be to configure and compile the kernel (less commits, thus less changes). Once you'll be done and you'll have reported the bad commit here, you'll have to stop bisecting and get back to where you started bisecting: git bisect reset</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>