This is getting a well-known sight.
Earlier I tried to recognize some ASCII in this `want=' value,
but looking at the source, what is printed is
(sector + count)>>1
where
sector = bh->b_rsector;
count = bh->b_size >> 9;
Clearly one of these two values is bad.
Now the device 03:01 makes sense, so bh->b_rdev makes sense,
which means that bh itself is probably OK, and the buffer_head it
points to was overwritten or was set up with bad values.
Since the want= value is ridiculously large, and bh->b_size is shifted,
we know that at least bh->b_rsector is bad.
If all is well, bh->b_rsector is filled only in ll_rw_block() by
bh[i]->b_rsector=bh[i]->b_blocknr*(bh[i]->b_size >> 9);
but just a few lines before that we checked that bh[i]->b_size
is the right power of two (assuming the blksize_size array is
still good).
So, unless the buffer_head is corrupted for some reason this
means that the caller of ll_rw_block() asked for a bad blocknr.
We might want to add
printk(KERN_INFO "dev %s blksize=%d blocknr=%d sector=%d size=%d count=%d\n",
kdevname(bh->b_dev),
blksize_size[major][MINOR(bh->b_dev)],
bh->b_blocknr, bh->b_rsector, bh->b_size, bh->b_count);
after the printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n", ... b_rdev)]);
in make_request() in ll_rw_blk.c - just to make sure that all is OK
(no buffer_head corruption) and only b_blocknr is ridiculous.
As far as I recall, this kind of messages has mostly been reported by people
using FAT, where it may be [have been] a fs problem, and by people who
got this error together with other SCSI-related error messages.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/