[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Apr 23 19:31:13 PDT 2013


https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #53 from Alexandre Demers <alexandre.f.demers at gmail.com> ---
(In reply to comment #52)
> W.r.t. bisecting I found the info at http://webchick.net/node/99.
> 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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130424/09aa0966/attachment.html>


More information about the dri-devel mailing list