Hello
On 1/18/19 8:10 PM, Marc Gonzalez wrote:
> Hello,
>
> I'm running into an issue which I don't know how to debug.
> So I'm open to ideas and suggestions :-)
>
> On my arm64 board, I have enabled Universal Flash Storage support.
>
> I wanted to benchmark read performance, and noticed that t
Hello
On 1/21/19 11:22 PM, Marc Gonzalez wrote:
> Well, now we know for sure that the clk_scaling_lock is a red herring.
> I applied the patch below, and still the system locked up:
>
> # dd if=/dev/sde of=/dev/null bs=1M status=progress
> 3892314112 bytes (3.9 GB, 3.6 GiB) copied, 50.0042 s, 77.
On 1/22/19 6:59 PM, Marc Gonzalez wrote:
> On 22/01/2019 04:12, Jianchao Wang wrote:
>
>> On 1/21/19 11:22 PM, Marc Gonzalez wrote:
>>
>>> Well, now we know for sure that the clk_scaling_lock is a red herring.
>>> I applied the patch below, and still the system locked up:
>>>
>>> # dd if=/dev/s
On 1/25/19 9:33 AM, Ming Lei wrote:
> On Fri, Jan 25, 2019 at 8:45 AM Florian Stecker
> wrote:
>>
>>
>>
>> On 1/22/19 4:22 AM, Ming Lei wrote:
>>> On Tue, Jan 22, 2019 at 5:13 AM Florian Stecker
>>> wrote:
Hi everyone,
on my laptop, I am experiencing occasional hangs of a
On 1/25/19 4:56 PM, Florian Stecker wrote:
> On 1/25/19 4:49 AM, jianchao.wang wrote:
>>
>> It sounds like not so easy to trigger.
>>
>> blk_mq_dispatch_rq_list
>> scsi_queue_rq
>> if (atomic_read(&sdev->device_busy) ||
>&g
On 1/26/19 6:10 AM, Florian Stecker wrote:
>
>
> On 1/25/19 10:05 AM, jianchao.wang wrote:
>>
>>
>> On 1/25/19 4:56 PM, Florian Stecker wrote:
>>> On 1/25/19 4:49 AM, jianchao.wang wrote:
>>>>
>>>> It sounds like not so easy to trigg
On 1/26/19 9:18 AM, jianchao.wang wrote:
>
>
> On 1/26/19 6:10 AM, Florian Stecker wrote:
>>
>>
>> On 1/25/19 10:05 AM, jianchao.wang wrote:
>>>
>>>
>>> On 1/25/19 4:56 PM, Florian Stecker wrote:
>>>> On 1/25/19 4:49 AM, jian
On 1/26/19 11:37 PM, Florian Stecker wrote:
>
>
> On 1/26/19 2:25 AM, jianchao.wang wrote:
...
>>>>
>>>> dmesg:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__florianstecker.de_dmesg-2D2019-2D01-2D25.txt&d=DwIDaQ&c=RoP1YumCX
Hi Florian
On 1/28/19 10:42 AM, jianchao.wang wrote:
> diff --git a/block/blk-flush.c b/block/blk-flush.c
> index a3fc7191..6e0f2d9 100644
> --- a/block/blk-flush.c
> +++ b/block/blk-flush.c
> @@ -335,7 +335,7 @@ static void mq_flush_data_end_io(struct request *rq,
>
ary 30, 2019 2:13:14 AM GMT+01:00, "jianchao.wang"
> wrote:
>> Hi Florian
>>
>> On 1/28/19 10:42 AM, jianchao.wang wrote:
>>> diff --git a/block/blk-flush.c b/block/blk-flush.c
>>> index a3fc7191..6e0f2d9 100644
>>> --- a/block/blk-flush.c
Hi Ming
On 3/21/19 11:55 AM, Ming Lei wrote:
> On Thu, Mar 21, 2019 at 11:21:20AM +0800, zhengbin wrote:
>> When I use dd test a SCSI device which use blk-mq in the following steps:
>> 1.echo "blocked" >/sys/block/sda/device/state
>> 2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
>> 3.echo "running
Hi Bart
Thanks for your kindly response.
On 02/27/2018 11:08 AM, Bart Van Assche wrote:
> On Mon, 2018-02-26 at 15:58 +0800, Jianchao Wang wrote:
>> In scsi core, __scsi_queue_insert should just put request back on
>> the queue and retry using the same command as before. However, for
>> blk-mq, s
Hi Bart
Thanks for your kindly response.
On 02/27/2018 11:41 AM, Bart Van Assche wrote:
> On Tue, 2018-02-27 at 11:28 +0800, jianchao.wang wrote:
>> If that is true, what if aacraid driver uses block legacy instead of blk-mq ?
>> w/ blk-mq disabled, __scsi_queue_insert just requ
Hi Bart
Thanks for your kindly response.
On 02/27/2018 01:12 PM, Bart Van Assche wrote:
> On Tue, 2018-02-27 at 12:00 +0800, jianchao.wang wrote:
>> On the other hand, this patch is to align the actions between blk-mq and
>> block
>> legacy code in __scsi_queue_insert
Hi Bart
Thanks for your kindly response and precious time to review this.
On 02/28/2018 01:18 AM, Bart Van Assche wrote:
> On Tue, 2018-02-27 at 17:06 +, Bart Van Assche wrote:
>> On Tue, 2018-02-27 at 13:15 +0800, jianchao.wang wrote:
>>> Can you share more details about t
Hi Bart
Thanks for your precious time to review this and kindly detailed response.
On 03/01/2018 01:52 AM, Bart Van Assche wrote:
> On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a86df9c..6fa7b0c 100644
>> --- a/d
Hi Bart
Thanks for your precious time and detailed summary.
On 03/02/2018 01:43 AM, Bart Van Assche wrote:
> Yes, the block layer core guarantees that scsi_mq_get_budget() will be called
> before scsi_queue_rq(). I think the full picture is as follows:
> * Before scsi_queue_rq() calls .queuecomma
Hi martin
Thanks for your kindly response.
On 03/02/2018 09:43 AM, Martin K. Petersen wrote:
>
> Jianchao,
>
>> Yes, the block layer core guarantees that scsi_mq_get_budget() will be
>> called before scsi_queue_rq(). I think the full picture is as follows:
>
>> * Before scsi_queue_rq() calls .
Hi martin
On 03/02/2018 09:44 AM, Martin K. Petersen wrote:
>> In scsi core, __scsi_queue_insert should just put request back on the
>> queue and retry using the same command as before. However, for blk-mq,
>> scsi_mq_requeue_cmd is employed here which will unprepare the
>> request. To align with
Hi Bart
Thanks for your kindly response and directive.
On 03/03/2018 12:31 AM, Bart Van Assche wrote:
> On Fri, 2018-03-02 at 11:31 +0800, Jianchao Wang wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a86df9c..d2f1838 100644
>> --- a/drivers/scsi/scsi_lib.c
>> ++
Hi Martin
Can you take your precious time to review this ?
Thanks in advice.
Jianchao
On 03/03/2018 09:54 AM, Jianchao Wang wrote:
> In scsi core, __scsi_queue_insert should just put request back on
> the queue and retry using the same command as before. However, for
> blk-mq, scsi_mq_requeue_cm
Would anyone please take a review at this patch ?
Thanks in advace
Jianchao
On 03/07/2018 08:29 PM, Jianchao Wang wrote:
> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going w
Hi Ming
Why not add percpu_ref_tryget/put pair into run queue and requeue work,
or before queue the work ?
Then freezing queue could really implement to freeze the queue and there will be
no any queue activity after freeze, including run queue and requeue work.
Thanks
Jianchao
On 4/4/19 4:43 PM
Hi Ming
On 09/13/2018 08:15 PM, Ming Lei wrote:
> EXPORT_SYMBOL(__scsi_execute);
> @@ -3246,6 +3251,7 @@ static int scsi_internal_device_block(struct
> scsi_device *sdev)
> else
> scsi_wait_for_queuecommand(sdev);
> }
> + wait_event(sdev->admin_wq, !
Hi Ming
On 09/14/2018 07:33 PM, Ming Lei wrote:
> On Fri, Sep 14, 2018 at 11:40 AM jianchao.wang
> wrote:
>>
>> Hi Ming
>>
>> On 09/13/2018 08:15 PM, Ming Lei wrote:
>>> EXPORT_SYMBOL(__scsi_execute);
>>> @@ -3246,6 +3251,7 @@ static int scsi_int
Hi Ming
On 09/17/2018 07:35 PM, Ming Lei wrote:
> On Mon, Sep 17, 2018 at 10:46:34AM +0800, jianchao.wang wrote:
>> Hi Ming
>>
>> On 09/14/2018 07:33 PM, Ming Lei wrote:
>>> On Fri, Sep 14, 2018 at 11:40 AM jianchao.wang
>>> wrote:
>>>>
>
On 09/18/2018 03:39 PM, Ming Lei wrote:
> On Tue, Sep 18, 2018 at 09:22:32AM +0800, jianchao.wang wrote:
>> Hi Ming
>>
>> On 09/17/2018 07:35 PM, Ming Lei wrote:
>>> On Mon, Sep 17, 2018 at 10:46:34AM +0800, jianchao.wang wrote:
>>>> Hi Ming
>&g
On 09/18/2018 03:55 PM, Ming Lei wrote:
> On Tue, Sep 18, 2018 at 03:51:10PM +0800, jianchao.wang wrote:
>>
>>
>> On 09/18/2018 03:39 PM, Ming Lei wrote:
>>> On Tue, Sep 18, 2018 at 09:22:32AM +0800, jianchao.wang wrote:
>>>> Hi Ming
>>>>
Hi Ming
On 09/18/2018 08:15 PM, Ming Lei wrote:
> The adminq request can be quisced in the scsi_device level, just as normal IO
> request, because the scsi_device instance is same with normal IO.
Yes, the scsi_queue_rq->scsi_prep_state_check could gate things out of.
>
> But in blk-mq level, th
On 11/14/18 12:35 PM, Ming Lei wrote:
> c2856ae2f315d ("blk-mq: quiesce queue before freeing queue") has
> already fixed this race, however the implied synchronize_rcu()
> in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
> performance regression.
>
> Then 1311326cf4755c7 ("blk
Would anyone please take a review on this ?
Thanks in advance
Jianchao
On 04/10/2018 04:48 PM, Jianchao Wang wrote:
> If the cmd has not be returned after aborted by qla2x00_eh_abort,
> we have to wait for it. However, the time is 1000ms at least currently.
> If there are a lot cmds need to be ab
Hi all
Our customer met a panic triggered by BUG_ON in blk_finish_request.
>From the dmesg log, the BUG_ON was triggered after command abort occurred many
>times.
There is a race condition in the following scenario.
cpu A cpu B
kworker
Would anyone please take a look at this ?
Thanks in advance
Jianchao
On 05/23/2018 11:55 AM, jianchao.wang wrote:
>
>
> Hi all
>
> Our customer met a panic triggered by BUG_ON in blk_finish_request.
>>From the dmesg log, the BUG_ON was triggered after command abort o
at this issue.
>
> Thanks,
> Himanshu
>
>> -Original Message-
>> From: jianchao.wang [mailto:jianchao.w.w...@oracle.com]
>> Sent: Wednesday, May 23, 2018 6:51 PM
>> To: Dept-Eng QLA2xxx Upstream ; Madhani,
>> Himanshu ; jthumsh...@suse.de
>>
llected for us to look at this in details.
>
> Can you provide me crash/vmlinux/modules for details analysis.
>
> Thanks,
> himanshu
>
> On 5/24/18, 6:49 AM, "Madhani, Himanshu" wrote:
>
>
> > On May 24, 2018, at 2:09 AM, jianchao.wan
Hi
[1.] One line summary of the problem:
scsi_done from qla2x00_sp_compl race with scsi_queue_insert from
scmd_eh_abort_handler()
then cause the BUG_ON(blk_queued_rq(req)) trigger.
[2.] Full description of the problem/report:
The detailed scene is as following:
cpu A
36 matches
Mail list logo
