Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp6137876imd; Wed, 31 Oct 2018 07:22:58 -0700 (PDT) X-Google-Smtp-Source: AJdET5dX7d+gsKy2vr5zAD5GmSeGzQ8e03mHUbBNUHsiF/ZpxaljkrUWspiPhtLnIRWzHs8MU2va X-Received: by 2002:a17:902:15c5:: with SMTP id a5-v6mr3646897plh.136.1540995778365; Wed, 31 Oct 2018 07:22:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540995778; cv=none; d=google.com; s=arc-20160816; b=v1jzOHmUY7gLaQsj3ZUXRXPGEgsz+6Yr2vefbSfJOy5k/c2wZB0q4vPb2PVHsz7eIW Gp0fDDIcBQ5rIlsHCGtrTb/Rww8UD1IUF0pYFiM2YMark9QeqjRbHQZ7ZyxOKBh7dUoh +lh5gfxl/8Srk0V5zIqZcAvkczdPzitdwEEHaFaI/WahIm+KJ8VHNj9vXBoOnfs4ML80 75bRHhRQWpJFV4tMbFqiiI0Ww0D7jAw0H/HinMN2NHP14O3QcOxSDfAeUBEK3aXD1tZZ 0Pdfh5hFTrpgJV0sHhXrbbgflBQliGAXt7xhX2n5TjOWAJc3EAFRJS9FzT0X/Orggv17 JUUA== 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=7+oSH5kDmjRUibt5B/bNNiK6u27mLIZeepvWFMgSczY=; b=sfeYwbfCm+wRwmmZ00rRvn7QkeuxD7nJ04dqZD+flsyn8FCVUYkm69PeYbSGPQJDjx RRolgnsDyE5r4eu7Cr5bX/fcThiNxb3fhSrGO0EUaTmpOa2iuc4YRH2cxDBhMxojcDoP LPKgCL0FphVvUEBJsFCrTJYSgUU3fisj4XUJoF1y+mSeDMy/pzSpBfOIWIFhC7y99Spo Bx0g9mKAGnIcRodLVMQYVc5VddU1NXk086bBL9oOuV11lZ1e7kXlXSpMAgI5m+fVMlHL KreyqEqXKf/16A+Y8aJGIberV9S8LKfmcyXNFYqno8CbmXtScOOWq5s7NXKQEfWbm817 KlOQ== 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 q9-v6si27447950pgi.162.2018.10.31.07.22.38; Wed, 31 Oct 2018 07:22:58 -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 S1729593AbeJaXRx (ORCPT + 99 others); Wed, 31 Oct 2018 19:17:53 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:41910 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1729435AbeJaXRx (ORCPT ); Wed, 31 Oct 2018 19:17:53 -0400 Received: (qmail 2083 invoked by uid 2102); 31 Oct 2018 10:19:39 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Oct 2018 10:19:39 -0400 Date: Wed, 31 Oct 2018 10:19:39 -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: <678F3D1BB717D949B966B68EAEB446ED1F19F98A@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 Wed, 31 Oct 2018, Zengtao (B) wrote: > Hi: > > >-----Original Message----- > >From: Alan Stern [mailto:stern@rowland.harvard.edu] > >Sent: Tuesday, October 30, 2018 10:08 PM > >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 > > > >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. > > > > Definitely, I haven't seen the SYNCHRONIZE CACHE from the host, it directly > issued the PREVENT-ALLOW MEDIUM REMOVAL, so maybe something wrong > with the scsi layer or something wrong with the mass storage class driver? Or it could be something else. Can you please post the dmesg log from the host, showing what happens when the device is first plugged in? Alan Stern