Messages in this thread Patch in this message | | | From | Neil Brown <> | Date | Sat, 1 Jul 2006 22:05:01 +1000 | Subject | Re: Weird RAID/SATA problem [ once was Re: 2.6.17-mm3 ] |
| |
On Saturday July 1, reuben-lkml@reub.net wrote: > > > > Only difference I can think of is still barriers... Does this patch > > make any difference? > > You will be happy to know that yes, it does make a difference. > > Applied to -mm4, RAID-1 now comes up with all arrays in sync and everything > looking good. Tried it twice, and both times raid-1 came up perfectly with > > md0 : active raid1 sdc2[1] sda2[0] > 24410688 blocks [2/2] [UU] > bitmap: 0/187 pages [0KB], 64KB chunk > > for each md. >
Cool.... so who is giving us that EIO. I'm guessing end_that_request_first or .._last, but where is it getting to there from?
What is you remove that last patch (so it still tries barrier writes) but add this patch (so WARN_ON gives us a trace when it happens).
Thanks, NeilBrown
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output ./drivers/md/md.c | 1 + 1 file changed, 1 insertion(+)
diff .prev/drivers/md/md.c ./drivers/md/md.c --- .prev/drivers/md/md.c 2006-07-01 12:12:14.000000000 +1000 +++ ./drivers/md/md.c 2006-07-01 22:00:57.000000000 +1000 @@ -412,6 +412,7 @@ static int super_written_barrier(struct if (bio->bi_size) return 1; + WARN_ON(error); if (!test_bit(BIO_UPTODATE, &bio->bi_flags) && error == -EOPNOTSUPP) { unsigned long flags; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |