On Fri, 1 May 2015, Xuebing Wang wrote: > > On 04/30/2015 11:31 PM, Alan Stern wrote: > >> >On Thu, Apr 30, 2015 at 12:37:15AM -0500, Felipe Balbi wrote: > >>> > >On Thu, Apr 30, 2015 at 10:46:51AM +0800, Xuebing Wang wrote: > >>>> > > > > >>>> > > >On 04/30/2015 12:45 AM, Felipe Balbi wrote: > >>>>>>> > > > >>>try setting nofua parameter. Windows always sets FUA bit (so all writes > >>>>>>>>> > > > >>>> >are*always* flushed to non-volatile media), but telling mass storage > >>>>>>>>> > > > >>>> >gadget to ignore FUA bit, you get better performance. > >>>>>>> > > > >>> > >>>>>>> > > > >>>At the expense of possibly loosing your data if you loose power, so > >>>>>>> > > > >>>ignore it at your own peril:) > >>>>> > > > >Well, unless you're completely powered via USB and have no batteries, > >>>>> > > > >then yeah, you have an issue. The likelyhood that you have batteries is > >>>>> > > > >much, much larger, though. > >>>> > > > > >>>> > > >Thanks for the help. However, enable nofua seems not helping performance > >>>> > > >with Win7 host. My command is: > >>>> > > >modprobe g_mass_storage file=/dev/mmcblk0p4 removable=1 nofua=1 > >>> > > > >>> > >then you're really on your own. I would suggest a sniffer to figure out > >>> > >if the host isn't sending tokens fast enough (too many SOFs) or the > >>> > >device isn't fast enough (too many NAKs/NYETs). > > Even without a hardware sniffer, it is possible to get useful timing > > information by uncommenting the > > > > /* #define VERBOSE_DEBUG */ > > /* #define DUMP_MSGS */ > > > > lines near the start of f_mass_storage.c. > > > > It's also worth mentioning that you are never supposed to use > > g_mass_storage without specifying a serial number string. This may not > > affect the transfer rates, but I know that Windows does pay attention > > to the serial number string. > > > > Alan Stern > > > >> >oh yeah, if you can reproduce the same thing using a recent kernel > >> >(v4.0, for example) and give us further details of your setup (which > >> >platform, which controller you're using, etc), then linux-usb will be > >> >very happy to help out. > > Felipe, Alan, > > Thanks for the help. Yes, I can reproduce this issue with kernel v4.0.1 > on our own board which is similar to Freescale iMX6SL EVK (evaluation > board). > > Command is : modprobe g_mass_storage file=/dev/mmcblk0p4 removable=1 nofua=1 > > For copying 180MB file from host to device: > -- At Win7 host, it takes about 60 seconds to copy. After GUI finishes > copying at Win7, and type "sync" at device side, "sync" returns immediately. > -- At MacOS host, it takes about 15 seconds for GUI to finishes copying. > After GUI finishes copying, type "sync" at device side, "sync" takes > about 10 seconds to return. > -- Ubuntu 14.04.1 host performance is similar to MacOS. > > Likely, this is not related to SoC platform or eMMC, what do you think? > > Thanks for your willingness to help. Would you mind to do quick test on > your hardware platform (e.g. TI SoC) if you have a Windows host? Not unless you pay attention to what I wrote above: It looks like you did not try enabling the debugging options in f_mass_storage.c. It looks like you did not try specifying the "serial=" module parameter for g_mass_storage. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
