On Thu, Dec 05, 2013 at 02:52:34PM -0800, Kent Overstreet wrote: > that's a null pointer deref; if Matthias could get the exact line number it > happened on we could tell what variable was null. I _think_ it's *sg because > it's running off the end of the scatterlist; if that's the case (and you should > verify that that is what's happening, then what's going on is bcache is sending > down a bio larger than what the device expects. found the kernel config value CONFIG_DEBUG_BUGVERBOSE, tried again with 3.12.3 and 3.13-rc3. The backtrace now spells the line number: kernel BUG at drivers/scsi/scsi_lib.c:1048! 1028 static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb, 1029 gfp_t gfp_mask) 1030 { 1031 int count; 1032 1033 /* 1034 * If sg table allocation fails, requeue request later. 1035 */ 1036 if (unlikely(scsi_alloc_sgtable(sdb, req->nr_phys_segments, 1037 gfp_mask))) { 1038 return BLKPREP_DEFER; 1039 } 1040 1041 req->buffer = NULL; 1042 1043 /* 1044 * Next, walk the list, and fill in the addresses and sizes of 1045 * each segment. 1046 */ 1047 count = blk_rq_map_sg(req->q, req, sdb->table.sgl); 1048 BUG_ON(count > sdb->table.nents); 1049 sdb->table.nents = count; 1050 sdb->length = blk_rq_bytes(req); 1051 return BLKPREP_OK; 1052 } Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html