[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901

Marc Deop i Argemí damnshock at gmail.com
Wed Jun 16 10:45:34 CEST 2010


On Tuesday June 15 2010 23:23:42 Carl Worth wrote:
> On Tue, 15 Jun 2010 19:12:28 +0200, Marc Deop i Argemí <damnshock at gmail.com> 
wrote:
> > That looks like a lot of work, ain't it? :S
> 
> It shouldn't be, once you get the hang of compiling and running against
> a locally-compiled driver. There are about 176 commits between 2.11.0
> and 2.11.901 so that should only require about 8 compile/test cycles to
> determine what the buggy commit is.
> 
> > Anyway, I could give it a try but I must admit I don't know where to
> > start to look for the commits... can somebody give a hand on that?
> 
> Sure. Here's the recipe. First, checkout the driver from git with:
> 
> 	git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel
> 
> After that, compile it with something like:
> 
> 	cd xf86-video-intel
> 	./autogen.sh --prefix=/some/directory
>         make
>         make install
> 
> Then, you'll want to edit your xorg.conf file (likely
> /etc/X11/xorg.conf) to let it know about the new directory to which you
> installed this driver. So either add to the beginning of the Files
> section or make a new section named "Files" as follows:
> 
> 	Section "Files"
> 		ModulePath	"/some/directory/lib/xorg/modules"
> 		ModulePath	"/usr/lib/xorg/modules"
> 	EndSection
> 
> [Obviously you might use something other than "/some/directory" in both
> of the above commands. Use whatever directory you'd like there.]
> 
> At that point, you should be able to restart X and run with your
> custom-compiled driver. And when you're done with all this, you'll be
> able to undo the changes to return to using your system's driver.
> 
> Next, to do the bisect, the first thing to do is to ensure that things
> work with the 2.11.0 release. That's as follows:
> 
> 	git checkout 2.11.0
> 	./autogen.sh --prefix=/some/directory
>         make
>         make install
> 
> And then run the server. If it all works, then you're ready to
> bisect. Get back to master first with:
> 
> 	git checkout master
> 
> And then actually start bisecting with:
> 
> 	git bisect start
> 	git bisect bad master
>         git bisect good 2.11.0
> 
> At that point git will checkout an intermediate commit for you. So then
> it's time to compile and test, (same commands as before: autogen.sh,
> make, make install). If it works, run "git bisect good". If it doesn't,
> run "git bisect bad". Then git will checkout another intermediate commit
> and you continue the process.
> 
> In the end, if all goes well, git should report "first bad commit is..."
> and that's the information we'll want to know.
> 
> > Naaah, we are here to help ;)
> 
> Fantastic. Please let me know if any of the above is not clear.
> 
> -Carl

Thanks a lot for the explanation Carl. I also would like to give thank to give 
thanks to Brain0 of the irc on Freenode for his help.

About the time taking... well, the freeze doesn't happen instantly so I have 
to play around for a while :S

Anyway, I will try to bisect today and report back :)

Thanks again for your explanation,

Regards
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



More information about the Intel-gfx mailing list