[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1540889786.12349.9.camel@suse.com>
Date: Tue, 30 Oct 2018 09:56:26 +0100
From: Oliver Neukum <oneukum@...e.com>
To: "Zengtao (B)" <prime.zeng@...ilicon.com>,
"jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"stern@...land.harvard.edu" <stern@...land.harvard.edu>
Cc: "usb-storage@...ts.one-eyed-alien.net"
<usb-storage@...ts.one-eyed-alien.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: scsi_set_medium_removal timeout issue
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
Powered by blists - more mailing lists