Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4767308imd; Tue, 30 Oct 2018 07:10:01 -0700 (PDT) X-Google-Smtp-Source: AJdET5ez/ChtxvTIzAKGZxqmJ3afBaIUYA+aSVeFaobugu1MVGAEySHw7GfMZ/gvQzxLl4b7Eq2Y X-Received: by 2002:a17:902:a58c:: with SMTP id az12-v6mr18665963plb.266.1540908601168; Tue, 30 Oct 2018 07:10:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540908601; cv=none; d=google.com; s=arc-20160816; b=GfJjrhw7peag2LeEOERhwTyoKIjZWZFl/eOY69DC5HlXtRrE1+3weVGoEjH6yyiCkz 9P3Z1o/I75vO8n33q46immN/Qzscx9Sf0rfWF5H76R4WCuvQQRIifhetm+PFmivrhGg2 4aqFVgiVhZ/V2lnnbUlYThBcmB87HKPL/Da338JXtNU9sbZIMXAxACuRlpMEwrS2BlIS ruCDZmYNVlC/Z+NnAaX/J/bdm8X18/4wDfL/TunArM98XQknkqAd+Is8itxsJ8d0Ah41 uLXzus39H+nthpBjNphG6ULdPh7g3o0uQqNJ7FkpqUhgaEy/zma7HxEq3gyTPFn/JWmv 2m0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=PKweEW0lmz7++XT5VU3uHpPWXtF7pENrZvxBFHxmkeU=; b=HsB4BLAClpAxZXQIK7qtcxlG0BLfyWznP8xTYHI/lHVcVYwa/MrWDUbSgSZYI+gV3g GHo5HUVI9tdSd7oA7ir3zf147LtZ0NqMxbn5cQ77r1Rob00ULGVKbaCyZleL9cZOiuF0 1Xel38jKC1phMhyeyvNqRIAlHBwXJ8qrzTup23WeM15+CtP7TItANLUlKmnjwAk3nwdD z4Rx2H3rSpdSZl6T1hZZk/du7w89sj6pTie7/uNS/NyIQ1hXZxy0x5Y6MW/kSdpM+NHs T1T1ot53tbCKwuya4F/stHKKqiMecNvFDRBgtXz0FC8aLP7YtX8xYbn/DLzrCYYHWOBt 81uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g7-v6si23973809pgj.116.2018.10.30.07.09.33; Tue, 30 Oct 2018 07:10:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728193AbeJ3XBw (ORCPT + 99 others); Tue, 30 Oct 2018 19:01:52 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:51332 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726563AbeJ3XBv (ORCPT ); Tue, 30 Oct 2018 19:01:51 -0400 Received: (qmail 2865 invoked by uid 2102); 30 Oct 2018 10:08:13 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Oct 2018 10:08:13 -0400 Date: Tue, 30 Oct 2018 10:08:13 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Zengtao (B)" cc: "jejb@linux.vnet.ibm.com" , "martin.petersen@oracle.com" , "gregkh@linuxfoundation.org" , "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "usb-storage@lists.one-eyed-alien.net" Subject: Re: scsi_set_medium_removal timeout issue In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED1F19F1CF@dggemm526-mbx.china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Oct 2018, Zengtao (B) wrote: > Hi > > I have recently met a scsi_set_medium_removal timeout issue, and it's related > to both SCSI and USB MASS storage. > Since i am not an expert in either scsi or usb mass storage, i am writing to report > the issue and ask for a solution from you guys. > > My test scenario is as follow: > 1.Linux HOST-----Linux mass storage gadget(the back store is a flash partition). > 2.Host mount the device. > 3.Host writes some data to the Mass storage device. > 4.Host Unmount the device. > Both Linux kernels(Host and Device) are Linux 4.9. > Some has reported the same issue a long time ago, but it remains there. > https://www.spinics.net/lists/linux-usb/msg53739.html > > For the issue itself, there is my observation: > In the step 4, the Host will issue an PREVENT_ALLOW_MEDIUM_REMOVAL scsi command. > and and timeout happens due to the device 's very slow fsg_lun_fsync_sub. Something is wrong here. Before sending PREVENT-ALLOW MEDIUM REMOVAL, the host should issue SYNCHRONIZE CACHE. This will force fsg_lun_fsync_sub to run, and the host should allow a long timeout for this command. Then when PREVENT-ALLOW MEDIUM REMOVAL is sent, nothing will need to be flushed. Alan Stern > I found there are two methods to workaround the issue: > 1. Change the timeout value of host scsi command PREVENT_ALLOW_MEDIUM_REMOVAL to > to about 60 seconds from 10 seconds. > 2. Remove the fsg_lun_fsync_sub in the device's Mass storage gadget driver. > > Thanks > > Regards > zentao