Re: Weird RAID/SATA problem [ once was Re: 2.6.17-mm3 ]

[Neil Brown]

On Saturday July 1, reuben-lkml@xxxxxxxx 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@xxxxxxx>

### 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/