Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

Am Mittwoch 01 September 2010 schrieb Paolo Ornati:
> On Tue, 31 Aug 2010 21:53:43 +0200
> 
> Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote:
> > Obviously I am not interested in kernels prior 2.6.33. Should I just
> > do a "git bisect good" without trying the kernel or is there some
> > other remedy?
> 
> No. Git is right in asking you to test that commit: you are ignoring
> branches and merges.
[...]
> So this this behaviour is normal :)

So as to the advice of Ted in the thread "stable? quality assurance?" I am 
seeking some more help with bisecting this bug. I continued bisecting and 
stumbled upon some problems:

Quite some kernels were unbootable with an ext4 and readahead related 
backtrace[1]. These were all within an USB merge and after skipping about 
five unbootable kernels I skipped the whole range of commits in it. I 
wondered by git insisted taking me back to this range of commits, even in 
the middle of two skips, instead of automatically re-adjusting the binary 
search, so that range would not be hit again for a while. Cause then its 
would have not been hit at all eventually. Anyway, I think this problem 
got fixed prior to 2.6.34 so I am asking whether there is a patch, a commit 
that fixed it in case I should stumble about such a unbootable kernel 
again. I attached the backtrace screenshot to my bug comment[1]. Ted, I am 
not booting from USB, but from the internal harddrive. I think these 
backtraces are completely unrelated to that USB commits. I think the bug 
has been introduced before that USB merge and fixed somewhen afterwards, 
but from a quick glance I didn't find the commit that fixes it.

I am also seeking help with selecting more suitable commits to test: If 
its a Radeon KMS related freeze and everything points at it, I think the 
offending commit is in the first quarter of what git commit shows to me[2]. 
Thus I'd  like to select one commit before those drm/kms related commits 
and one after it, before testing any other commits. But I have been fooled 
by those branches and merges before and there is the range of skipped 
commits in that USB merge, thus I'd like advice on which commits to 
select. A current git bisect log I attached to [2]. I will continue 
bisecting as usual for the time being, but I really appreciate some help, 
cause its still above 1800 commits to test otherwise and I am quite 
annoyed by seeing the same roughly 11 steps even if the absolute number of 
commits got down by about somewhat:

Bisecting: 1861 revisions left to test after this (roughly 11 steps)

[1] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c37
[2] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c38

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.