On Mon, 2011-01-10 at 12:14 +1030, Arthur Marsh wrote: > This problem still occurs on kernel 2.6.37-git4. > > Is there a way to do a git-bisect when a particular commit is removed? > > When I did a > > git reset --hard v2.6.37 > git revert 541cc966915b6756e54c20eebe60ae957afdb537 > > and rebuilt the kernel I still had the problem, indicating that some > other commit in addition to 541cc966915b6756e54c20eebe60ae957afdb537 was > causing problems.
The only way I know of is to manually revert the commit before each test if necessary (beware that you need to pass something like HEAD^ to git bisect bad/good if you create a new commit with something like git revert). However, I'm afraid the bisected commit is completely unrelated to your problem[0], something probably went wrong during the bisect process. I suspect the problem may not always be immediately reproducible even with the faulty commit applied, so you may need to test more thoroughly before declaring a commit 'good'. [0] AFAICT from the information so far, it seems to be a failed attempt to map a BO which is currently located in the not-CPU-accessible part of VRAM. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
