> On Jan 7, 2018, at 5:44 PM, Jon Brawn <j...@brawn.org> wrote: > > >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme <gurenc...@gmail.com> wrote: >> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <i...@bsdimp.com> wrote: >> >>> >>> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenc...@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 <dar...@dons.net.au> >>>> wrote: >>>> >>>>> >>>>> >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennj...@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-unsubscr...@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 = 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 Direct >> 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=0x2<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+0x1fe >> 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+0x34 >> 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’t see any read or write performance figures anywhere? Also, is this > CURRENT? If so, aren’t 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’re writing through a filesystem where 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 that goes. Remember to backup your > data from the card first… > > 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
smime.p7s
Description: S/MIME cryptographic signature
