Found the first bad commit. It was the one you suspected all along!
I will submit this issue upstream. Thanks for your invaluable help and demos!
Cheers
Andres
384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit
commit 384a48d71520ca569a63f1e61e51a538bedb16df
Author: Stephen Warren
Hi Andres,
Andres Cimmarusti wrote:
>> To be clear, are you saying "git bisect" told you that 76531d4166 was
>> the first bad commit?
>
> Not exactly. I told you I got confused on how to use git-bisect
My bad. I forgot I hadn't given the git bisect demo.
So, it works like this:
git bi
> To be clear, are you saying "git bisect" told you that 76531d4166 was
> the first bad commit?
Not exactly. I told you I got confused on how to use git-bisect, so I
didn't use it (I didn't understand how is it supposed to check each
commit, when another kernel is running). I simply used your firs
Andres Cimmarusti wrote:
> I found the patch that brings about the problem. It turns out it
> happened quite early in the 3.1 kernel merge window. This the commit
> that changes things:
>
> [...]76531d4166fb620375ff3c1ac24753265216d579
To be clear, are you saying "git bisect" told you that 76531d
Thanks for the git crash course. I did not look at 'git-bisect' too
much. It is more systematic, but how to test each commit confused me
some.
I found the patch that brings about the problem. It turns out it
happened quite early in the 3.1 kernel merge window. This the commit
that changes things:
Andres Cimmarusti wrote:
> How did you get that number you gave me before to use with git?
> basically I'm asking how do I get it for this patch ? I'm going to
> simply download the snapshot and try it for now. There are other
> suspicious patches submitted around the same time. I shall try them a
> Perhaps v3.1-rc2~4^2~47^2~89 (ALSA: hda: HDMI: Support codecs with
> fewer cvts than pins, 2011-07-01) is the problematic patch. Can you
> check this guess, like so?
That patch that you mention is included in the 3.0.x kernels as the
matter of fact. Thus I don't think it would have caused the p
Andres Cimmarusti wrote:
> I installed two kernels from snapshots. Using date 2012-02-01 I was
> able to pull in a 3.1.8 kernel that exhibited the same problem as
> kernels 3.2.x.
> I also used data 20111201 and pulled in a debian 3.0.x kernel. This
> one didn't have the problem (as in the case of
8 matches
Mail list logo
