Re: [PATCH] Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"

[Ulf Hansson <ulf.hansson@linaro.org>]

On 29 August 2018 at 16:01, Jens Axboe <axboe@kernel.dk> wrote:
> On 8/29/18 12:15 AM, Ulf Hansson wrote:
>> On 28 August 2018 at 21:11, Hunter, Adrian <adrian.hunter@intel.com> wrote:
>>>> -----Original Message-----
>>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>>> Sent: Tuesday, August 28, 2018 8:12 PM
>>>> To: Ian W MORRISON <ianwmorrison@gmail.com>
>>>> Cc: linux-block@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>> kashyap.desai@broadcom.com; loberman@redhat.com; osandov@fb.com;
>>>> hch@lst.de; bart.vanassche@wdc.com; hare@suse.de;
>>>> ming.lei@redhat.com; Hunter, Adrian <adrian.hunter@intel.com>
>>>> Subject: Re: [PATCH] Revert "blk-mq: issue directly if hw queue isn't busy in
>>>> case of 'none'"
>>>>
>>>> On 8/28/18 11:01 AM, Ian W MORRISON wrote:
>>>>> On Wed, 29 Aug 2018 at 02:13, Jens Axboe <axboe@kernel.dk> wrote:
>>>>>>
>>>>>> On 8/28/18 10:10 AM, Ian W MORRISON wrote:
>>>>>>> On Wed, 29 Aug 2018 at 02:09, Jens Axboe <axboe@kernel.dk> wrote:
>>>>>>>>
>>>>>>>> On 8/28/18 10:07 AM, Ian W MORRISON wrote:
>>>>>>>>> On Wed, 29 Aug 2018 at 01:48, Jens Axboe <axboe@kernel.dk>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/28/18 9:47 AM, Ian W MORRISON wrote:
>>>>>>>>>>> Kernel oops when booting on Bay and Cherry Trail devices such as
>>>>>>>>>>> Intel Compute Stick. Bisected as:
>>>>>>>>>>>
>>>>>>>>>>> commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't
>>>>>>>>>>> busy in case of 'none'")
>>>>>>>>>>>
>>>>>>>>>>> This patch reverts the above commit.
>>>>>>>>>>
>>>>>>>>>> Did I miss the posting of that oops? Just curious where this is
>>>>>>>>>> going wrong. Not adverse to reverting, but I'd like to try to
>>>>>>>>>> understand the issue first.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jens Axboe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've not been able to capture it however manually transcribing
>>>>>>>>> what is on the screen:
>>>>>>>>>
>>>>>>>>> mmc0: Got data interrupt 0x00000002 even though no data operation
>>>>>>>>>
>>>>>>>>> followed by:
>>>>>>>>>
>>>>>>>>> mmc0: sdhci: ============= SDHCI REGISTER DUMP
>>>> ==============
>>>>>>>>>
>>>>>>>>> Do you want any specific register value or should I transcribe
>>>>>>>>> each (as I am working from an image taken at boot)?
>>>>>>>>
>>>>>>>> Just take a picture of the screen, that should be good enough.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jens Axboe
>>>>>>>>
>>>>>>>
>>>>>>> Attached as requested.
>>>>>>
>>>>>> Can you see if this patch helps?
>>>>>>
>>>>>> https://marc.info/?l=linux-mmc&m=153485326025301&w=2
>>>>>>
>>>>>> --
>>>>>> Jens Axboe
>>>>>>
>>>>>
>>>>> I confirm that the above patch works with commit 6ce3dd6eec11 and
>>>>> removes the need for reverting it on eMMC based devices.
>>>>>
>>>>> Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake
>>>>> (not affected) devices.
>>>>
>>>> Great, thanks for testing. Adrian, when is this going upstream?
>>>
>>> It is in Ulf's fixes branch, so most likely v4.19-rc2 .  Then to stable in due course.
>>>
>>>         https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=26caddf274cf1e89fd4ce44ab2b8dbc7a7f97681
>>
>> Yep, correct!
>>
>> As I told someone before, I am deliberately holding on to fixes a
>> little longer that before, to extend the test coverage a bit.
>>
>> If someone wants to test the latest rc with fixes, one could instead
>> try the pending-fixes branch in Stephen Rothwell's linux-next tree.
>
> With all due respect, you should expedite this one so we're not
> wasting peoples time bisecting it again and again. I didn't even
> know about a pending-fixes branch in the linux-next tree, so I
> doubt most users will.

I guess it takes some time before people gets aware of the
pending-fixes branch. At least I managed to highlight its presence in
this thread. :-)

PR about to be created, I keep the folkz in this thread on cc once I post it.

Kind regards
Uffe