linux-kernel - Re: 2.6.21-rc1: known regressions (part 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Mar 2007 17:12:35 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jens Axboe <jens.axboe@...cle.com>, Pavel Machek <pavel@....cz>,
	Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...lanox.co.il>,
	Thomas Gleixner <tglx@...utronix.de>, linux-pm@...ts.osdl.org,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Daniel Walker <dwalker@...sta.com>
Subject: Re: 2.6.21-rc1: known regressions (part 2)

On Thursday, 1 March 2007 15:52, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > hm. There's some weird bisection artifact here. Here are the commits i 
> > tested, in git-log order:
> > 
> > #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> > #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> > #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> > #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
> > 
> > if i tell git-bisect that #1 is bad and #3 is good, then it offers me 
> > #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - 
> > which is out of order! The bisection goes off into la-la land after 
> > that and never gets back to a commit that is /after/ the good commit. 
> > How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure 
> > this isnt some git bug that's already fixed.)
> > 
> > i'll try to straighten this out manually, perhaps #3 is in some merge 
> > branch that confuses bisection. Or maybe i misunderstood how 
> > git-bisect works.
> 
> git-bisect gets royally confused on those ACPI merge branches around 
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
> results so far:
> 
>  commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
>  commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
>  commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
>  commit c24e912b61b1ab2301c59777134194066b06465c: good
>  commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
>  commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
>  commit fc955f670c0a66aca965605dae797e747b2bef7d: good
>  commit 70c0846e430881967776582e13aefb81407919f1: good
>  commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
>  commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
>  commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
>  commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
>  commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
>  commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
>  commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
>  commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad
> 
> the results are totally reproducible (i re-tried a few of both the good 
> and the bad commits), i.e. it's not a sporadic condition. Also, a number 
> of the 'bad' commits have no dynticks stuff in them at all, so i'd 
> exclude dynticks.
> 
> could someone suggest a sane way to go with this? Perhaps suggest 
> specific commit IDs to test?

Hm, does 2.6.20-mm2 work?  If not, you can bisect the broken-out sereis
with quilt.

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/