Reuben Farrelly <[email protected]> wrote:
>
> On 11/01/2006 6:30 p.m., Andrew Morton wrote:
> > Andrew Morton <[email protected]> wrote:
> >> Reuben Farrelly <[email protected]> wrote:
> >>> I'm tempted to see if I can narrow it down to a specific -gitX release, maybe
> >>> that would narrow it down to say, 200 or so patches ;-)
> >> If -mm2 plus -mm2's linus.patch does not fail then
> >> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt will
> >> find the dud patch.
> >
> > Actually 2.6.15-mm1 would be a better one to do the bisection on: it has
> > all the md- patches separated out.
>
> I've done some more testing - which may change the suggested approach somewhat..
>
> 2.6.15-mm1 is OK, I'm running it now, rebooted probably 15 times and it's come
> up every time.
> 2.6.15-git2 is OK, booted up to completion (tested once).
> 2.6.15-git3 was a dud, bootup hung
Ah.
> 2.6.15- [linus.patch from -mm2, which is basically the same as -git3] won't boot
> 2.6.15-mm2 doesn't boot either, tested many times
> 2.6.15-git6 won't boot
> 2.6.15-git7 got stuck also, same issue
>
> So some change that went in between -git2 and -git3 seems to have caused it.
> Nothing from -git3 onwards has ever booted to completion.
>
> Is there any chance a patch came in, was queued in -mm but was never released in
> any -mm (1|2) release before being sent to Linus/-gitX? (in this case, -git3).
Yes, people sneak stuff in at the last minute.
Neil thinks that an IO got lost. In the git2->git3 diff we have:
b/drivers/scsi/Kconfig | 10
b/drivers/scsi/ahci.c | 1
b/drivers/scsi/ata_piix.c | 5
b/drivers/scsi/libata-core.c | 145 +
b/drivers/scsi/libata-scsi.c | 48
b/drivers/scsi/libata.h | 4
b/drivers/scsi/sata_mv.c | 1
b/drivers/scsi/sata_promise.c | 1
b/drivers/scsi/sata_sil.c | 1
b/drivers/scsi/sata_sil24.c | 1
b/drivers/scsi/sata_sx4.c | 1
b/drivers/scsi/scsi_lib.c | 50
b/drivers/scsi/scsi_sysfs.c | 31
b/drivers/scsi/sd.c | 85 -
b/fs/bio.c | 26
Jens, Jeff: were any of those changes added in the final day or two, not
included in the trees which I pull?
>
> I'm not sure where this leaves quilt testing. Would quilt testing just narrow
> me down to it being the linus.patch in mm which actually caused it? (Which I
> already know is the source)..
Yes, there's not much point in that.
`git bisect' will find it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
