RE: scsi_set_medium_removal timeout issue
Hi Alan: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Monday, November 12, 2018 11:33 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@lists.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 I just enabled the scsi log in the middle of the umount operation, otherwise I can't reproduce the issue when the scsi log is enabled. >from the beginning. In any case, it wasn't what I wanted. I asked you to >post the dmesg log, not the SCSI log. Please refer to the new attachment for dmesg log. Thanks Zengtao ~ # dmesg Booting Linux on physical CPU 0x0 Linux version 4.9.37 (lpcheng@osdrv) (gcc version 6.3.0 (HC V100R002C00B021_20180917) ) #5 SMP Mon Nov 12 19:35:04 HKT 2018 CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache OF: fdt:Machine model: Hisilicon Hi3519AV100 SMP Board cma: dma_contiguous_reserve(limit ) cma: dma_contiguous_reserve: reserving 16 MiB for global area cma: cma_declare_contiguous(size 0x0100, base 0x, limit 0x alignment 0x) cma: Reserved 16 MiB at 0x3100 Memory policy: Data cache writealloc On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c092d580, node_mem_map cedf1000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65536 pages, LIFO batch:15 percpu: Embedded 13 pages/cpu @cedc6000 s22028 r8192 d23028 u53248 pcpu-alloc: s22028 r8192 d23028 u53248 alloc=13*4096 pcpu-alloc: [0] 0 [0] 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: mem=256M console=ttyAMA0,115200 clk_ignore_unused root=/dev/mtdblock2 rw rootfstype=yaffs2 mtdparts=hinand:1M(boot),4M(kernel),60M(rootfs) nosmp PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 234544K/262144K available (5120K kernel code, 184K rwdata, 1368K rodata, 1024K init, 321K bss, 11216K reserved, 16384K cma-reserved, 0K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xd080 - 0xff80 ( 752 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc060 (6112 kB) .init : 0xc080 - 0xc090 (1024 kB) .data : 0xc090 - 0xc092e180 ( 185 kB) .bss : 0xc093 - 0xc098072c ( 322 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. Build-time adjustment of leaf fanout to 32. RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 NR_IRQS:16 nr_irqs:16 16 arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns Switching to timer-based delay loop, resolution 41ns clocksource: hisp804: mask: 0x max_cycles: 0x, max_idle_ns: 637086815595 ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) pid_max: default: 32768 minimum: 301 Mount-cache
RE: scsi_set_medium_removal timeout issue
Hi Alan: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Monday, November 12, 2018 11:33 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@lists.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 I just enabled the scsi log in the middle of the umount operation, otherwise I can't reproduce the issue when the scsi log is enabled. >from the beginning. In any case, it wasn't what I wanted. I asked you to >post the dmesg log, not the SCSI log. Please refer to the new attachment for dmesg log. Thanks Zengtao ~ # dmesg Booting Linux on physical CPU 0x0 Linux version 4.9.37 (lpcheng@osdrv) (gcc version 6.3.0 (HC V100R002C00B021_20180917) ) #5 SMP Mon Nov 12 19:35:04 HKT 2018 CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache OF: fdt:Machine model: Hisilicon Hi3519AV100 SMP Board cma: dma_contiguous_reserve(limit ) cma: dma_contiguous_reserve: reserving 16 MiB for global area cma: cma_declare_contiguous(size 0x0100, base 0x, limit 0x alignment 0x) cma: Reserved 16 MiB at 0x3100 Memory policy: Data cache writealloc On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c092d580, node_mem_map cedf1000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65536 pages, LIFO batch:15 percpu: Embedded 13 pages/cpu @cedc6000 s22028 r8192 d23028 u53248 pcpu-alloc: s22028 r8192 d23028 u53248 alloc=13*4096 pcpu-alloc: [0] 0 [0] 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: mem=256M console=ttyAMA0,115200 clk_ignore_unused root=/dev/mtdblock2 rw rootfstype=yaffs2 mtdparts=hinand:1M(boot),4M(kernel),60M(rootfs) nosmp PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 234544K/262144K available (5120K kernel code, 184K rwdata, 1368K rodata, 1024K init, 321K bss, 11216K reserved, 16384K cma-reserved, 0K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xfff0 (3072 kB) vmalloc : 0xd080 - 0xff80 ( 752 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc060 (6112 kB) .init : 0xc080 - 0xc090 (1024 kB) .data : 0xc090 - 0xc092e180 ( 185 kB) .bss : 0xc093 - 0xc098072c ( 322 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. Build-time adjustment of leaf fanout to 32. RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 NR_IRQS:16 nr_irqs:16 16 arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys). clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns Switching to timer-based delay loop, resolution 41ns clocksource: hisp804: mask: 0x max_cycles: 0x, max_idle_ns: 637086815595 ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) pid_max: default: 32768 minimum: 301 Mount-cache
RE: scsi_set_medium_removal timeout issue
Hi Alan: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Wednesday, October 31, 2018 10:20 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@lists.one-eyed-alien.net >Subject: RE: scsi_set_medium_removal timeout issue > >On Wed, 31 Oct 2018, Zengtao (B) wrote: > >> Hi: >> >> >-Original Message- >> >From: Alan Stern [mailto:st...@rowland.harvard.edu] >> >Sent: Tuesday, October 30, 2018 10:08 PM >> >To: Zengtao (B) >> >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >> >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >> >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >> >usb-stor...@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? > I have enabled the SCSI log for the host, please refer to the attachment. Thanks. Zengtao ~ # ~ # ~ # ~ # ~ # mkfs.vfat /dev/sda1 moun~ # ~ # mount /dev/sda1 /mnt ~ # ~ # time dd if=/dev/zero of=/mnt/test0 bs=16k count=5120 5120+0 records in 5120+0 records out 83886080 bytes (80.0MB) copied, 2.970369 seconds, 26.9MB/s real0m 2.97s user0m 0.01s sys 0m 0.76s ~ # ~ # umount /mnt sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 12 f6 00 00 80 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b800 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 13 76 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 13 76 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b700 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 14 66 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 14 66 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b800 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 15 56 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 15 56 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] ta
RE: scsi_set_medium_removal timeout issue
Hi Alan: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Wednesday, October 31, 2018 10:20 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@lists.one-eyed-alien.net >Subject: RE: scsi_set_medium_removal timeout issue > >On Wed, 31 Oct 2018, Zengtao (B) wrote: > >> Hi: >> >> >-Original Message- >> >From: Alan Stern [mailto:st...@rowland.harvard.edu] >> >Sent: Tuesday, October 30, 2018 10:08 PM >> >To: Zengtao (B) >> >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >> >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >> >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >> >usb-stor...@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? > I have enabled the SCSI log for the host, please refer to the attachment. Thanks. Zengtao ~ # ~ # ~ # ~ # ~ # mkfs.vfat /dev/sda1 moun~ # ~ # mount /dev/sda1 /mnt ~ # ~ # time dd if=/dev/zero of=/mnt/test0 bs=16k count=5120 5120+0 records in 5120+0 records out 83886080 bytes (80.0MB) copied, 2.970369 seconds, 26.9MB/s real0m 2.97s user0m 0.01s sys 0m 0.76s ~ # ~ # umount /mnt sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 12 f6 00 00 80 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b800 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 13 76 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 13 76 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b700 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 14 66 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 14 66 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] tag#0 Send: scmd 0xce13b800 sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 15 56 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 02 15 56 00 00 f0 00 sd 0:0:0:0: [sda] tag#0 scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) sd 0:0:0:0: [sda] ta
RE: scsi_set_medium_removal timeout issue
Hi: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Tuesday, October 30, 2018 10:08 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@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? Zengtao >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
RE: scsi_set_medium_removal timeout issue
Hi: >-Original Message- >From: Alan Stern [mailto:st...@rowland.harvard.edu] >Sent: Tuesday, October 30, 2018 10:08 PM >To: Zengtao (B) >Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; >gre...@linuxfoundation.org; linux-s...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; >usb-stor...@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? Zengtao >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
