Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbdHRVmF (ORCPT ); Fri, 18 Aug 2017 17:42:05 -0400 Received: from esa5.hgst.iphmx.com ([216.71.153.144]:19719 "EHLO esa5.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752514AbdHRVmD (ORCPT ); Fri, 18 Aug 2017 17:42:03 -0400 X-IronPort-AV: E=Sophos;i="5.41,393,1498492800"; d="scan'208";a="43174678" From: Bart Van Assche To: "linuxppc-dev@lists.ozlabs.org" , "abdhalee@linux.vnet.ibm.com" , "brking@linux.vnet.ibm.com" CC: "linux-kernel@vger.kernel.org" , "hch@lst.de" , "linux-scsi@vger.kernel.org" , "sfr@canb.auug.org.au" , "sachinp@linux.vnet.ibm.com" , "linux-next@vger.kernel.org" , "hare@suse.com" , "mpe@ellerman.id.au" Subject: Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc Thread-Topic: [BUG][bisected 270065e] linux-next fails to boot on powerpc Thread-Index: AQHTFrEsFAqRDNfhzkCHszoyuzdYEKKHOrsAgABjzoCAARXLgIAB6V2AgAAKWYA= Date: Fri, 18 Aug 2017 21:41:13 +0000 Message-ID: <1503092473.2622.17.camel@wdc.com> References: <1502902815.3305.22.camel@abdul.in.ibm.com> <1502904072.2421.3.camel@wdc.com> <2f686064-3e32-df8d-134f-962b5181da9d@linux.vnet.ibm.com> <1502985161.2615.8.camel@wdc.com> <71fb9c1b-9f3f-acdc-8bb5-aa1240aea763@linux.vnet.ibm.com> In-Reply-To: <71fb9c1b-9f3f-acdc-8bb5-aa1240aea763@linux.vnet.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1307;20:n94KJPKdRTu1SNaUbt+5qhDNgZr+DkOaqDjqARhTIxjrKccNa7AA4a31QLbfLZWyf9aglMDs+Qawe7qKiR353kBzSiFyws6vJEPeSx9KV7OGK28+W8mfjwcqdLr/NgjINPr5cniTR4SjHLB8oLsyWKWwgP+nmpRDTJo2Rbd7pyo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6406294f-e959-4fd1-5bc3-08d4e681d98e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR0401MB1307; x-ms-traffictypediagnostic: CY1PR0401MB1307: wdcipoutbound: EOP-TRUE x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB1307;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB1307; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(24454002)(377424004)(199003)(51914003)(189002)(2906002)(68736007)(305945005)(2501003)(33646002)(86362001)(8936002)(7736002)(106356001)(72206003)(5660300001)(53936002)(103116003)(97736004)(2201001)(6246003)(81166006)(105586002)(8676002)(81156014)(93886005)(6506006)(6116002)(77096006)(2900100001)(102836003)(6486002)(101416001)(3846002)(3660700001)(229853002)(7416002)(25786009)(50986999)(76176999)(6512007)(54356999)(2950100002)(66066001)(54906002)(36756003)(99286003)(14454004)(189998001)(478600001)(3280700002)(4326008)(6436002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1307;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <68887D7DDBE50145B91F1308358F04AA@namprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2017 21:41:13.9826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1307 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 v7ILgBYb030860 Content-Length: 1857 Lines: 32 On Fri, 2017-08-18 at 16:04 -0500, Brian King wrote: > I think I have an understanding what is going on and why Bart's patch is causing problems for ipr. > I can work around the boot hang in ipr, but ultimately I think we need to figure out a fix > in scsi / block. I added some tracing and confirmed its not a matter of commands getting stuck > in ipr. The issue is we are retrying failed commands until we finally run out of time. This is > what I see: > > 1. sd_revalidate_disk calls scsi_report_opcode > 2. ipr RAID arrays don't support MAINTENANCE_IN / MI_REPORT_SUPPORTED_OPERATION_CODES > 3. ipr returns the command with DID_ERROR > 4. scsi_decide_disposition goes to maybe_retry, increments scmd->retries, and returns NEEDS_RETRY > 5. scsi_softirq_done calls scsi_queue_insert to requeue the command, which calls scsi_mq_requeue_cmd > 6. With Bart's change, we then clear RQF_DONTPREP in this path, while prior we did not > 7. This results in the command getting scmd->retries zeroed out when it gets re-queued, > since we go through prep again and we lose our retry counter, resulting in lots and lots of retries. > 8. Since the default command timeout for an ipr RAID array is 120 seconds, these retries go on for > quite a long time... > 9. Finally, the command has been retried so long we trip over the overall retry timer > in scsi_softirq_done and we timeout the command. > > I'll follow up with a patch to ipr to workaround the hang, but I think we need to somehow preserve > the retry counter in the scsi command, as this will likely cause issues with other drivers. Hello Brian, Thanks for the detailed analysis. This is very helpful. Have you considered to change the ipr driver such that it terminates REPORT SUPPORTED OPERATION CODES commands with the appropriate check condition code instead of DID_ERROR? Thanks, Bart.