lkml.org 
[lkml]   [2006]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: 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/
\
 
 \ /
  Last update: 2006-07-02 00:08    [W:0.065 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site