On 02/28/2017 10:16 AM, Stephen Hemminger wrote:
> On Tue, 28 Feb 2017 09:06:13 -0800
> James Bottomley <jejb@xxxxxxxxxxxxxxxxxx> wrote:
>
>> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
>>> On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
>>>> On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
>>>>> Fixes: ee5242360424 ("scsi: zero per-cmd driver data before each
>>>>> I/O")
>>>>>
>>>>> but that is already in linux-next.
>>>>>
>>>>> Noticed another place where memset(of the data was being done not
>>>>> the extra bits.
>>>>> Tried this, but didn't fix it either...
>>>>
>>>> Are you using blk-mq or the legacy request code?
>>>
>>> Stephen doesn't have MQ set in the config he posted, I'm assuming he
>>> didn't boot with scsi_mod.use_blk_mq=true. In a previous email, I
>>> asked if turning on MQ makes a difference.
>>
>> OK, since we're not making much progress, Stephen, could you insert
>> some debugging into the storvsc driver? The trace clearly shows we're
>> getting zeros back in the buffer when we should have data from the
>> initial scan. Firstly, does the vmbus think it's transferring any data
>> for the INQUIRY and READ_CAPACITY commands (looks like
>> storvsc_command_completion() data_transfer_length)? If it does,
>> there's probably an issue initialising the sg list. If it doesn't,
>> we're probably sending bogus commands.
>>
>> James
>
> I tried booting with scsi_mod.use_blk_mq=true and that did nothing.
> Rebuilding now with
> CONFIG_SCSI_MQ_DEFAULT=y
If you already booted with scsi_mod.use_blk_mq=true and tested that,
then don't bother with the config option. They basically toggle
the same switch.
> Sure, can instrument. after that test.
That'd be great!
--
Jens Axboe
