[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1512490603.2660.13.camel@sandisk.com>
Date: Tue, 5 Dec 2017 16:16:44 +0000
From: Bart Van Assche <Bart.VanAssche@....com>
To: "osandov@...ndov.com" <osandov@...ndov.com>,
"jthumshirn@...e.de" <jthumshirn@...e.de>,
"ming.lei@...hat.com" <ming.lei@...hat.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"hch@...radead.org" <hch@...radead.org>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"axboe@...com" <axboe@...com>, "hare@...e.com" <hare@...e.com>,
"holger@...lied-asynchrony.com" <holger@...lied-asynchrony.com>,
"jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>
Subject: Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and
queue is idle
On Tue, 2017-12-05 at 15:29 +0100, Johannes Thumshirn wrote:
> 1) Testing without the patch applied hangs the test forever as it
> doesn't get killed after a specific timeout (I think this should be
> solved in a common function).
Hello Johannes,
If a request queue got stuck then the processes that submitted the requests
on that queue are unkillable. The only approach I know of to stop these
processes is to send a kill signal and next to trigger a queue run from user
space. One possible approach is to run the following command:
for d in /sys/kernel/debug/block/*; do echo kick >$d/state; done
Bart.
Powered by blists - more mailing lists