On 12/01/2006 3:55 a.m., Jens Axboe wrote:
On Wed, Jan 11 2006, Jens Axboe wrote:
It's not too tricky, you just need to correct that function prototype.
Could you do that? Would be nice to know _exactly_ which libata
changeset caused this malfunction. But it does of course point at the
barrier changes for scsi/libata...
You can also try something quicker - use a newer kernel known to exhibit
the problem, and apply this patch on top of that:
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 0302723..720ace4 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -436,6 +436,7 @@ void md_super_write(mddev_t *mddev, mdk_
bio->bi_rw = rw;
atomic_inc(&mddev->pending_writes);
+#if 0
if (!test_bit(BarriersNotsupp, &rdev->flags)) {
struct bio *rbio;
rw |= (1<<BIO_RW_BARRIER);
@@ -444,6 +445,7 @@ void md_super_write(mddev_t *mddev, mdk_
rbio->bi_end_io = super_written_barrier;
submit_bio(rw, rbio);
} else
+#endif
submit_bio(rw, bio);
}
...and with that patch, I can now boot up 2.6.15-mm3 (repeated twice). So yes,
looks like that's where the problem lies.
Thanks Jens,
Reuben
-
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]
