Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753446AbdHPDE1 (ORCPT ); Tue, 15 Aug 2017 23:04:27 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:11266 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752440AbdHPDEZ (ORCPT ); Tue, 15 Aug 2017 23:04:25 -0400 From: "Tangchen (UVP)" To: Bart Van Assche , "lduncan@suse.com" , "cleech@redhat.com" , "axboe@kernel.dk" CC: "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , guijianfeng , zhengchuan , "Tangchen (UVP)" Subject: =?utf-8?B?UkU6IOetlOWkjTogW2lzY3NpXSBEZWFkbG9jayBvY2N1cnJlZCB3aGVuIG5l?= =?utf-8?Q?twork_is_in_error?= Thread-Topic: =?utf-8?B?562U5aSNOiBbaXNjc2ldIERlYWRsb2NrIG9jY3VycmVkIHdoZW4gbmV0d29y?= =?utf-8?Q?k_is_in_error?= Thread-Index: AdMU7px11YQAMA8RQpqjHfoYPGQQNgAIc0wAABXO1gAAKg2GAAAKzc8w Date: Wed, 16 Aug 2017 03:03:48 +0000 Message-ID: <22E823DBB7698E489DC113638F7470729C2D9E@DGGEMM506-MBX.china.huawei.com> References: <22E823DBB7698E489DC113638F7470729C17B6@DGGEMM506-MBX.china.huawei.com> <1502723836.2333.3.camel@wdc.com> <22E823DBB7698E489DC113638F7470729C1AF0@DGGEMM506-MBX.china.huawei.com> <1502833548.2259.9.camel@wdc.com> In-Reply-To: <1502833548.2259.9.camel@wdc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.147.155] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5993B624.0032,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=169.254.3.138, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d0f0a6cb29f9937b9a44f67d82621a8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v7G34Wp4009217 Content-Length: 1407 Lines: 40 > On Tue, 2017-08-15 at 02:16 +0000, Tangchen (UVP) wrote: > > But I'm not using mq, and I run into these two problems in a non-mq system. > > The patch you pointed out is fix for mq, so I don't think it can resolve this > problem. > > > > IIUC, mq is for SSD ? I'm not using ssd, so mq is disabled. > > Hello Tangchen, > > Please post replies below the original e-mail instead of above - that is the reply > style used on all Linux-related mailing lists I know of. From > https://en.wikipedia.org/wiki/Posting_style: > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? Hi Bart, Thanks for the reply. Will post the reply in e-mail. :) > > Regarding your question: sorry but I quoted the wrong commit in my previous > e-mail. The commit I should have referred to is 255ee9320e5d ("scsi: Make > __scsi_remove_device go straight from BLOCKED to DEL"). That patch not only > affects scsi-mq but also the single-queue code in the SCSI core. OK, I'll try this one. Thx. > > blk-mq/scsi-mq was introduced for SSDs but is not only intended for SSDs. > The plan is to remove the blk-sq/scsi-sq code once the blk-mq/scsi-mq code > works at least as fast as the single queue code for all supported devices. > That includes hard disks. OK, thanks for tell me this. > > Bart.