Date: Mon, 8 Jan 2018 13:17:22 +0800 From: blubee blubeeme <gurenchan@gmail.com> To: Jon Brawn <jon@brawn.org> Cc: Warner Losh <imp@bsdimp.com>, "O'Connor, Daniel" <darius@dons.net.au>, gljennjohn@gmail.com, FreeBSD current <freebsd-current@freebsd.org> Subject: Re: USB stack Message-ID: <CALM2mEnsbS2WijTPzihEfP2K_7H5r1hRXGuCCsuyzbw7MwA03w@mail.gmail.com> In-Reply-To: <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org> References: <CALM2mEmZFP9dGOivJknrCaaa-K1cSxNTTEV%2B8XCMpoZp-xcbqQ@mail.gmail.com> <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <CALM2mE=7cKcPzJ=-bVvmHez2inrAqJsuMaW%2BUZZtXesB3pzDtQ@mail.gmail.com> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <CALM2mE=uFK0BVqxFcrU_K%2BN%2BwYnu9VTewACeNqPTGYFEv93g4g@mail.gmail.com> <CANCZdfqna3dy-29g_fB3-aw71Hps2ph_%2BNMBUW9z7nhMBVztjg@mail.gmail.com> <CALM2mEmgn4FmBLtW4SaGEEqoF6AsFR_y1PUMTZ80_2GpDx1SdQ@mail.gmail.com> <D9F7EB72-71CF-463F-B4AE-C3EFCB453721@brawn.org> <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn <jon@brawn.org> wrote: > > > > On Jan 7, 2018, at 5:44 PM, Jon Brawn <jon@brawn.org> wrote: > > > > > >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme <gurenchan@gmail.com> > wrote: > >> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <imp@bsdimp.com> wrote: > >> > >>> > >>> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenchan@gmail.com> > >>> wrote: > >>> > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or > greater > >>>> and the topic gets derailed...? > >>>> > >>> > >>> Yes, it does. > >>> > >>> > >>>> Are you guys saying that 7-8MB/s is USB speeds? > >>>> > >>> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > USB > >>> 1.x. More recently, I've maxed out the writes on a USB stick at about > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... > I've > >>> not tried USB3 with an SSD that can do more.... > >>> > >>> Warner > >>> > >>> > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel <darius@dons.net.au= > > >>>> wrote: > >>>> > >>>>> > >>>>> > >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennjohn@gmail.com> > wrote: > >>>>>>> What is an "LG v30"? > >>>>>>> > >>>>>> It's a smartphone from LG and only supports USB2 speed. The > reported > >>>>>> transfer rate is no big surprise. > >>>>> > >>>>> OK thanks. > >>>>> > >>>>> -- > >>>>> Daniel O'Connor > >>>>> "The nice thing about standards is that there > >>>>> are so many of them to choose from." > >>>>> -- Andrew Tanenbaum > >>>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org > >>>> " > >>>> > >>> > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > >> ------------------------------------------------------------------- > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > >> Jan 7 11:56:56 blubee kernel: umass0: <StoreJet Transcend StoreJet > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = =3D > 0x0100 > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > lun 0 > >> Jan 7 11:56:56 blubee kernel: da0: <StoreJet Transcend 0> Fixed Direc= t > >> Access SPC-4 SCSI device > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > sectors) > >> Jan 7 11:56:56 blubee kernel: da0: quirks=3D0x2<NO_6_BYTE> > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait > (bufwait) @ > >> /usr/src/sys/vm/vm_pager.c:374 > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > >> /usr/src/sys/dev/md/md.c:952 > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > >> lockmgr_lock_fast_path+0x1ae > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at > VOP_LOCK1_APV+0xd9 > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > mdstart_vnode+0x442 > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1= fe > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > fork_trampoline+0xe > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait > (bufwait) @ > >> /usr/src/sys/kern/vfs_bio.c:3562 > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash > (dirhash) @ > >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > ufsdirhash_add+0x3d > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at > ufs_direnter+0x459 > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > ufs_makeinode+0x613 > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x3= 4 > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > VOP_CREATE_APV+0xd3 > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at > vn_open_cred+0x2ad > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at > kern_openat+0x212 > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > amd64_syscall+0x79b > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > Xfast_syscall+0xfb > >> > >> > >> Is the slow transfers user error? > > > > Wotcha! > > > > I don=E2=80=99t see any read or write performance figures anywhere? Als= o, is > this CURRENT? If so, aren=E2=80=99t all the debug / warning features that= are > turned on by default in CURRENT at the moment going to have an effect on > throughput? Especially if you=E2=80=99re writing through a filesystem whe= re > directory and file accesses will each require a lock to be taken, if only > for a short while? If you want to get closer to the true USB speed of the > device, stop mounting it and copying files to the filesystem, but instead > just dd data onto and off of the device directly, and measure how fast th= at > goes. Remember to backup your data from the card first=E2=80=A6 > > > > Jon. > > > > > > Also, is the SD card physically inside the phone, and you are using a USB > cord to connect the phone to the FreeBSD computer by any chance? > > Jon > > @Mark Millard I use sysutils/simple-mtpfs to mount the android device. when I mount the phone through USB this is the relevant section: /dev/fuse 356311 78912 277398 22% /mnt That's the most complicated mount process that I use, for the ssd it's just a simple mount /dev/device /mnt relevant output: /dev/da0 923913 121450 728550 14% /mnt Can you tell me what information you're looking for so that I can gather it all up and send it. @Jon Brawn I am running current because I handle admin a few other boxes that are on RELEASE so I have to run in current to make sure they don't have it. I do wonder about those locks as well but, they should only affect the multiple small files, not so much the larger files. The microsd card is physically inside the phone.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALM2mEnsbS2WijTPzihEfP2K_7H5r1hRXGuCCsuyzbw7MwA03w>