On Thu, Feb 25, 2016 at 7:28 AM, John David Anglin <dave.anglin@xxxxxxxx> wrote:
> On 2016-02-24, at 4:36 PM, Helge Deller wrote:
>
>> Maybe Dave has more luck, otherwise I'll continue to try to get some info.
>
> I tried your patch on the commit in linux-block which first failed to boot. As with Helge, the
> system crashed and no useful data was output on console. I then applied following patch
> to give some extra segments and tired again:
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index b1a2631..b421f03 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -595,6 +595,11 @@ static int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, int nents, bool mq)
>
> BUG_ON(!nents);
>
> + /* Provide extra entries in case of split. */
> + nents += 8;
> + if (nents > SCSI_MAX_SG_SEGMENTS)
> + nents = SCSI_MAX_SG_SEGMENTS;
> +
Yeah, this is needed for sake of safety.
> if (mq) {
> if (nents <= SCSI_MAX_SG_SEGMENTS) {
> sdb->table.nents = nents;
>
> The attached file shows the crash in first boot. The second boot was successful and various output
> was generated by your check code.
>From the following log(just select one simple, and looks all are similar) in
2nd boot, the bi_phys_segments is figured out as one by block core
, which is wrong because the max segment size is 64k according to
your investigation in the below link, but the whole req/bio is 192k(4k*48).
http://www.spinics.net/lists/linux-parisc/msg06749.html
Looks weird, it shouldn't have happened because blk_bio_segment_split()
does respect the max segment size limit.
BTW, what is the scsi driver for the device?
blk_rq_map_sg: merge bug: 3 1, extra_len 0, dma_drain 0
check_bvec: dump bvec for 000000007e53c5f0(f:24490000, t:1)
0: 0 4096 245852 000000007e2c4c40
1: 0 4096 245853 000000007e2c4c40
2: 0 4096 245854 000000007e2c4c40
3: 0 4096 245855 000000007e2c4c40
4: 0 4096 245856 000000007e2c4c40
5: 0 4096 245857 000000007e2c4c40
6: 0 4096 245858 000000007e2c4c40
7: 0 4096 245859 000000007e2c4c40
8: 0 4096 245860 000000007e2c4c40
9: 0 4096 245861 000000007e2c4c40
10: 0 4096 245862 000000007e2c4c40
11: 0 4096 245863 000000007e2c4c40
12: 0 4096 245864 000000007e2c4c40
13: 0 4096 245865 000000007e2c4c40
14: 0 4096 245866 000000007e2c4c40
15: 0 4096 245867 000000007e2c4c40
16: 0 4096 245868 000000007e2c4c40
17: 0 4096 245869 000000007e2c4c40
18: 0 4096 245870 000000007e2c4c40
19: 0 4096 245871 000000007e2c4c40
20: 0 4096 245872 000000007e2c4c40
21: 0 4096 245873 000000007e2c4c40
22: 0 4096 245874 000000007e2c4c40
23: 0 4096 245875 000000007e2c4c40
24: 0 4096 245876 000000007e2c4c40
25: 0 4096 245877 000000007e2c4c40
26: 0 4096 245878 000000007e2c4c40
27: 0 4096 245879 000000007e2c4c40
28: 0 4096 245880 000000007e2c4c40
29: 0 4096 245881 000000007e2c4c40
30: 0 4096 245882 000000007e2c4c40
31: 0 4096 245883 000000007e2c4c40
32: 0 4096 245884 000000007e2c4c40
33: 0 4096 245885 000000007e2c4c40
34: 0 4096 245886 000000007e2c4c40
35: 0 4096 245887 000000007e2c4c40
36: 0 4096 245888 000000007e2c4c40
37: 0 4096 245889 000000007e2c4c40
38: 0 4096 245890 000000007e2c4c40
39: 0 4096 245891 000000007e2c4c40
40: 0 4096 245892 000000007e2c4c40
41: 0 4096 245893 000000007e2c4c40
42: 0 4096 245894 000000007e2c4c40
43: 0 4096 245895 000000007e2c4c40
44: 0 4096 245896 000000007e2c4c40
45: 0 4096 245897 000000007e2c4c40
46: 0 4096 245898 000000007e2c4c40
47: 0 4096 245899 000000007e2c4c40
Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
