lkml.org 
[lkml]   [2017]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()
    From
    Date
    On 12/05/17 06:16, Ming Lei wrote:
    > On Mon, Dec 04, 2017 at 11:48:07PM +0000, Holger Hoffstätte wrote:
    >> On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote:
    >>
    >>> On Mon, Dec 04, 2017 at 03:09:20PM +0000, Bart Van Assche wrote:
    >>>> On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote:
    >>>>> Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for blk-mq")
    >>>>
    >>>> It might be safer to revert commit 0df21c86bdbf instead of trying to fix all
    >>>> issues introduced by that commit for kernel version v4.15 ...
    >>>
    >>> What are all issues in v4.15-rc? Up to now, it is the only issue reported,
    >>> and can be fixed by this simple patch, which one can be thought as cleanup
    >>> too.
    >>
    >> Even with this patch I've encountered at least one hang that
    >> seemed related. I'm using most of block/scsi-4.15 on top of 4.14 and
    >> the hang in question was on a rotating disk. It could be solved by activating
    >> a different scheduler on the hanging device; all hanging sync/df processes got
    >> unstuck and all was fine again, which leads me to believe that there is at least
    >> one more rare condition where delaying requests (as done in the budget patch)
    >> leads to a hang.
    >>
    >> This happened with mq-deadline which I was testing specifically to avoid
    >> any BFQ-related side effects.
    >
    > OK, this looks a new report.
    >
    > Without any log, we can't make any progress, and even we can't guess
    > what the issue is related with.

    Considering that you just had an idea about a corner case and posted v2
    of the patch, it's safe to say that we actually can...which is why I
    described the situation exactly the way I did. :)

    I did try to get stack traces but all the hanging processes were
    simply stuck on the device mutex (deep inside btrfs), so nothing too
    helpful.

    > Could you post your dmesg log(include the hang process stack trace)? And
    > dump the debugfs log by the following script when this hang happens?
    >
    > http://people.redhat.com/minlei/tests/tools/dump-blk-info
    >
    > BTW, you just need to pass the disk name to the script, such as: /dev/sda.

    Thanks for the script. I'm now running with the new patch and will see what
    happens.

    cheers,
    Holger

    \
     
     \ /
      Last update: 2017-12-05 12:36    [W:4.641 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site