Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4444366imd; Tue, 30 Oct 2018 01:57:22 -0700 (PDT) X-Google-Smtp-Source: AJdET5eqsRQpXWPjQlorK5tXoU0WaNevgg1Evrk5hSTZ2ZTS7BzkCB1cp7xeBPChgcY5i7/pjShV X-Received: by 2002:a17:902:3a5:: with SMTP id d34-v6mr17716201pld.231.1540889842380; Tue, 30 Oct 2018 01:57:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540889842; cv=none; d=google.com; s=arc-20160816; b=zEq0CxFdeto8NlrgEuBlITRkWJ34xx2wnfKNeZjOvr3txhCzWh0N4Sld/gY8uMsNl5 lpzmWgWDIE13OHBAr7NyWWDWN9gXX2vci/LWbhBWkWpYFAJu+0Mr6kDLnTiSS4G5XTz+ dr2nfpOAvn87IqShr0epT1WJDLOqa/pUZ12rNshUIS29BbwkEV5mslEcc82NNTMF/PeC xT2i/4j7YolZCH2HDWf9GzlW79cJpY9nkHDo77b20JMUmZGEhW0KlKX66BYIqjYu6SHq HicFukNgOAKmTTHj4sU4osL43DM3qzRWSJ4N53kRWxFhdZpTrocXNI4qlKcXvRvNCN3s FvRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=j2lEKLOnqZrtgqk1PUFRJLhrmMad4T1rgjhrTXiaong=; b=qZePWhINGDP10S0GPZ3I6+1KCP0RHX2IUggY6+P6o91nHwf7l5NP5AUDiC/Tm1i/q1 gPu5oZ0wkj23m9rOHrxc1UsQJvhPzOKeJyHoPdlmVbqvxFcS7DfWgt+u2yYL00WFQ898 fpXd/4CnrosDKHNZtfV4shBAFpl11A9vaOHmzmhCCrMiLVi868xD2yLfVSwfL4ao7EQG 1qOxN6+hMIAfunQV6MMeGmKfzDGY4y44oyE/8lcfm511zJM3hEXGHyLEPf2mHKm5raCR 4rziICMQN/YBbSPHkHB9PWUt1VyuZSgiVSGKQwFEll0sPRbLWiMPHSd4KoMQ5A8SxpJZ kyyg== 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 s18-v6si19617942pgd.484.2018.10.30.01.57.06; Tue, 30 Oct 2018 01:57:22 -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 S1726743AbeJ3RtR (ORCPT + 99 others); Tue, 30 Oct 2018 13:49:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:41666 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726211AbeJ3RtR (ORCPT ); Tue, 30 Oct 2018 13:49:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5EAD1AE92; Tue, 30 Oct 2018 08:56:43 +0000 (UTC) Message-ID: <1540889786.12349.9.camel@suse.com> Subject: Re: scsi_set_medium_removal timeout issue From: Oliver Neukum To: "Zengtao (B)" , "jejb@linux.vnet.ibm.com" , "gregkh@linuxfoundation.org" , "martin.petersen@oracle.com" , "stern@rowland.harvard.edu" Cc: "usb-storage@lists.one-eyed-alien.net" , "linux-kernel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux-usb@vger.kernel.org" Date: Tue, 30 Oct 2018 09:56:26 +0100 In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED1F19F1CF@dggemm526-mbx.china.huawei.com> References: <678F3D1BB717D949B966B68EAEB446ED1F19F1CF@dggemm526-mbx.china.huawei.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Di, 2018-10-30 at 08:28 +0000, Zengtao (B) wrote: > Hi > 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. > 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. That is near useless, because the gadget can be used with other systems. > 2. Remove the fsg_lun_fsync_sub in the device's Mass storage gadget driver. It exists for a reason. The blocks have to be on the medium. It seems to me that your gadget just allows too many dirty pages in the cache. Regards Oliver