From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: usb: uas: fix usb subsystem hang after power off hub port From: "Martin K. Petersen" Message-Id: Date: Mon, 08 Apr 2019 22:10:19 -0400 To: Alan Stern Cc: Kento.A.Kobayashi@sony.com, "James E.J. Bottomley" , "Martin K. Petersen" , Oliver Neukum , gregkh@linuxfoundation.org, USB Storage list , Jacky.Cao@sony.com, Kernel development list , SCSI development list , USB list List-ID: QWxhbiwKCj4gU28gaXQgbG9va3MgYXMgdGhvdWdoIHRoZSBTQ1NJIHN1YnN5c3RlbSBkb2Vzbid0 IGxpa2UgdG8gaGF2ZSBhIHJlc2V0IAo+IGhhbmRsZXIgY2FsbCBzY3NpX3JlbW92ZV9ob3N0LgoK QXJlIHlvdSB0YWxraW5nIGFib3V0IGEgUENJIGRldmljZSByZW1vdmFsIGhhbmRsZXIgb3IgYSBT Q1NJIGVycm9yCmhhbmRsZXI/Cgo+IENvbW1hbmRzIGRpc3BhdGNoZWQgYnkgdGhlIHJlbW92YWwg cm91dGluZXMgYXJlIGZvcmNlZCB0byB3YWl0IGZvciB0aGUKPiByZXNldCByZWNvdmVyeSB0byBm aW5pc2gsIHdoaWNoIHdvbid0IGhhcHBlbiB1bnRpbCB0aG9zZSBjb21tYW5kcyBoYXZlCj4gYmVl biBjb21wbGV0ZWQuCj4KPiBJcyB0aGlzIGEgYnVnIGluIHRoZSBTQ1NJIGNvcmU/ICBJZiBub3Qs IHdlIG5lZWQgdG8ga25vdyB3aGF0IGlzIHRoZQo+IHJpZ2h0IHdheSB0byBkbyB0aGluZ3Mgd2hl biBhIHJlc2V0IGhhbmRsZXIgZGV0ZWN0cyB0aGF0IHRoZSBTQ1NJIGhvc3QKPiBoYXMgYmVlbiBo b3QtdW5wbHVnZ2VkLgoKUENJIHN1cnByaXNlIHJlbW92YWwgc2hvdWxkIGdlbmVyYWxseSB3b3Jr LiBCdXQgaXQncyBzb21ld2hhdCB1bnVzdWFsCmZvciBhIFNDU0kgaG9zdCB0byBldmFwb3JhdGUg aW4gdGhlIG1pZGRsZSBvZiBlcnJvciBoYW5kbGluZy4gQWZ0ZXIgYWxsLAp0aGUgbWFpbiBwdXJw b3NlIG9mIGVoIGlzIHRvIGxldmVyYWdlIHRoZSBpbnRlcmZhY2VzIHByb3ZpZGVkIGJ5IHRoZQpo b3N0IHRvIHRyeSB0byByZWNvbm5lY3QgdG8gYSB0YXJnZXQgdGhhdCB0cmlwcGVkIGFuZCBmZWxs IG9mZiB0aGUKYnVzLi4uCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_HIGH,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86B29C10F13 for ; Tue, 9 Apr 2019 02:10:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55D5221473 for ; Tue, 9 Apr 2019 02:10:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="lZLSLXsk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726538AbfDICKx (ORCPT ); Mon, 8 Apr 2019 22:10:53 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:59924 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725953AbfDICKx (ORCPT ); Mon, 8 Apr 2019 22:10:53 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x392A4Rk097347; Tue, 9 Apr 2019 02:10:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : cc : subject : from : references : date : in-reply-to : message-id : mime-version : content-type; s=corp-2018-07-02; bh=HfkS45Zt2fMESAbcnl3hyfZ2EC46gZ0d06xznFPMZWM=; b=lZLSLXskSicYiRk9BPdTzZLzw8GvWANg5CRXoY8w8tkndlhxs0iGlCdIC9XZzKvOjMm3 2YFON2NdZdGuMtXgZY3K0DSbORuVuBaQW0YUOkfAfb82fMxd7DfKIOtlD/yxwKza6sO1 hnpfhy9YJqZsL88ZVgXP1YoXHB83DEIH7ZhRg+1xin4TX5L12JzRZ29KW3EjXJtJWpZ7 ASPu/rLFcFKF8Tr6Skwg3BtO+F6Z/44XxrcS0b6quxWCmYYLRUZBli8XSx85DH872IEm varNiMwz+sCBRV+gobC5kFXbMSNF7byyXP+eThY21sVA8LK0+JSkZV2vWP3csXQq92Ei pg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2130.oracle.com with ESMTP id 2rphmea66j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 02:10:28 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3929cb6007436; Tue, 9 Apr 2019 02:10:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2rpj5aa1v3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 02:10:28 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x392ANCq014365; Tue, 9 Apr 2019 02:10:23 GMT Received: from ca-mkp.ca.oracle.com (/10.159.214.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Apr 2019 19:10:22 -0700 To: Alan Stern Cc: Kento.A.Kobayashi@sony.com, "James E.J. Bottomley" , "Martin K. Petersen" , Oliver Neukum , , USB Storage list , , Kernel development list , SCSI development list , USB list Subject: Re: [PATCH] usb: uas: fix usb subsystem hang after power off hub port From: "Martin K. Petersen" Organization: Oracle Corporation References: Date: Mon, 08 Apr 2019 22:10:19 -0400 In-Reply-To: (Alan Stern's message of "Thu, 4 Apr 2019 15:33:38 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=411 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090013 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=431 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090013 Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Message-ID: <20190409021019.dmiNGI1arYzdHVh-u7bO3ebGHQI5GXWO_C6IRXHVfU0@z> Alan, > So it looks as though the SCSI subsystem doesn't like to have a reset > handler call scsi_remove_host. Are you talking about a PCI device removal handler or a SCSI error handler? > Commands dispatched by the removal routines are forced to wait for the > reset recovery to finish, which won't happen until those commands have > been completed. > > Is this a bug in the SCSI core? If not, we need to know what is the > right way to do things when a reset handler detects that the SCSI host > has been hot-unplugged. PCI surprise removal should generally work. But it's somewhat unusual for a SCSI host to evaporate in the middle of error handling. After all, the main purpose of eh is to leverage the interfaces provided by the host to try to reconnect to a target that tripped and fell off the bus... -- Martin K. Petersen Oracle Linux Engineering