> From: Christoph Hellwig [mailto:hch@xxxxxx] > Sent: Thursday, January 12, 2017 23:53 > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxx>; linux-block@xxxxxxxxxxxxxxx; Jens Axboe > <axboe@xxxxxx>; Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; KY Srinivasan <kys@xxxxxxxxxxxxx>; Chris Valean > (Cloudbase Solutions SRL) <v-chvale@xxxxxxxxxxxxx> > Subject: Re: [Regression] fstrim hangs on Hyper-V: caused by "block: improve > handling of the magic discard payload" > > Can you check if this debug printk triggers for the discard commands? > > --- > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > index 888e16e..7ab7d08 100644 > --- a/drivers/scsi/storvsc_drv.c > +++ b/drivers/scsi/storvsc_drv.c > @@ -1031,6 +1031,10 @@ static void storvsc_command_completion(struct > storvsc_cmd_request *cmd_request, > data_transfer_length = 0; > } > > + if (cmd_request->payload->range.len != data_transfer_length) > + printk_ratelimited("request len: %u, transfer len: %u\n", > + cmd_request->payload->range.len, > + data_transfer_length); > scsi_set_resid(scmnd, > cmd_request->payload->range.len - data_transfer_length); > // I fixed the small building issue (data_transfer_length ==> vm_srb->data_transfer_length). No, the printk doesn't trigger for fstrim. It does trigger at the early boot phase, though. # dmesg |grep len: [ 0.000000] log_buf_len: 134217728 bytes [ 7.073423] request len: 255, transfer len: 12 [ 7.084937] request len: 255, transfer len: 52 [ 7.121728] request len: 64, transfer len: 12 [ 7.121915] request len: 64, transfer len: 12 [ 7.123180] request len: 64, transfer len: 12 [ 7.123367] request len: 64, transfer len: 12 [ 7.127193] request len: 64, transfer len: 12 [ 7.127350] request len: 64, transfer len: 12 [ 7.178930] request len: 255, transfer len: 12 [ 7.179045] request len: 255, transfer len: 52 -- Dexuan -- 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