Grant Likely wrote:
> On 6/28/06, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
>>
>> The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>>
>> How can I find the individual patches that make up the transition
>> from 2.6.16.21 to 2.6.17 ?
>
> Unfortunately, there isn't a direct line between .16.21 and .17 which
> makes it complicated. Does your bsp work with .16? If so; you can
> use the 'git bisect' command to figure out exactly where the
> regression occured.
>
> If it doesn't work on .16; you can do a bisect between .16 and .16.21
> to figure out what patch is missing between .16 and .17.
>
> $ git bisect good v2.6.16
> $ git bisect bad # the head of the tree
> compile, test, etc.
> $ git bisect good|bad # depends on whether it works or not
> compile, test, etc
> $ git bisect good|bad # you get the idea... repeat until it's
> narrowed down
> $ git log # see where you are in the git tree.
Thanks,
At the moment I am not working out of a git tree - but I was
previously.
What I have works with everything from 2.6.15 through 2.6.16.21 -
or atleast the 15+ odd interim steps I tried.
It fails if I go from 2.6.16 to 2.6.17.
I can probably actually check into why it is not working - looks
alot like an ml403 mmu hang posted earlier (I am working with a Xilinx V4).
But I was hoping I could get away with brute force/divide and
conquer and isolate it to a single patch before actually trying to
figure out the problem.
I am going to have to get better at git.
>
> Cheers,
> g.
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii at dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
