On Sat, 2008-02-23 at 08:42 +0100, Mike Galbraith wrote:
> Meanwhile back at the ranch, reverting
> 6b00769fe1502b4ad97bb327ef7ac971b208bfb5
> 40b01b9bbdf51ae543a04744283bf2d56c4a6afa and the one entangled line from
> dde2020754aeb14e17052d61784dcb37f252aac2 did restore my burner.
It looks like the reason for boot failure with
40b01b9bbdf51ae543a04744283bf2d56c4a6afa may be that one hunk of
6b00769fe1502b4ad97bb327ef7ac971b208bfb5 was supposed to land in
40b01b9bbdf51ae543a04744283bf2d56c4a6afa (per comment);
diff --git a/block/blk-map.c b/block/blk-map.c
index a7cf63c..09f7fd0 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -154,6 +155,7 @@ int blk_rq_map_user(struct request_queue *q, struct request
*rq,
bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len;
bio->bi_size += pad_len;
+ rq->data_len += pad_len;
}
rq->buffer = rq->data = NULL;
Something else looks funny with
6b00769fe1502b4ad97bb327ef7ac971b208bfb5, did something go missing?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 135c1d0..ba21d97 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1014,10 +1014,6 @@ static int scsi_init_sgtable(struct request *req, struct
scsi_data_buffer *sdb,
}
req->buffer = NULL;
- if (blk_pc_request(req))
- sdb->length = req->data_len;
- else
- sdb->length = req->nr_sectors << 9;
/*
* Next, walk the list, and fill in the addresses and sizes of <== here
@@ -1026,6 +1022,10 @@ static int scsi_init_sgtable(struct request *req, struct
scsi_data_buffer *sdb,
count = blk_rq_map_sg(req->q, req, sdb->table.sgl);
BUG_ON(count > sdb->table.nents);
sdb->table.nents = count;
+ if (blk_pc_request(req))
+ sdb->length = req->data_len;
+ else
+ sdb->length = req->nr_sectors << 9;
return BLKPREP_OK;
}
--
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/
