Em Wed, 17 Jul 2013 10:54:19 -0300
Alfredo Jesús Delaiti <alfredodela...@netscape.net> escreveu:
> Hi all
>
> El 15/07/13 17:30, Mauro Carvalho Chehab escribió:
> > Em Mon, 15 Jul 2013 16:30:18 -0300
> > Alfredo Jesús Delaiti <alfredodela...@netscape.net> escreveu:
> >
> >> Hi all
> >>
> >> After some time trying to see what the problem is, I have found it is
> >> not come the RF signal.
> >>
> >> I've gone back using a 3.2 kernel, after doing a couple of tests, the
> >> board works :-)
> >> When I try to apply these changes to a 3.4 or later kernel does not tune
> >> plate.
> >>
> >> Between 3.2 and 3.4 kernel there are several changes to the drivers:
> >> CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4
> >> kernel, but I can not make the card tune.
> > If you know already that the breakage happened between 3.2 and 3.4, the
> > better
> > is to use git bisect to discover what patch broke it.
>
> Mauro Thanks for the suggestion.
> This weekend I have some time and I'll study how to implement it.
>
> I guess it's do something similar to:
>
> ~ $ git clone git://linuxtv.org/media_build.git
> ~ $ cd media_build
> ~/media_build $./build --main-git
> ~/media_build $ cd media
> ~/media $ gedit drivers/media/video/foo.c
> ~/media $ make -C ../v4l
> ~/media $ make -C ../ install
> ~/media $ make -C .. rmmod
> ~/media $ modprobe foo
No. You'll need to clone the entire kernel tree (either Linus one or
mine).
The build system at the Kernel will rebuild an entire Kernel image.
You'll then need to boot that new image.
That takes some machine time, but, after the first compilation, the
subsequent compilations are faster.
I recommend you to use a minimal .config file for the compilation,
as this speeds up a lot the time to compile the Kernel.
Here, I use this small script to produce such mini-kernel:
http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig
After running it (and using the default for whatever question it
asks me), I do a make menuconfig, to be sure that the media
drivers and options I want are there.
In summary, what I suggest is:
$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git checkout v3.2
$ git bisect good
$ diet-kconfig
$ make menuconfig
select what is missed at media stuff
$ make && make modules install && make install & reboot
after reboot check if everything is ok
$ git bisect bad v3.4
repeat:
$ make && make modules install && make install & reboot
it will likely ask you about some new drivers = it is generally safe
to just let the default - just be more careful with the media
menuconfig items
test the kernel:
if OK:
$ git bisect good
if BAD:
$ git bisect bad
if git bisect answers that there are xxx bisects left, then goto repeat
After running the above, git bisect will put its fingers on the broken patch.
> >
> > You can do (using Linus git tree):
> >
> > git checkout v3.4
> > git bisect bad
> > git checkout good v3.2
>
> Where is the git tree of Linus in <git://git.kernel.org/> or
> <git://linuxtv.org/>?
>
> Thanks again,
>
> Alfredo
>
>
> >
> > git bisect will then do a binary search between those two kernels. All you
> > have to do is to recompile the Kernel and test it. Then you'll tag the
> > changeset as "bad" or "good", until the end of the search. In general,
> > you'll
> > discover the changeset responsible for the breakage after a few (8-10)
> > interactions.
> >
> > For more reference, you can take a look, for example, at:
> > http://git-scm.com/book/en/Git-Tools-Debugging-with-Git
> >
> > Regards,
> > Mauro
> >
> > PS.: Someone should fix our wiki, as it is still pointing to hg bisect,
> > instead of pointing to git bisect.
> >
> >> The changes I have applied to kernel 3.2 are:
> >
>
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
