Good Morning,

On 07/30/2018 09:38 PM, Ming Lei wrote:
> Hi Peter,
> 
> Thanks for collecting the log.
> 
> On Mon, Jul 30, 2018 at 02:55:42PM -0400, Peter Geis wrote:
>>
>>
>> On 07/28/2018 09:37 AM, Ming Lei wrote:
> 
> ...
> 
>> [   10.887209] systemd--112     0.n.1 2411122us : blk_mq_make_request: make
>> rq -1
>> [   10.890274] kworker/-98      0...1 2411506us : blk_mq_free_request:
>> complete: rq -1
>> [   10.893313] systemd--107     0...1 2412025us : blk_mq_make_request: make
>> rq -1
>> [   10.896354] systemd--107     0.... 2412323us : mmc_mq_queue_rq: queue rq
>> -1, 0
>> [   10.899388] systemd--107     0.... 2412327us :
>> blk_mq_try_issue_list_directly: issue direct: rq -1, ret 0
>> [   10.902463] (direxec-111     1...1 2413829us : blk_mq_make_request: make
>> rq -1
>> [   10.905513] systemd--114     1...1 2415159us : blk_mq_make_request: make
>> rq -1
> 
> Above is the most interesting part in the log. MMC sets hw queue depth
> as 1, and you are using none scheduler, that means the max number of
> in-flight requests should be one, but the above log shows that there may
> be 3 in-flight requests.

That's odd, I have CFQ set as the default, is something changing this 
during boot?
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_IOSCHED="cfq"

> 
> That seems really weird, but it shouldn't be related with my two patches,
> which won't change the tag allocation behaviour at all. However, what matters
> may be that the patch speeds up the request dispatch. Maybe one bug
> in lib/sbitmap.c block/blk-mq-tag.c.
> 
> Unfortunately rq->tag wasn't shown in the log because I forget to dump
> it in the debug patch, so could you apply the following new debug patch and
> provide us the log again? BTW, please attach the ftrace log in the reply
> mail directly, then it may be parsed/looked easily.

I have resynced to the latest linux-next and applied your new patch.
The log is attached.

Of note, it took several boots this time before it would progress to 
where I could grab the log.
Instead it was blocking the moment RW was requested.
Also of note, it seems only the emmc is affected, the SD card (mmcblk2) 
does not trigger any errors.