Libata VIA woes continue. Worked around - *wrong*
Resending, there was a typo in the kernel address.
Date: Mon, 30 Aug 2004 07:45:52 -0700
From: Larry McVoy <[email protected]>
To: Jeff Garzik <[email protected]>
Cc: Brad Campbell <[email protected]>, [email protected],
[email protected], Larry McVoy <[email protected]>, Linus Torvalds <[email protected]>
Subject: Re: Libata VIA woes continue. Worked around - *wrong*
Quoted 7 lines
Since BK changesets are ordered as a progression, you can also do a bsearch by clone trees to specific changesets, such as
bk changes -rv2.6.6..2.6.7 >
/tmp/changes.txt# view changes.txt, pick out cset 1.1587.39.1 as your "top of tree" bk clone -r1.1587.39.1 vanilla-2.6 brad-test-2.6.6-bk # compile and test the kernel in brad-test-2.6.6-bk
A couple of comments:
- BK changesets are not a linear progression, they are in the form of a graph called a lattice. Getting a path through there that you can do binary search on is not straightforward.
- The CVS tree represents one such straight path, get just the ChangeSet file from the CVS tree and do an rlog on it - you are looking for the lines like:
BKrev: 41316382Cxbyp1_yHDX8LmymGot3Ww
That rev is the "md5key" of the BK rev and can be used anywhere a BK rev may be used (bk clone -r41316382Cxbyp1_yHDX8LmymGot3Ww ...)
- The biggest time saver is knowing where to look for your bug. If you knew that the bug was in drivers/scsi/libata-core.c then you could find each changeset which touched that file like so
$ bk rset -lv2.6.6 | grep drivers/scsi/libata-core.c drivers/scsi/libata-core.c|1.39
$ bk prs -hnd:I: -r1.39.. drivers/scsi/libata-core.c | while read rev do bk r2c -r$rev drivers/scsi/libata-core.c
done
That will crunch away and spit out (in this case) 63 revs like
1.1803.1.40
1.1803.1.39
1.1803.1.38
...
and a binary search over those revs is likely to be fair more fruitful because the history of that one file is pretty linear.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitkeeper.com