Messages in this thread | | | From | Martin Steigerwald <> | Subject | Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes | Date | Sun, 5 Sep 2010 09:53:41 +0200 |
| |
Am Mittwoch 01 September 2010 schrieb Paolo Ornati: > On Tue, 31 Aug 2010 21:53:43 +0200 > > Martin Steigerwald <Martin@lichtvoll.de> 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 [unhandled content-type:application/pgp-signature] | |