Re: USB stack

> On Jan 7, 2018, at 5:44 PM, Jon Brawn <jon_at_brawn.org> wrote:
> 
> 
>> On Jan 6, 2018, at 10:18 PM, blubee blubeeme <gurenchan_at_gmail.com> wrote:
>> 
>> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <imp_at_bsdimp.com> wrote:
>> 
>>> 
>>> 
>>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenchan_at_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_at_dons.net.au>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennjohn_at_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_at_freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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) _at_
>> /usr/src/sys/vm/vm_pager.c:374
>> Jan  7 12:06:08 blubee kernel:  2nd 0xfffff80148c425f0 zfs (zfs) _at_
>> /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) _at_
>> /usr/src/sys/kern/vfs_bio.c:3562
>> Jan  7 12:06:15 blubee kernel:  2nd 0xfffff8002bb31a00 dirhash (dirhash) _at_
>> /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