[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1811121031180.7773-100000@netrider.rowland.org>
Date: Mon, 12 Nov 2018 10:33:04 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: "Zengtao (B)" <prime.zeng@...ilicon.com>
cc: "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"usb-storage@...ts.one-eyed-alien.net"
<usb-storage@...ts.one-eyed-alien.net>
Subject: RE: scsi_set_medium_removal timeout issue
On Mon, 12 Nov 2018, Zengtao (B) wrote:
> >> >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?
> >
>
> I have enabled the SCSI log for the host, please refer to the attachment.
The log you attached was incomplete -- it was missing some commands
from the beginning. In any case, it wasn't what I wanted. I asked
you to post the dmesg log, not the SCSI log.
Alan Stern
Powered by blists - more mailing lists