Discussion:
USB stack
(too old to reply)
blubee blubeeme
2018-01-03 10:31:54 UTC
Permalink
Does FreeBSD current USB stack support usb >= 2.0 devices?

Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
O'Connor, Daniel
2018-01-03 10:41:15 UTC
Permalink
Post by blubee blubeeme
Does FreeBSD current USB stack support usb >= 2.0 devices?
Absolutely.
Post by blubee blubeeme
Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
What sort of test? What sort of device? What sort of port?

What is the output of dmesg and usbconfig?

--
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
O'Connor, Daniel
2018-01-03 19:29:08 UTC
Permalink
Post by O'Connor, Daniel
Post by blubee blubeeme
Does FreeBSD current USB stack support usb >= 2.0 devices?
Absolutely.
Post by blubee blubeeme
Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
What sort of test? What sort of device? What sort of port?
What is the output of dmesg and usbconfig?
I transferred about 30GB of audio from laptop to Samsung usb class 10 usb device connected to LG v30.
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.3: <SunplusIT Inc Chicony USB 2.0 Camera> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen0.2: <Razer Razer Abyssus 1800> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
Ugh, your mail client has mangled things, oh well.

You missed posting the output of dmesg..

What is an "LG v30"?

--
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
O'Connor, Daniel
2018-01-04 10:44:59 UTC
Permalink
Post by O'Connor, Daniel
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
blubee blubeeme
2018-01-07 03:56:09 UTC
Permalink
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?

Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
blubee blubeeme
2018-01-07 04:08:37 UTC
Permalink
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
Actually, this post: https://forums.freebsd.org/threads/41041/
on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.

I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.

Why is that?
Warner Losh
2018-01-07 04:17:54 UTC
Permalink
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
Actually, this post: https://forums.freebsd.org/threads/41041/
on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.
I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.
Why is that?
If you are copying a boatload of tiny files to USB there's two issues. Both
our UFS and MSDOS don't do well in this case. Second, for flash based USB
thumbdrives, most of them have horrible write performance unless you buy
quality drives...

Warner
blubee blubeeme
2018-01-07 04:20:56 UTC
Permalink
Post by Warner Losh
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
Actually, this post: https://forums.freebsd.org/threads/41041/
on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.
I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.
Why is that?
If you are copying a boatload of tiny files to USB there's two issues.
Both our UFS and MSDOS don't do well in this case. Second, for flash based
USB thumbdrives, most of them have horrible write performance unless you
buy quality drives...
Warner
I would consider this：
https://www.samsung.com/us/computing/memory-storage/memory-cards/micro-sd-evo-256gb-memory-card-w-adapter-mb-mc256da-am/
256GB Samsung microsd card quality.
Warner Losh
2018-01-07 04:25:06 UTC
Permalink
Post by Warner Losh
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
and the topic gets derailed...?
Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by blubee blubeeme
Post by O'Connor, Daniel
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
Actually, this post: https://forums.freebsd.org/threads/41041/
on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.
I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.
Why is that?
If you are copying a boatload of tiny files to USB there's two issues.
Both our UFS and MSDOS don't do well in this case. Second, for flash based
USB thumbdrives, most of them have horrible write performance unless you
buy quality drives...
Warner
I would consider this： https://www.samsung.com/
us/computing/memory-storage/memory-cards/micro-sd-evo-
256gb-memory-card-w-adapter-mb-mc256da-am/
256GB Samsung microsd card quality.
At most, you can get 90MB/s read/write on this card. What are you seeing?
And how are you copying?

Warner
blubee blubeeme
2018-01-07 04:28:37 UTC
Permalink
Post by Warner Losh
Post by Warner Losh
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
and the topic gets derailed...?
Are you guys saying that 7-8MB/s is USB speeds?
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by blubee blubeeme
Post by O'Connor, Daniel
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
Actually, this post: https://forums.freebsd.org/threads/41041/
on the forum from 2013 pretty well describes what I am experiencing when
moving data over USB.
I have no problems hitting very high read/ write speeds using dd or
downloading something but copying by USB is excruciatingly slow.
Why is that?
If you are copying a boatload of tiny files to USB there's two issues.
Both our UFS and MSDOS don't do well in this case. Second, for flash based
USB thumbdrives, most of them have horrible write performance unless you
buy quality drives...
Warner
I would consider this： https://www.samsung.com/
us/computing/memory-storage/memory-cards/micro-sd-evo-256gb-
memory-card-w-adapter-mb-mc256da-am/
256GB Samsung microsd card quality.
At most, you can get 90MB/s read/write on this card. What are you seeing?
And how are you copying?
Warner
I use the phone, LG V30 to record basically ungraded RAW video files to the
microsd card; they are large files.
I transfer them to my computer copy a backup to the 1TB driver; then do
edits/ color grading, etc in blender,
then I transfer the finished to another 1TB hdd for backup as well.
Warner Losh
2018-01-07 04:20:19 UTC
Permalink
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
reebsd.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>
/usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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
/usr/src/sys/kern/vfs_bio.c:3562
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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?
It's likely due to the slow UFS issue...

Warner
blubee blubeeme
2018-01-07 04:25:17 UTC
Permalink
Post by Warner Losh
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
reebsd.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: 1st 0xfffffe07c26336c0 bufwait (bufwait)
@ /usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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: 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: #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?
It's likely due to the slow UFS issue...
Warner
The Transcend ssd is formated ZFS, I use it as a backup.

The microsd might suffer from what you say since it's formatted by Android
but I do not get these slow transfer speeds on other OS.

so a quick roundup.
1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds;
let's say that's because of the Android OS default format.
I only get these slow speeds on FreeBSD, why is that?

2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above;
are the slow speeds user error or something else?

@Warner Losh
what was your setup where you were able to transfer 23-75MB/s to your USB
device?
Tomoaki AOKI
2018-01-07 05:32:50 UTC
Permalink
On Sun, 7 Jan 2018 12:25:17 +0800
Post by blubee blubeeme
Post by Warner Losh
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
reebsd.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: 1st 0xfffffe07c26336c0 bufwait (bufwait)
@ /usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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: 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: #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?
It's likely due to the slow UFS issue...
Warner
The Transcend ssd is formated ZFS, I use it as a backup.
The microsd might suffer from what you say since it's formatted by Android
but I do not get these slow transfer speeds on other OS.
so a quick roundup.
1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds;
let's say that's because of the Android OS default format.
I only get these slow speeds on FreeBSD, why is that?
Warner is asking "how are you copying" on another thread. How?
Although it's over LAN, I experience slooooow copying using shells/fd
to copy (1-2MB/s), while 10-60MB/s by /bin/cp.
Not measured, but feeling alike for USB memstick (same file to same
memstick, with at least one reboot between each copy).
It shoud be said to other filers, which doesn't call /bin/cp internally
or does just what /bin/cp does.

As for USB memsticks, I had a problematic one, which caused plenty of
errors, maybe by mismatched quirks. It worked but very slow, sometimes
suddenly disappeares, although it claimed 90MB/s capable. :-(
Post by blubee blubeeme
2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above;
are the slow speeds user error or something else?
@Warner Losh
what was your setup where you were able to transfer 23-75MB/s to your USB
device?
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
--
Tomoaki AOKI <***@dec.sakura.ne.jp>
blubee blubeeme
2018-01-07 05:44:18 UTC
Permalink
Post by Tomoaki AOKI
On Sun, 7 Jan 2018 12:25:17 +0800
Post by blubee blubeeme
Post by Warner Losh
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
Post by Warner Losh
Post by blubee blubeeme
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by Warner Losh
75MB/s (the fastest it will do), which isn't possible with USB
2.0... I've
Post by blubee blubeeme
Post by Warner Losh
not tried USB3 with an SSD that can do more....
Warner
Post by blubee blubeeme
On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel <
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by O'Connor, Daniel
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
Post by blubee blubeeme
Post by Warner Losh
Post by blubee blubeeme
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
reebsd.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
Post by blubee blubeeme
Post by Warner Losh
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)
Post by blubee blubeeme
Post by Warner Losh
Jan 7 11:56:56 blubee kernel: da0: quirks=0x2<NO_6_BYTE>
Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait
(bufwait)
Post by blubee blubeeme
Post by Warner Losh
@ /usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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
Post by blubee blubeeme
Post by Warner Losh
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
Post by blubee blubeeme
Post by Warner Losh
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: 1st 0xfffffe07c41d5dc0 bufwait
(bufwait)
Post by blubee blubeeme
Post by Warner Losh
@ /usr/src/sys/kern/vfs_bio.c:3562
Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash
(dirhash)
Post by blubee blubeeme
Post by Warner Losh
@ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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
Post by blubee blubeeme
Post by Warner Losh
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
Post by blubee blubeeme
Post by Warner Losh
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
Post by blubee blubeeme
Post by Warner Losh
Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at
kern_openat+0x212
Post by blubee blubeeme
Post by Warner Losh
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?
It's likely due to the slow UFS issue...
Warner
The Transcend ssd is formated ZFS, I use it as a backup.
The microsd might suffer from what you say since it's formatted by
Android
Post by blubee blubeeme
but I do not get these slow transfer speeds on other OS.
so a quick roundup.
1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds;
let's say that's because of the Android OS default format.
I only get these slow speeds on FreeBSD, why is that?
Warner is asking "how are you copying" on another thread. How?
Although it's over LAN, I experience slooooow copying using shells/fd
to copy (1-2MB/s), while 10-60MB/s by /bin/cp.
Not measured, but feeling alike for USB memstick (same file to same
memstick, with at least one reboot between each copy).
It shoud be said to other filers, which doesn't call /bin/cp internally
or does just what /bin/cp does.
As for USB memsticks, I had a problematic one, which caused plenty of
errors, maybe by mismatched quirks. It worked but very slow, sometimes
suddenly disappeares, although it claimed 90MB/s capable. :-(
Post by blubee blubeeme
2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above;
are the slow speeds user error or something else?
@Warner Losh
what was your setup where you were able to transfer 23-75MB/s to your USB
device?
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org"
--
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
I copy using /bin/cp to and from /mnt after I mount said device.
The devices are;
LG v30 with 256GB Samsung microsd
1TB Trascend SSD

Both were linked earlier in this thread.

so, any reason why i'm getting these slow speeds?

I asked what was his setup to get 23-75MB/s but no response to that
question as of yet, why?
Warner Losh
2018-01-07 04:11:05 UTC
Permalink
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
blubee blubeeme
2018-01-07 04:18:17 UTC
Permalink
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
"
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?
Freddie Cash
2018-01-07 08:27:16 UTC
Permalink
Forgot to include the list. Resending.

---------- Forwarded message ----------
From: "Freddie Cash" <***@gmail.com>
Date: Jan 7, 2018 12:26 AM
Subject: Re: USB stack
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>


Is the slow transfers user error?


You'll need to post /var/run/dmesg.boot somewhere so we can see how your
USB controllers are being detected and the different buses are being
configured, and which bus/controller the USB devices are attaching too. You
haven't shown enough information yet to be able to help you.

Cheers,
Freddie
Jon Brawn
2018-01-08 00:03:28 UTC
Permalink
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
"
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>
/usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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
/usr/src/sys/kern/vfs_bio.c:3562
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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
blubee blubeeme
2018-01-08 05:17:22 UTC
Permalink
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by blubee blubeeme
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org
Post by blubee blubeeme
"
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: 1st 0xfffffe07c26336c0 bufwait
/usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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: 1st 0xfffffe07c41d5dc0 bufwait
/usr/src/sys/kern/vfs_bio.c:3562
Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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
@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.
Gary Jennejohn
2018-01-08 19:14:20 UTC
Permalink
On Mon, 8 Jan 2018 13:17:22 +0800
Post by blubee blubeeme
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by blubee blubeeme
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org
Post by blubee blubeeme
"
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: 1st 0xfffffe07c26336c0 bufwait
/usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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: 1st 0xfffffe07c41d5dc0 bufwait
/usr/src/sys/kern/vfs_bio.c:3562
Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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
@Mark Millard
I use sysutils/simple-mtpfs to mount the android device.
/dev/fuse 356311 78912 277398 22%
/mnt
FUSE = Filesystem in Userspace and is inherently slow. You can't
expect good performance from it.

For example, when I mount NTFS with FUSE I get only about 30MBps.
Windows manages about 100MBps.

I mounted the SD card in my smart phone under Windows and got a
transfer rate of about 23MBps. Given how slow fuse is I'd say
that the aprroximately 7MBps you're seeing is to be expected.

[snip]
--
Gary Jennejohn
blubee blubeeme
2018-01-07 10:09:07 UTC
Permalink
blubee blubeeme gurenchan at gmail.com wrote on
Post by blubee blubeeme
Does FreeBSD current USB stack support usb >= 2.0 devices?
Testing out the USB devices support I get about 7.2-7.8 megabytes per
second which seems odd.
FreeBSD machine: Pine64+ 2GB? Ryzen Threadripper 1950X? . . .?
It would help to specify the type of system and its
relevant properties (not just the processor).
What independent channels are in use? Any? Or are
the source and destination on the same channel at
some stage?
Post by blubee blubeeme
I transferred about 30GB of audio from laptop
The 30GB was on what type of device? Plugged in to what?
What file system?
ZFS file system on the main machine and the 1TB Transcend drive.
I am not 100% sure what format android device is;
I can look into this further but I've been testing on the Transcend device
linked above in this list.
Post by blubee blubeeme
to Samsung usb class 10 usb
device connected to LG v30.
What file system?
Android 7.1
And in another message (indicating the other direction
I transfer from the phone to the computer.
Post by blubee blubeeme
I use the phone, LG V30 to record basically ungraded RAW video files to
the
Post by blubee blubeeme
microsd card; they are large files.
I transfer them to my computer copy a backup to the 1TB driver; then do
edits/ color grading, etc in blender,
then I transfer the finished to another 1TB hdd for backup as well.
So the LG v30 was plugged in as a USB device, effectively
acting as a media reader/writer? What file system?
(It seems unlikely that the LG v30 would use a FreeBSD
native file system to record RAW video files.)
Going the other direction of providing some examples
of files copies for UFS. . .
Note: These are based on head -r327485 with
non-debug kernel builds.
(lots of small files on a fairly low-end FreeBSD
machine)
RPi2B V1.1 (with USB 2.0)
A) USB 3.0 SSD stick (USB 2.0 compatible) with the root file system
B) 64 GB eMMC on a usdcard adapter, plugged into a USB 3.0 media
reader/writer (USB 2.0 compatible).
mount -o noatime in use for (A) and (B). UFS file systems.
soft-updates enabled.
cp -ax /usr/src/ /mnt/root/srccpy_test
dT: 1.007s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 255 255 5501 1.9 0 0 0.0 0 0
0.0 48.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da3
64 426 1 32 221.4 425 6287 140.4 0 0
0.0 62.9| da4
Note that the read kBps + write kBps means around 11MiByte/s for r+w.
(There is only one USB connection at the RPi2B V1.1 here,
not multiple, independent channels.)
This is an example copying [multiple small files] to the 1TB drive.
------------------------------------------------------------------------------------------------------------------
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 547 290 35239 2.0 4 16 73.1 249 44291
93.7 48.8| nvd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| md99
21 333 0 0 0.0 333 36040 16.2 0 0
0.0 76.2| da1
------------------------------------------------------------------------------------------------------------------
dT: 1.007s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 393 393 5295 1.3 0 0 0.0 0 0
0.0 50.7| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da3
46 102 2 64 2.9 100 2101 116.9 0 0
0.0 19.5| da4
The above last shows a period with around 7 MiBytes/s for r+w.
dT: 1.007s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
16 245 245 9761 37.4 0 0 0.0 0 0
0.0 77.4| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da3
28 481 0 0 0.0 481 10809 95.1 0 0
0.0 93.7| da4
That last shows a period with around 20 MiBytes/s for r+w.
(Probably copying fewer, bigger files at the time.)
This might be around 8 MiBytes/s being written (mean rate
overall for the copy).
Example high end machine copying /usr/src/ to
fast USB 3.0 SSD stick over USB 3.0, all UFS
Ryzen Threadripper 1950X
Running FreeBSD under Hyper-V under Windows 10 Pro
Samsung 960 Pro 1TB NVMe root root UFS file system
USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection (UFS)
(These are Hyper-V "Physical disk drive" bindings,
not NTFS files used as a virtual file system.)
mount -o noatime in use for both. UFS file systems.
soft-updates.
cp -ax /usr/src/ /mnt/root/srccpy_test
dT: 1.023s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 6519 6519 103339 0.1 0 0 0.0 0 0
0.0 35.5| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
676 6635 0 0 0.0 6635 119898 43.6 0 0
0.0 43.0| da3
dT: 1.058s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 6839 6839 106968 0.1 0 0 0.0 0 0
0.0 34.7| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
1 6967 0 0 0.0 6967 133410 42.4 0 0
0.0 46.1| da3
In this context there are 2 independent channels
and reading from one and writing from the other
can potentially happen at the same time.
Vastly faster than 8 MiBytes/s mean rate for writes.
Example high end machine copying /usr/src/ from
and to fast USB 3.0 SSD sticks over USB 3.0, all
Ryzen Threadripper 1950X
Running FreeBSD under Hyper-V under Windows 10 Pro
USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection (UFS)
Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection
(UFS)
(These are Hyper-V "Physical disk drive" bindings,
not NTFS files used as a virtual file system.)
mount -o noatime in use for both. UFS file systems.
soft-updates.
cp -ax /mnt/usr/src /media/root/srccpy_test
dT: 1.008s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 2388 2388 36317 0.3 0 0 0.0 0 0
0.0 80.5| da3
0 2197 0 0 0.0 2197 38206 35.7 0 0
0.0 14.8| da4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 2443 2443 44537 0.3 0 0 0.0 0 0
0.0 82.5| da3
0 2309 0 0 0.0 2309 51142 36.0 0 0
0.0 18.7| da4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 2664 2664 65516 0.3 0 0 0.0 0 0
0.0 82.8| da3
0 2932 0 0 0.0 2932 84290 34.5 0 0
0.0 32.2| da4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
dT: 1.047s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 2542 2542 28571 0.3 0 0 0.0 0 0
0.0 77.7| da3
778 1803 13 428 0.4 1789 15985 27.8 0 0
0.0 8.0| da4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
I doubt that this has independent channels at
all stages.
Faster than 8 MiBytes/s mean rate for writes.
Example high end machine copying /usr/src/ from
and to fast USB 3.0 SSD sticks over USB 2.0, all
Ryzen Threadripper 1950X
Running FreeBSD under Hyper-V under Windows 10 Pro
USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection (UFS)
Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection
(UFS)
(These are Hyper-V "Physical disk drive" bindings,
not NTFS files used as a virtual file system.)
mount -o noatime in use for both. UFS file systems.
soft-updates.
cp -ax /mnt/usr/src /media/root/srccpy_test
dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 812 812 10487 0.8 0 0 0.0 0 0
0.0 62.6| da3
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
0 949 5 150 66.9 944 13853 229.0 0 0
0.0 48.6| da4
dT: 1.042s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 1093 1093 12903 0.7 0 0 0.0 0 0
0.0 71.5| da3
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
180 1003 8 246 94.9 996 9443 242.7 0 0
0.0 35.9| da4
dT: 1.068s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
1 617 617 15973 1.4 0 0 0.0 0 0
0.0 87.4| da3
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
1 1147 2 60 49.2 1145 17220 187.0 0 0
0.0 78.1| da4
Still solidly more than 8 MiBytes/s being written (mean rate).
Having a few large files to copy instead should normally
be faster in each of the earlier example contexts.
But no hard drives or flash drives were involved: all SSDs of
one form or another. Hard drive properties and file system
fragmentation could make things much slower by comparison.
Flash drives also can have issues.
This is a larger file, not the largest but hey
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 4 0 0 0.0 2 8 0.0 0 0
0.0 0.1| nvd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| md99
128 982 1 32 58.8 981 125428 110.5 0 0
0.0 100.0| da1

===
Mark Millard
markmi at dsl-only.net
I'm having a few issues with USB but just to simplify things;
let's focus on speed for the device that I am currently using.

Device spec:
FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
14:54:55 UTC 2017
***@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

pciconf -lv
***@pci0:0:0:0: class=0x060000 card=0x6a011558 chip=0x19108086 rev=0x07
hdr=0x00
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host
Bridge/DRAM Registers'
class = bridge
subclass = HOST-PCI
***@pci0:0:1:0: class=0x060400 card=0x6a011558 chip=0x19018086 rev=0x07
hdr=0x01
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe
Controller (x16)'
class = bridge
subclass = PCI-PCI
***@pci0:0:20:0: class=0x0c0330 card=0x6a011558 chip=0xa12f8086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class = serial bus
subclass = USB
***@pci0:0:22:0: class=0x078000 card=0x6a011558 chip=0xa13a8086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class = simple comms
***@pci0:0:23:0: class=0x010601 card=0x6a011558 chip=0xa1038086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class = mass storage
subclass = SATA
***@pci0:0:28:0: class=0x060400 card=0x6a011558 chip=0xa1108086 rev=0xf1
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class = bridge
subclass = PCI-PCI
***@pci0:0:28:4: class=0x060400 card=0x6a011558 chip=0xa1148086 rev=0xf1
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class = bridge
subclass = PCI-PCI
***@pci0:0:28:6: class=0x060400 card=0x6a011558 chip=0xa1168086 rev=0xf1
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class = bridge
subclass = PCI-PCI
***@pci0:0:29:0: class=0x060400 card=0x6a011558 chip=0xa1188086 rev=0xf1
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class = bridge
subclass = PCI-PCI
***@pci0:0:31:0: class=0x060100 card=0x6a011558 chip=0xa14e8086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class = bridge
subclass = PCI-ISA
***@pci0:0:31:2: class=0x058000 card=0x6a011558 chip=0xa1218086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PMC'
class = memory
***@pci0:0:31:3: class=0x040300 card=0x6a021558 chip=0xa1708086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H HD Audio'
class = multimedia
subclass = HDA
***@pci0:0:31:4: class=0x0c0500 card=0x6a011558 chip=0xa1238086 rev=0x31
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SMBus'
class = serial bus
subclass = SMBus
***@pci0:1:0:0: class=0x030000 card=0x6a021558 chip=0x1ba110de rev=0xa1
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GP104M [GeForce GTX 1070 Mobile]'
class = display
subclass = VGA
***@pci0:109:0:0: class=0xff0000 card=0x6a011558 chip=0x528710ec rev=0x01
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8411B PCI Express Card Reader'
***@pci0:109:0:1: class=0x020000 card=0x6a011558 chip=0x816810ec rev=0x12
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
***@pci0:110:0:0: class=0x028000 card=0x50108086 chip=0x095a8086 rev=0x48
hdr=0x00
vendor = 'Intel Corporation'
device = 'Wireless 7265'
class = network
***@pci0:111:0:0: class=0x010802 card=0x390a8086 chip=0xf1a58086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
class = mass storage
subclass = NVM

I have the 1TB Transcend drive that I linked before [ZFS format]
I have a LG v30 with 256GB Samsung microsd.

I do not transfer to multiple USB devices at any one time.

I either transfer from phone [LG v30] to this machine; [pciconf output
above]
Transfer from this machine to 1TB USB device for backup.

I never have two or more USB devices connected to this machine.
Mark Millard
2018-01-07 10:44:18 UTC
Permalink
[The following notes a problem with how a test was done.
I omit the rest of the material.]

On 2018-Jan-7, at 2:09 AM, blubee blubeeme <gurenchan at gmail.com> wrote:

. . .
This is a larger file, not the largest but hey
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 4 0 0 0.0 2 8 0.0 0 0 0.0 0.1| nvd0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99
128 982 1 32 58.8 981 125428 110.5 0 0 0.0 100.0| da1
. . .

Note that almost complete lack of kBps near r/s but the large
kBps near w/s.

It appears that the file has been cached in RAM and is not
being read from media at all. So this test is of a RAM to
disk transfer, not disk to disk, as far as I can tell.

You need to avoid re-reading the same file unless you
dismount and remount between tests or some such. Or
just use a different file not copied since booting (that
file may or may not be a previous copy of the same file
by content).

See if you can get gstat -pd results that show both
read kBps and write kBps figures.

===
Mark Millard
markmi at dsl-only.net
Mark Millard
2018-01-07 12:13:33 UTC
Permalink
[I add an example of a none-USB to USB2 copy and
a USB2 to non-USB copy. They do not show any
< 8 MiByte/s bottlenecks.]
[The other numbers show lots of delete activity on nvd0,
not just primarily reads. Also: Can you test a different
USB device, such as a USB SSD stick?]
Post by Mark Millard
[The following notes a problem with how a test was done.
I omit the rest of the material.]
. . .
This is a larger file, not the largest but hey
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 4 0 0 0.0 2 8 0.0 0 0 0.0 0.1| nvd0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99
128 982 1 32 58.8 981 125428 110.5 0 0 0.0 100.0| da1
. . .
Note that almost complete lack of kBps near r/s but the large
kBps near w/s.
It appears that the file has been cached in RAM and is not
being read from media at all. So this test is of a RAM to
disk transfer, not disk to disk, as far as I can tell.
You need to avoid re-reading the same file unless you
dismount and remount between tests or some such. Or
just use a different file not copied since booting (that
file may or may not be a previous copy of the same file
by content).
See if you can get gstat -pd results that show both
read kBps and write kBps figures.
Can you test another USB device, such as a USB SSD
stick, sometime known to be reliably fast and not
involving reading from the LG v30?
From what I read Android has many file systems supported
or used at one time: ext4, f2fs, yaffs, yaffs2,
vfat, msdos being in the list. Normal SD and SDHC files
systems are FAT32 and SDXC is exFAT.
So "Android 7.1" does not answer my question about which
file system is actually on the usdcard being used. I'd
guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but
I do not really know.
My results show that getting above 8 MiBytes/s over
USB 2.0 is supported for other than the rather low end
of the FreeBSD range of systems. Beyond that is something
more specific to your context and not involved in mine.
The file system might be involved.
So far, from the tables and what you have written, the
LG v30 is required to be involved for the slowdown
to sub 8 MiBytes/s. This is part of why I ask about
testing an alternative USB device that is fast: it
tests USB without involving the LG v30 or the usdcard.
If USB ends up faster, then it is not USB's "stack" that
is the primary source of the current bottleneck for your
context: something else is also involved, such as the
file system may be.
Can you show gstat -pd output for copying from the
LG v30? Copying to the 1TB USB backup device? The
%busy figures might be interesting.
This is an example copying [multiple small files] to the 1TB drive.
------------------------------------------------------------------------------------------------------------------
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 547 290 35239 2.0 4 16 73.1 249 44291 93.7 48.8| nvd0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99
21 333 0 0 0.0 333 36040 16.2 0 0 0.0 76.2| da1
------------------------------------------------------------------------------------------------------------------
This shows lots of deletes per second for some reason.
Did you move instead of copy? After each file was copied,
was it then deleted?
It is possible that the deletes slowed this down,
whatever they were from.
Here are "gstat -pd" samples from during a:

cp -ax /usr/src /media/root/srccpy_test
(which is to USB2 from non-USB.)

dT: 1.071s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 2346 2346 20234 0.1 0 0 0.0 0 0 0.0 11.9| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
1162 1375 21 658 60.1 1354 26962 331.4 0 0 0.0 81.1| da4

dT: 1.069s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 859 859 7657 0.1 0 0 0.0 0 0 0.0 4.8| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
841 1544 7 240 5.3 1536 31956 261.7 0 0 0.0 93.0| da4

dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 1709 1709 15074 0.1 0 0 0.0 0 0 0.0 9.3| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
1257 1423 15 479 43.9 1408 31011 277.5 0 0 0.0 91.9| da4

dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 4350 4350 44982 0.1 0 0 0.0 0 0 0.0 22.0| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
943 1028 27 867 5.0 1001 19315 614.8 0 0 0.0 59.8| da4



Here are "gstat -pd" samples from during a:

cp -ax /media/usr/src /root/srccpy_test
(which is to non-USB from USB2.)

dT: 1.069s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 306 0 0 0.0 306 38383 0.3 0 0 0.0 2.6| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
1 548 548 37533 52.7 0 0 0.0 0 0 0.0 100.2| da4

dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 934 7 209 0.1 927 12438 2.2 0 0 0.0 1.5| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
1 1296 1296 20674 0.7 0 0 0.0 0 0 0.0 90.1| da4

dT: 1.070s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| fd0
0 1208 5 150 0.1 1203 32069 2.3 0 0 0.0 2.2| da0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| da3
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| cd0
1 931 931 27073 6.9 0 0 0.0 0 0 0.0 93.6| da4


No bottlenecks causing < 8 MiBytes/s: much faster then that.
USB2 is not such a bottleneck in my context.

But, again, all UFS and the USB SSD stick is the slower
device but is, in turn, limited by USB2 in these.

===
Mark Millard
markmi at dsl-only.net
Mark Millard
2018-01-07 17:41:43 UTC
Permalink
I ran this test and here's some results.
18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
multiple small files from laptop to phone: https://imgur.com/a/B4v4y
multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
The files are missing timestamps but the originals were taken with scrot and have timestamps available here: https://nofile.io/f/mzKnkpM9CyC/stats.tar.gz2
as far as why there's such high deletions? I can't say I'm only using cp.
I assume that md99 is for a file-based swap-space, such as
via /var/swap0 file. (As a side note I warn about bugzilla
206048 for such contexts.) Otherwise please describe how
md99 is created. (Below I assume the swap-space usage of
md99.)

The only other device that your pictures show is your
NVMe device nvd0.

No picture shows a device for the LG v30 when it is mentioned
above as being copied to or from. How is it that there is no
mounted device shown for the LG v30?

No picture shows a device for the SSD when it is mentioned
above as being copied to or from. How is it that there
is no mounted device shown for the SSD?

Without a device displayed for the LG-v30/SSD there is nothing
displayed for its reads or writes. This makes the gstat -pd
useless.

May be the p needs to be omitted for some reason? gstat -d

===
Mark Millard
markmi at dsl-only.net
blubee blubeeme
2018-01-07 18:23:36 UTC
Permalink
I ran this test and here's some results.
18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
multiple small files from laptop to phone: https://imgur.com/a/B4v4y
multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
The files are missing timestamps but the originals were taken with scrot
and have timestamps available here: https://nofile.io/f/
mzKnkpM9CyC/stats.tar.gz2
as far as why there's such high deletions? I can't say I'm only using cp.
I assume that md99 is for a file-based swap-space, such as
via /var/swap0 file. (As a side note I warn about bugzilla
206048 for such contexts.) Otherwise please describe how
md99 is created. (Below I assume the swap-space usage of
md99.)
The only other device that your pictures show is your
NVMe device nvd0.
No picture shows a device for the LG v30 when it is mentioned
above as being copied to or from. How is it that there is no
mounted device shown for the LG v30?
No picture shows a device for the SSD when it is mentioned
above as being copied to or from. How is it that there
is no mounted device shown for the SSD?
Without a device displayed for the LG-v30/SSD there is nothing
displayed for its reads or writes. This makes the gstat -pd
useless.
May be the p needs to be omitted for some reason? gstat -d
===
Mark Millard
markmi at dsl-only.net
You are correct that md99 is a file backed swap disk, I am aware of the
issues but I had to test some things out.

Those tests earlier was a huge time sink.
Here's the dmesg output from earlier:
------------------------
Jan 7 19:13:17 blubee kernel: Copyright (c) 1992-2017 The FreeBSD Project.
Jan 7 19:13:17 blubee kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Jan 7 19:13:17 blubee kernel: The Regents of the University of California.
All rights reserved.
Jan 7 19:13:17 blubee kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.
Jan 7 19:13:17 blubee kernel: FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21
14:54:55 UTC 2017
Jan 7 19:13:17 blubee kernel:
***@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
Jan 7 19:13:17 blubee kernel: FreeBSD clang version 5.0.0
(tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn)
Jan 7 19:13:17 blubee kernel: WARNING: WITNESS option enabled, expect
reduced performance.
Jan 7 19:13:17 blubee kernel: VT(efifb): resolution 3840x2160
Jan 7 19:13:17 blubee kernel: CPU: Intel(R) Core(TM) i7-6700HQ CPU @
2.60GHz (2592.11-MHz K8-class CPU)
Jan 7 19:13:17 blubee kernel: Origin="GenuineIntel" Id=0x506e3
Family=0x6 Model=0x5e Stepping=3
Jan 7 19:13:17 blubee kernel:
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Jan 7 19:13:17 blubee kernel:
Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
Jan 7 19:13:17 blubee kernel: AMD
Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
Jan 7 19:13:17 blubee kernel: AMD Features2=0x121<LAHF,ABM,Prefetch>
Jan 7 19:13:17 blubee kernel: Structured Extended
Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
Jan 7 19:13:17 blubee kernel: XSAVE
Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
Jan 7 19:13:17 blubee kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
Jan 7 19:13:17 blubee kernel: TSC: P-state invariant, performance
statistics
Jan 7 19:13:17 blubee kernel: real memory = 34359738368 (32768 MB)
Jan 7 19:13:17 blubee kernel: avail memory = 33147957248 (31612 MB)
Jan 7 19:13:17 blubee kernel: Event timer "LAPIC" quality 600
Jan 7 19:13:17 blubee kernel: ACPI APIC Table: <ALASKA A M I >
Jan 7 19:13:17 blubee kernel: FreeBSD/SMP: Multiprocessor System Detected:
8 CPUs
Jan 7 19:13:17 blubee kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2
hardware threads
Jan 7 19:13:17 blubee kernel: random: unblocking device.
Jan 7 19:13:17 blubee kernel: ioapic0 <Version 2.0> irqs 0-119 on
motherboard
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #1 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #4 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #2 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #3 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #6 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #5 Launched!
Jan 7 19:13:17 blubee kernel: SMP: AP CPU #7 Launched!
Jan 7 19:13:17 blubee kernel: Timecounter "TSC-low" frequency 1296054319
Hz quality 1000
Jan 7 19:13:17 blubee kernel: random: entropy device external interface
Jan 7 19:13:17 blubee kernel: netmap: loaded module
Jan 7 19:13:17 blubee kernel: [ath_hal] loaded
Jan 7 19:13:17 blubee kernel: module_register_init: MOD_LOAD (vesa,
0xffffffff80f95c20, 0) error 19
Jan 7 19:13:17 blubee kernel: random: registering fast source Intel Secure
Key RNG
Jan 7 19:13:17 blubee kernel: random: fast provider: "Intel Secure Key RNG"
Jan 7 19:13:17 blubee kernel: kbd1 at kbdmux0
Jan 7 19:13:17 blubee kernel: nexus0
Jan 7 19:13:17 blubee kernel: cryptosoft0: <software crypto> on motherboard
Jan 7 19:13:17 blubee kernel: acpi0: <ALASKA A M I > on motherboard
Jan 7 19:13:17 blubee kernel: acpi0: Power Button (fixed)
Jan 7 19:13:17 blubee kernel: cpu0: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu1: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu2: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu3: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu4: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu5: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu6: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: cpu7: <ACPI CPU> on acpi0
Jan 7 19:13:17 blubee kernel: hpet0: <High Precision Event Timer> iomem
0xfed00000-0xfed003ff on acpi0
Jan 7 19:13:17 blubee kernel: Timecounter "HPET" frequency 24000000 Hz
quality 950
Jan 7 19:13:17 blubee kernel: Event timer "HPET" frequency 24000000 Hz
quality 550
Jan 7 19:13:17 blubee kernel: atrtc0: <AT realtime clock> port 0x70-0x77
irq 8 on acpi0
Jan 7 19:13:17 blubee kernel: atrtc0: Warning: Couldn't map I/O.
Jan 7 19:13:17 blubee kernel: atrtc0: registered as a time-of-day clock,
resolution 1.000000s
Jan 7 19:13:17 blubee kernel: Event timer "RTC" frequency 32768 Hz quality
0
Jan 7 19:13:17 blubee kernel: attimer0: <AT timer> port
0x40-0x43,0x50-0x53 irq 0 on acpi0
Jan 7 19:13:17 blubee kernel: Timecounter "i8254" frequency 1193182 Hz
quality 0
Jan 7 19:13:17 blubee kernel: Event timer "i8254" frequency 1193182 Hz
quality 100
Jan 7 19:13:17 blubee kernel: Timecounter "ACPI-fast" frequency 3579545 Hz
quality 900
Jan 7 19:13:17 blubee kernel: acpi_timer0: <24-bit timer at 3.579545MHz>
port 0x1808-0x180b on acpi0
Jan 7 19:13:17 blubee kernel: acpi_ec0: <Embedded Controller: GPE 0x3>
port 0x62,0x66 on acpi0
Jan 7 19:13:17 blubee kernel: pcib0: <ACPI Host-PCI bridge> port
0xcf8-0xcff on acpi0
Jan 7 19:13:17 blubee kernel: pci0: <ACPI PCI bus> on pcib0
Jan 7 19:13:17 blubee kernel: pcib1: <ACPI PCI-PCI bridge> at device 1.0
on pci0
Jan 7 19:13:17 blubee kernel: pci1: <ACPI PCI bus> on pcib1
Jan 7 19:13:17 blubee kernel: vgapci0: <VGA-compatible display> port
0xe000-0xe07f mem
0xdb000000-0xdbffffff,0x90000000-0x9fffffff,0xa0000000-0xa1ffffff at device
0.0 on pci1
Jan 7 19:13:17 blubee kernel: nvidia0: <GeForce GTX 1070> on vgapci0
Jan 7 19:13:17 blubee kernel: vgapci0: child nvidia0 requested
pci_enable_io
Jan 7 19:13:17 blubee kernel: vgapci0: child nvidia0 requested
pci_enable_io
Jan 7 19:13:17 blubee kernel: vgapci0: Boot video device
Jan 7 19:13:17 blubee kernel: xhci0: <Intel Sunrise Point USB 3.0
controller> mem 0x2ffff10000-0x2ffff1ffff at device 20.0 on pci0
Jan 7 19:13:17 blubee kernel: xhci0: 32 bytes context size, 64-bit DMA
Jan 7 19:13:17 blubee kernel: usbus0 on xhci0
Jan 7 19:13:17 blubee kernel: usbus0: 5.0Gbps Super Speed USB v3.0
Jan 7 19:13:17 blubee kernel: pci0: <simple comms> at device 22.0 (no
driver attached)
Jan 7 19:13:17 blubee kernel: ahci0: <Intel Sunrise Point AHCI SATA
controller> port 0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem
0xdc404000-0xdc405fff,0xdc407000-0xdc4070ff,0xdc406000-0xdc4067ff at device
23.0 on pci0
Jan 7 19:13:17 blubee kernel: ahci0: AHCI v1.31 with 3 6Gbps ports, Port
Multiplier not supported
Jan 7 19:13:17 blubee kernel: ahcich1: <AHCI channel> at channel 1 on ahci0
Jan 7 19:13:17 blubee kernel: ahcich2: <AHCI channel> at channel 2 on ahci0
Jan 7 19:13:17 blubee kernel: ahcich3: <AHCI channel> at channel 3 on ahci0
Jan 7 19:13:17 blubee kernel: ahciem0: <AHCI enclosure management bridge>
on ahci0
Jan 7 19:13:17 blubee kernel: ahciem0: EM timeout
Jan 7 19:13:17 blubee kernel: device_attach: ahciem0 attach returned 6
Jan 7 19:13:17 blubee kernel: pcib2: <ACPI PCI-PCI bridge> at device 28.0
on pci0
Jan 7 19:13:17 blubee kernel: pcib2: [GIANT-LOCKED]
Jan 7 19:13:17 blubee kernel: pcib3: <ACPI PCI-PCI bridge> at device 28.4
on pci0
Jan 7 19:13:17 blubee kernel: pci2: <ACPI PCI bus> on pcib3
Jan 7 19:13:17 blubee kernel: pci2: <unknown> at device 0.0 (no driver
attached)
Jan 7 19:13:17 blubee kernel: re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G
PCIe Gigabit Ethernet> port 0xd000-0xd0ff mem
0xdc304000-0xdc304fff,0xdc300000-0xdc303fff at device 0.1 on pci2
Jan 7 19:13:17 blubee kernel: re0: Using 1 MSI-X message
Jan 7 19:13:17 blubee kernel: re0: turning off MSI enable bit.
Jan 7 19:13:17 blubee kernel: re0: ASPM disabled
Jan 7 19:13:17 blubee kernel: re0: Chip rev. 0x5c800000
Jan 7 19:13:17 blubee kernel: re0: MAC rev. 0x00000000
Jan 7 19:13:17 blubee kernel: miibus0: <MII bus> on re0
Jan 7 19:13:17 blubee kernel: rgephy0: <RTL8251/8153 1000BASE-T media
interface> PHY 1 on miibus0
Jan 7 19:13:17 blubee kernel: rgephy0: none, 10baseT, 10baseT-FDX,
10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
Jan 7 19:13:17 blubee kernel: re0: Using defaults for TSO: 65518/35/2048
Jan 7 19:13:17 blubee kernel: re0: Ethernet address: 80:fa:5b:3a:2f:8b
Jan 7 19:13:17 blubee kernel: re0: netmap queues/slots: TX 1/256, RX 1/256
Jan 7 19:13:17 blubee kernel: pcib4: <ACPI PCI-PCI bridge> at device 28.6
on pci0
Jan 7 19:13:17 blubee kernel: pci3: <ACPI PCI bus> on pcib4
Jan 7 19:13:17 blubee kernel: iwm0: <Intel(R) Dual Band Wireless AC 7265>
mem 0xdc200000-0xdc201fff at device 0.0 on pci3
Jan 7 19:13:17 blubee kernel: pcib5: <ACPI PCI-PCI bridge> at device 29.0
on pci0
Jan 7 19:13:17 blubee kernel: pci4: <ACPI PCI bus> on pcib5
Jan 7 19:13:17 blubee kernel: nvme0: <Generic NVMe Device> mem
0xdc100000-0xdc103fff at device 0.0 on pci4
Jan 7 19:13:17 blubee kernel: isab0: <PCI-ISA bridge> at device 31.0 on
pci0
Jan 7 19:13:17 blubee kernel: isa0: <ISA bus> on isab0
Jan 7 19:13:17 blubee kernel: pci0: <memory> at device 31.2 (no driver
attached)
Jan 7 19:13:17 blubee kernel: hdac0: <Intel Sunrise Point HDA Controller>
mem 0x2ffff20000-0x2ffff23fff,0x2ffff00000-0x2ffff0ffff at device 31.3 on
pci0
Jan 7 19:13:17 blubee kernel: acpi_button0: <Power Button> on acpi0
Jan 7 19:13:17 blubee kernel: acpi_button1: <Sleep Button> on acpi0
Jan 7 19:13:17 blubee kernel: acpi_lid0: <Control Method Lid Switch> on
acpi0
Jan 7 19:13:17 blubee kernel: acpi_acad0: <AC Adapter> on acpi0
Jan 7 19:13:17 blubee kernel: battery0: <ACPI Control Method Battery> on
acpi0
Jan 7 19:13:17 blubee kernel: acpi_tz0: <Thermal Zone> on acpi0
Jan 7 19:13:17 blubee kernel: atkbdc0: <Keyboard controller (i8042)> port
0x60,0x64 irq 1 on acpi0
Jan 7 19:13:17 blubee kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Jan 7 19:13:17 blubee kernel: kbd0 at atkbd0
Jan 7 19:13:17 blubee kernel: atkbd0: [GIANT-LOCKED]
Jan 7 19:13:17 blubee kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
Jan 7 19:13:17 blubee kernel: psm0: [GIANT-LOCKED]
Jan 7 19:13:17 blubee kernel: psm0: model Generic PS/2 mouse, device ID 0
Jan 7 19:13:17 blubee kernel: est0: <Enhanced SpeedStep Frequency Control>
on cpu0
Jan 7 19:13:17 blubee kernel: est1: <Enhanced SpeedStep Frequency Control>
on cpu1
Jan 7 19:13:17 blubee kernel: est2: <Enhanced SpeedStep Frequency Control>
on cpu2
Jan 7 19:13:17 blubee kernel: est3: <Enhanced SpeedStep Frequency Control>
on cpu3
Jan 7 19:13:17 blubee kernel: est4: <Enhanced SpeedStep Frequency Control>
on cpu4
Jan 7 19:13:17 blubee kernel: est5: <Enhanced SpeedStep Frequency Control>
on cpu5
Jan 7 19:13:17 blubee kernel: est6: <Enhanced SpeedStep Frequency Control>
on cpu6
Jan 7 19:13:17 blubee kernel: est7: <Enhanced SpeedStep Frequency Control>
on cpu7
Jan 7 19:13:17 blubee kernel: ZFS filesystem version: 5
Jan 7 19:13:17 blubee kernel: ZFS storage pool version: features support
(5000)
Jan 7 19:13:17 blubee kernel: Timecounters tick every 1.000 msec
Jan 7 19:13:17 blubee kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0
Jan 7 19:13:17 blubee kernel: iwm0: hw rev 0x180, fw ver 17.352738.0,
address 60:57:18:94:c6:4a
Jan 7 19:13:17 blubee kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
Jan 7 19:13:17 blubee kernel: nvd0: <INTEL SSDPEKKW256G7> NVMe namespace
Jan 7 19:13:17 blubee kernel: nvd0: 244198MB (500118192 512 byte sectors)
Jan 7 19:13:17 blubee kernel: hdacc0: <Realtek ALC899 HDA CODEC> at cad 0
on hdac0
Jan 7 19:13:17 blubee kernel: hdaa0: <Realtek ALC899 Audio Function Group>
at nid 1 on hdacc0
Jan 7 19:13:17 blubee kernel: pcm0: <Realtek ALC899 (Analog)> at nid 20
and 24 on hdaa0
Jan 7 19:13:17 blubee kernel: pcm1: <Realtek ALC899 (Rear Analog
Line-out)> at nid 23 on hdaa0
Jan 7 19:13:17 blubee kernel: pcm2: <Realtek ALC899 (Rear Digital)> at nid
30 on hdaa0
Jan 7 19:13:17 blubee kernel: WARNING: WITNESS option enabled, expect
reduced performance.
Jan 7 19:13:17 blubee kernel: Trying to mount root from
zfs:zroot/ROOT/default []...
Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0
Jan 7 19:13:17 blubee kernel: uhub0: 24 ports with 24 removable, self
powered
Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0
Jan 7 19:13:17 blubee kernel: ugen0.2: <Razer Razer Abyssus 1800> at usbus0
Jan 7 19:13:17 blubee kernel: ukbd0 on uhub0
Jan 7 19:13:17 blubee kernel: ukbd0: <Razer Razer Abyssus 1800, class 0/0,
rev 2.00/2.00, addr 1> on usbus0
Jan 7 19:13:17 blubee kernel: kbd2 at ukbd0
Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0
Jan 7 19:13:17 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 19:13:17 blubee kernel: ugen0.4: <vendor 0x8087 product 0x0a2a> at
usbus0
Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0
Jan 7 19:13:17 blubee kernel: ugen0.5: <SunplusIT Inc Chicony USB 2.0
Camera> at usbus0
Jan 7 19:13:17 blubee kernel: nvidia-modeset: Loading NVIDIA Kernel Mode
Setting Driver for UNIX platforms 384.90 Tue Sep 19 17:29:32 PDT 2017
Jan 7 19:13:17 blubee kernel: acquiring duplicate lock of same type:
"os.lock_sx"
Jan 7 19:13:17 blubee kernel: 1st os.lock_sx @ nvidia_os.c:638
Jan 7 19:13:17 blubee kernel: 2nd os.lock_sx @ nvidia_os.c:638
Jan 7 19:13:17 blubee kernel: stack backtrace:
Jan 7 19:13:17 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 7 19:13:17 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 7 19:13:17 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68
Jan 7 19:13:17 blubee kernel: #3 0xffffffff82dc9112 at
os_acquire_mutex+0x32
Jan 7 19:13:17 blubee kernel: #4 0xffffffff82ccff06 at _nv031368rm+0x16
Jan 7 19:13:17 blubee kernel: wlan0: Ethernet address: 60:57:18:94:c6:4a
Jan 7 19:13:17 blubee kernel: wlan0: link state changed to UP
Jan 7 19:13:17 blubee kernel: re0: link state changed to DOWN
Jan 7 19:13:17 blubee kernel: ums0 on uhub0
Jan 7 19:13:17 blubee kernel: ums0: <Razer Razer Abyssus 1800, class 0/0,
rev 2.00/2.00, addr 1> on usbus0
Jan 7 19:13:17 blubee kernel: ums0: 3 buttons and [XYZ] coordinates ID=0
Jan 7 19:13:17 blubee kernel: ubt0 on uhub0
Jan 7 19:13:17 blubee kernel: ubt0: <vendor 0x8087 product 0x0a2a, class
224/1, rev 2.01/0.01, addr 3> on usbus0
Jan 7 19:13:17 blubee kernel: WARNING: attempt to domain_add(bluetooth)
after domainfinalize()
Jan 7 19:13:17 blubee kernel: WARNING: attempt to domain_add(netgraph)
after domainfinalize()
Jan 7 19:13:17 blubee kernel: ubt0: ubt_ctrl_write_callback:780: control
transfer failed: USB_ERR_TIMEOUT
Jan 7 19:13:17 blubee kernel: ng_hci_process_command_timeout: ubt0hci -
unable to complete HCI command OGF=0x3, OCF=0x3. Timeout
Jan 7 19:13:17 blubee ntpd[876]: ntpd 4.2.8p10-a (1): Starting
Jan 7 19:13:17 blubee ntpd[877]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
Jan 7 19:13:17 blubee ntpd[877]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=2018-06-28T00:00:00Z
last=2017-01-01T00:00:00Z ofs=37
Jan 7 19:13:17 blubee kernel: .
Jan 7 19:13:17 blubee kernel: g_handleattr: md99 bio_length 24 len 31 ->
EFAULT
Jan 7 19:13:18 blubee dbus[931]: [system] Activating service
name='org.freedesktop.ConsoleKit' (using servicehelper)
Jan 7 19:13:18 blubee dbus[931]: [system] Activating service
name='org.freedesktop.PolicyKit1' (using servicehelper)
Jan 7 19:13:18 blubee dbus[931]: [system] Successfully activated service
'org.freedesktop.ConsoleKit'
Jan 7 19:13:18 blubee dbus[931]: [system] Successfully activated service
'org.freedesktop.PolicyKit1'
Jan 7 19:13:31 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
Argument #4 type mismatch - Found [Buffer], ACPI requires [Package]
(20171110/nsarguments-210)
Jan 7 19:13:32 blubee kernel: acquiring duplicate lock of same type:
"os.lock_mtx"
Jan 7 19:13:32 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:873
Jan 7 19:13:32 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:873
Jan 7 19:13:32 blubee kernel: stack backtrace:
Jan 7 19:13:32 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 7 19:13:32 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 7 19:13:32 blubee kernel: #2 0xffffffff80a4b8dc at
__mtx_lock_flags+0x9c
Jan 7 19:13:32 blubee kernel: #3 0xffffffff82dc958b at
os_acquire_spinlock+0x1b
Jan 7 19:13:32 blubee kernel: #4 0xffffffff82ccc0ec at _nv030732rm+0xc
Jan 7 19:13:32 blubee kernel: nvidia-modeset: Allocated GPU:0
(GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI:0000:01:00.0
Jan 7 19:13:49 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 1
Jan 7 19:13:50 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 2
Jan 7 19:13:51 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 3
Jan 7 19:13:52 blubee adb: dnssd_clientstub ConnectToServer: connect()
failed path:/var/run/mdnsd Socket:6 Err:-1 Errno:2 No such file or directory
Jan 7 19:14:07 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 19:14:12 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 19:14:12 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 19:14:12 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 19:14:48 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 19:14:49 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 19:14:49 blubee root: Unknown USB device: vendor 0x1004 product
0x633e bus uhub0
Jan 7 19:14:49 blubee root: Unknown USB device: vendor 0x1004 product
0x633e bus uhub0
Jan 7 19:15:02 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 1
Jan 7 19:15:03 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 2
Jan 7 19:15:04 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 3
Jan 7 19:15:05 blubee adb: dnssd_clientstub ConnectToServer: connect()
failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory
Jan 7 19:15:06 blubee root: Unknown USB device: vendor 0x1004 product
0x633e bus uhub0
Jan 7 22:29:01 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 22:40:12 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 22:40:12 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 22:40:12 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 22:43:22 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 22:43:25 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 22:43:25 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 22:43:25 blubee kernel: lock order reversal:
Jan 7 22:43:25 blubee kernel: 1st 0xfffff807d194b9a0 zfs (zfs) @
/usr/src/sys/kern/vfs_vnops.c:568
Jan 7 22:43:25 blubee kernel: 2nd 0xfffffe07c2632680 bufwait (bufwait) @
/usr/src/sys/vm/vm_pager.c:374
Jan 7 22:43:25 blubee kernel: stack backtrace:
Jan 7 22:43:25 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 7 22:43:25 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 7 22:43:25 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883
Jan 7 22:43:25 blubee kernel: #3 0xffffffff80da0f19 at initpbuf+0xb9
Jan 7 22:43:25 blubee kernel: #4 0xffffffff80da0e34 at getpbuf+0x124
Jan 7 22:43:25 blubee kernel: #5 0xffffffff80d785b6 at sw
Jan 7 22:43:25 blubee kernel: ap_pager_getpages+0x46
Jan 7 22:43:25 blubee kernel: #6 0xffffffff80da0a3a at vm_pager_get_p
Jan 7 22:43:25 blubee kernel: ages+0x4a
Jan 7 22:43:25 blubee kernel: #7 0xffffffff80d84762 at vm_fault_hold+0xf12
Jan 7 22:43:25 blubee kernel: #8 0xffffffff80d86389 at
vm_fault_quick_hold_pages+0x139
Jan 7 22:43:25 blubee kernel: #9 0xffffffff80b4b41f at vn_io_fault1+0x2cf
Jan 7 22:43:25 blubee kernel:
Jan 7 22:43:25 blubee kernel: #10 0xffffffff80b4b045 at vn_rdwr+0x1b5
Jan 7 22:43:25 blubee kernel: #11 0xffffffff80b4b5e2 at
vn_rdwr_inchunks+0x92
Jan 7 22:43:25 blubee kernel: #12 0xffffffff809fd18c at elf64_cor
Jan 7 22:43:25 blubee kernel: edump+0xcec
Jan 7 22:43:25 blubee kernel: #13 0xffffffff80a70
Jan 7 22:43:25 blubee kernel: 13c at sigexit+0x81c
Jan 7 22:43:25 blubee kernel: #14 0xffffffff80a70970 at postsig+0x1c0
Jan 7 22:43:25 blubee kernel: #15 0xffffffff80ac5557 at ast+0x2e7
Jan 7 22:43:25 blubee kernel: #16 0xffffffff80ef6f69 at doreti_ast+0x1f
Jan 7 22:43:25 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 22:43:25 blubee kernel: pid 1216 (adb), uid 0: exited on signal 10
(core dumped)
Jan 7 22:43:29 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 1
Jan 7 22:43:30 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 2
Jan 7 22:43:31 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 3
Jan 7 22:43:32 blubee adb: dnssd_clientstub ConnectToServer: connect()
failed path:/var/run/mdnsd Socket:9 Err:-1 Errno:2 No such file or directory
Jan 7 22:43:50 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 1
Jan 7 22:43:51 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 2
Jan 7 22:43:52 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 3
Jan 7 22:43:53 blubee adb: dnssd_clientstub ConnectToServer: connect()
failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory
Jan 7 22:43:54 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 22:55:09 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 23:00:37 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
Jan 7 23:00:37 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 23:00:37 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 23:01:40 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 1
Jan 7 23:01:41 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 2
Jan 7 23:01:42 blubee adb: dnssd_clientstub ConnectToServer: connect()->
No of tries: 3
Jan 7 23:01:43 blubee adb: dnssd_clientstub ConnectToServer: connect()
failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory
Jan 7 23:01:44 blubee root: Unknown USB device: vendor 0x1004 product
0x61f9 bus uhub0
Jan 7 23:04:12 blubee kernel: ugen0.3: <LGE LG-H930> at usbus0
(disconnected)
Jan 7 23:04:33 blubee kernel: ugen0.3: <StoreJet Transcend StoreJet
Transcend> at usbus0
Jan 7 23:04:33 blubee kernel: umass0 on uhub0
Jan 7 23:04:33 blubee kernel: umass0: <StoreJet Transcend StoreJet
Transcend, class 0/0, rev 3.00/80.00, addr 10> on usbus0
Jan 7 23:04:33 blubee kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100
Jan 7 23:04:33 blubee kernel: umass0:3:0: Attached to scbus3
Jan 7 23:04:33 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
Jan 7 23:04:33 blubee kernel: da0: <StoreJet Transcend 0> Fixed Direct
Access SPC-4 SCSI device
Jan 7 23:04:33 blubee kernel: da0: Serial Number NZY8239W
Jan 7 23:04:33 blubee kernel: da0: 400.000MB/s transfers
Jan 7 23:04:33 blubee kernel: da0: 953869MB (1953525168 512 byte sectors)
Jan 7 23:04:33 blubee kernel: da0: quirks=0x2<NO_6_BYTE>
Jan 7 23:06:02 blubee kernel: lock order reversal:
Jan 7 23:06:02 blubee kernel: 1st 0xfffff803eba695f0 ufs (ufs) @
/usr/src/sys/kern/vfs_syscalls.c:3965
Jan 7 23:06:02 blubee kernel: 2nd 0xfffffe07c2636440 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3562
Jan 7 23:06:02 blubee kernel: stack backtrace:
Jan 7 23:06:02 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 7 23:06:02 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 7 23:06:02 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883
Jan 7 23:06:02 blubee kernel: #3 0xffffffff80b17f8e at getblk+0x4fe
Jan 7 23:06:02 blubee kernel: #4 0xffffffff80b17884 at breadn_flags+0x34
Jan 7 23:06:02 blubee kernel: #5 0xffffffff80d5fb36 at ffs_blkatoff+0x86
Jan 7 23:06:02 blubee kernel: #6 0xffffffff80d71c4e at ufs_readdir+0x17e
Jan 7 23:06:02 blubee kernel: #7 0xffffffff81093d09 at VOP_READDIR_APV+0xd9
Jan 7 23:06:02 blubee kernel: #8 0xffffffff80b483cf at
kern_getdirentries+0x24f
Jan 7 23:06:02 blubee kernel: #9 0xffffffff80b485d9 at
sys_getdirentries+0x29
Jan 7 23:06:02 blubee kernel: #10 0xffffffff80f16d2b at amd64_syscall+0x79b
Jan 7 23:06:02 blubee kernel: #11 0xffffffff80ef5b7b at Xfast_syscall+0xfb
Jan 7 23:07:26 blubee kernel: lock order reversal:
Jan 7 23:07:26 blubee kernel: 1st 0xfffff8017ae98a00 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:214
Jan 7 23:07:26 blubee kernel: 2nd 0xfffffe07c263f340 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3562
Jan 7 23:07:26 blubee kernel: stack backtrace:
Jan 7 23:07:26 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 7 23:07:26 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 7 23:07:26 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883
Jan 7 23:07:26 blubee kernel: #3 0xffffffff80b17f8e at getblk+0x4fe
Jan 7 23:07:26 blubee kernel: #4 0xffffffff80b17884 at breadn_flags+0x34
Jan 7 23:07:26 blubee kernel: #5 0xffffffff80d5fb36 at ffs_blkatoff+0x86
Jan 7 23:07:26 blubee kernel: #6 0xffffffff80d69419 at
ufsdirhash_build+0x959
Jan 7 23:07:26 blubee kernel: #7 0xffffffff80d6bcca at ufs_lookup_ino+0x1aa
Jan 7 23:07:26 blubee kernel: #8 0xffffffff81091873 at
VOP_CACHEDLOOKUP_APV+0xd3
Jan 7 23:07:26 blubee kernel: #9 0xffffffff80b24166 at
vfs_cache_lookup+0xd6
Jan 7 23:07:26 blubee kernel: #10 0xffffffff81091703 at VOP_LOOKUP_APV+0xd3
Jan 7 23:07:26 blubee kernel: #11 0xffffffff80b2d542 at lookup+0x682
Jan 7 23:07:26 blubee kernel: #12 0xffffffff80b2caca at namei+0x51a
Jan 7 23:07:26 blubee kernel: #13 0xffffffff80b44240 at kern_unlinkat+0x80
Jan 7 23:07:26 blubee kernel: #14 0xffffffff80f16d2b at amd64_syscall+0x79b
Jan 7 23:07:26 blubee kernel: #15 0xffffffff80ef5b7b at Xfast_syscall+0xfb
Jan 8 00:07:55 blubee kernel: lock order reversal:
Jan 8 00:07:55 blubee kernel: 1st 0xfffff80877d6e418 zfs (zfs) @
/usr/src/sys/kern/vfs_mount.c:1276
Jan 8 00:07:55 blubee kernel: 2nd 0xfffff8000a3609a0 syncer (syncer) @
/usr/src/sys/kern/vfs_subr.c:2770
Jan 8 00:07:55 blubee kernel: stack backtrace:
Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a41b8e at
lockmgr_lock_fast_path+0x1ae
Jan 8 00:07:55 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9
Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66
Jan 8 00:07:55 blubee kernel: #5 0xffffffff80b39dd6 at vputx+0x156
Jan 8 00:07:55 blubee kernel: #6 0xffffffff80b31888 at dounmount+0x4d8
Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b3132f at sys_unmount+0x30f
Jan 8 00:07:55 blubee kernel: #8 0xffffffff80f16d2b at amd64_syscall+0x79b
Jan 8 00:07:55 blubee kernel: #9 0xffffffff80ef5b7b at Xfast_syscall+0xfb
Jan 8 00:07:55 blubee kernel: lock order reversal:
Jan 8 00:07:55 blubee kernel: 1st 0xfffff80877d6e418 zfs (zfs) @
/usr/src/sys/kern/vfs_mount.c:1276
Jan 8 00:07:55 blubee kernel: 2nd 0xfffff8014af929a0 devfs (devfs) @
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1416
Jan 8 00:07:55 blubee kernel: stack backtrace:
Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a41b8e at
lockmgr_lock_fast_path+0x1ae
Jan 8 00:07:55 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9
Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66
Jan 8 00:07:55 blubee kernel: #5 0xffffffff80d60b43 at ffs_flushfiles+0x93
Jan 8 00:07:55 blubee kernel: #6 0xffffffff80d6311e at ffs_unmount+0x7e
Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b318c8 at dounmount+0x518
Jan 8 00:07:55 blubee kernel: #8 0xffffffff80b3132f at sys_unmount+0x30f
Jan 8 00:07:55 blubee kernel: #9 0xffffffff80f16d2b at amd64_syscall+0x79b
Jan 8 00:07:55 blubee kernel: #10 0xffffffff80ef5b7b at Xfast_syscall+0xfb
Jan 8 00:07:55 blubee kernel: lock order reversal:
Jan 8 00:07:55 blubee kernel: 1st 0xffffffff81eab970 GEOM topology (GEOM
topology) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1303
Jan 8 00:07:55 blubee kernel: 2nd 0xfffffe07c3f55680 bufwait (bufwait) @
/usr/src/sys/kern/vfs_subr.c:1758
Jan 8 00:07:55 blubee kernel: stack backtrace:
Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at
witness_debugger+0x73
Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at
witness_checkorder+0xe02
Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883
Jan 8 00:07:55 blubee kernel: #3 0xffffffff80b37783 at flushbuflist+0x103
Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b37411 at bufobj_invalbuf+0x81
Jan 8 00:07:55 blubee kernel: #5 0xffffffff809bf426 at g_vfs_close+0x46
Jan 8 00:07:55 blubee kernel: #6 0xffffffff80d632d0 at ffs_unmount+0x230
Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b318c8 at dounmount+0x518
Jan 8 00:07:55 blubee kernel: #8 0xffffffff80b3132f at sys_unmount+0x30f
Jan 8 00:07:55 blubee kernel: #9 0xffffffff80f16d2b at amd64_syscall+0x79b
Jan 8 00:07:55 blubee kernel: #10 0xffffffff80ef5b7b at Xfast_syscall+0xfb
Jan 8 00:07:59 blubee kernel: ugen0.3: <StoreJet Transcend StoreJet
Transcend> at usbus0 (disconnected)
Jan 8 00:07:59 blubee kernel: umass0: at uhub0, port 17, addr 10
(disconnected)
Jan 8 00:07:59 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
Jan 8 00:07:59 blubee kernel: da0: <StoreJet Transcend 0> s/n NZY8239W
detached
Jan 8 00:07:59 blubee kernel: (da0:umass-sim0:0:0:0): Periph destroyed
Jan 8 00:07:59 blubee kernel: umass0: detached
----------------------------------

I don't know why gstat isn't showing the info u are looking for.

You said earlier that something was getting deleted,
I don't know what could be causing that.

I've provided tons of debug out, logs, pciconf, dmesg, etc...
Even say forget the mobile device and go from
zpool

Are you saying that there's something misconfigured on my end?
What other info do you need me to provide to try to figure out
what's going on or why I'm getting these transfer rates?
Mark Millard
2018-01-08 07:20:19 UTC
Permalink
[The involvement of sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp
in order to use the Media Transfer Protocol (MTP)
against the LG v30 likely explains much of the
performance difference vs. local UFS file
systems. I provide some related notes.]

blubee blubeeme gurenchan at gmail.com wrote on
Mon Jan 8 05:17:24 UTC 2018 :

[Note: the original was in a reply to a Jon Brawn
post. I've merged it back with my post.]
Post by blubee blubeeme
Post by Mark Millard
I ran this test and here's some results.
18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
multiple small files from laptop to phone: https://imgur.com/a/B4v4y
multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
The files are missing timestamps but the originals were taken with scrot and have timestamps available here: https://nofile.io/f/mzKnkpM9CyC/stats.tar.gz2
as far as why there's such high deletions? I can't say I'm only using cp.
I assume that md99 is for a file-based swap-space, such as
via /var/swap0 file. (As a side note I warn about bugzilla
206048 for such contexts.) Otherwise please describe how
md99 is created. (Below I assume the swap-space usage of
md99.)
The only other device that your pictures show is your
NVMe device nvd0.
No picture shows a device for the LG v30 when it is mentioned
above as being copied to or from. How is it that there is no
mounted device shown for the LG v30?
No picture shows a device for the SSD when it is mentioned
above as being copied to or from. How is it that there
is no mounted device shown for the SSD?
Without a device displayed for the LG-v30/SSD there is nothing
displayed for its reads or writes. This makes the gstat -pd
useless.
May be the p needs to be omitted for some reason? gstat -d
===
Mark Millard
markmi at dsl-only.net
You are correct that md99 is a file backed swap disk, I am aware of the issues but I had to test some things out.
Those tests earlier was a huge time sink.
. . .
----------------------------------
I don't know why gstat isn't showing the info u are looking for.
You said earlier that something was getting deleted,
I don't know what could be causing that.
Those "deletes" are more commonly called TRIM on SSD's.
FreeBSD called them, BIO_DELETE as I remember.
Those deletes have nothing to do with umounting, deleteing
devices, etc.
I've provided tons of debug out, logs, pciconf, dmesg, etc...
Even say forget the mobile device and go from
zpool
From which I've not been able to figure out the kind of
information that I'm looking for.
Just because a device is present, does not mean that it
is available as a file system. I'm more interested in
how the file systems are made available --or if some
non-file system way of working is involved.
Are you saying that there's something misconfigured on my end?
What other info do you need me to provide to try to figure out
what's going on or why I'm getting these transfer rates?
I'm saying I still can not tell how you make the SSD or the
LGv 30 available to FreeBSD (mount?). Or why no matching
mounted device shows up in gstat's display.
If you wish to keep trying to help me help you, . . .
Please show how you make the file system on the
SSD available to FreeBSD: what FreeBSD commands make
the device available for use. (I'd guess that mount
is used or that something like /etc/fstab is used
to do mounts more implicitly.)
what FreeBSD commands make the device available for
use. (I'd guess that mount is used or that something like
/etc/fstab is used to do mounts more implicitly.)
(I would expect these are mount commands, or at least
involve mount commands/calls. Some of the following makes
that presumption.)
For each of those: with the device available show the
mount
df -m
Similarly, show the exact commands used to make the
copies to and from the SSD. Show the exact commands
used to make the copies to and from the LG v30.
(You can for now stop the commands early or just
not start any that would take a long time.)
I'm looking for a way to get information similar to
what I expected gstat to show. I'd expect a mounted
file system but may be something else is involved?
[Extracted from a reply to a Jon Brawn post.]
Post by blubee blubeeme
@Mark Millard
I use sysutils/simple-mtpfs to mount the android device.
/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
/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.
I do not find a /usr/ports/sysutils/simple-mtpfs . But I
do find:

# ls -lTd /usr/ports/sysutils/*simple*
drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 /usr/ports/sysutils/fusefs-simple-mtpfs

And that was very important to know.

I had to look it up but this means that you are using
the Media Transfer Protocol (MTP) to transfer files from
the LG v30. It also means that part of that involves use
of the Filesystem in USErspace (FUSE). The two would be
likely to add overheads that slow things down (extra
stages/steps in getting the bytes copied).

[Apparently MTP is an extension to the Picture Transfer
Protocol (PTP) communications protocol. MTP has been
standardized as a full-fledged USB device class but
originated with Microsoft.]

[MTP use involves putting the Android device into MTP mode,
frequently referenced in the Android UI via a selection
of "USB for file transfer" someplace in the user
interface (according to what I read).]

One example of why FreeBSD and sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp might be
slower than some linux software is:

It appears that some Linux software has implemented "USB
'Zerocopy' support found in recent Linux kernel" (and,
so, avoid user-space vs. kernel space data copying and
some context switching).

I doubt that FreeBSD and its sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp combination
happen to do that. This difference likely would make a
notable speed difference for the transfer and save to local
file system (if my doubt is correct).

It is not surprising that the speeds would be far less
than the experiments that I reported.


I do not have a context to experiment with the
consequences of using sysutils/fusefs-simple-mtpfs
and what it requires (fusefs-libs and libmtp). I'm
afraid I'll not be able to be much help relative to
the LG v30 MTP-based transfer performance
investigations.


That leaves the SSD context. Is there anything that
you still want to investigate relative to the SSD
usage? Or is there no point because of the LG v30
status?

===
Mark Millard
markmi at dsl-only.net
blubee blubeeme
2018-01-08 09:15:42 UTC
Permalink
Post by Mark Millard
[The involvement of sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp
in order to use the Media Transfer Protocol (MTP)
against the LG v30 likely explains much of the
performance difference vs. local UFS file
systems. I provide some related notes.]
blubee blubeeme gurenchan at gmail.com wrote on
[Note: the original was in a reply to a Jon Brawn
post. I've merged it back with my post.]
Post by blubee blubeeme
On 2018-Jan-7, at 10:23 AM, blubee blubeeme <gurenchan at gmail.com>
On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard <markmi at dsl-only.net>
On 2018-Jan-7, at 7:50 AM, blubee blubeeme <gurenchan at gmail.com>
I ran this test and here's some results.
18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
multiple small files from laptop to phone: https://imgur.com/a/B4v4y
multiple small files from laptop to ssd: https://imgur.com/a/mDiMu
The files are missing timestamps but the originals were taken with
scrot and have timestamps available here: https://nofile.io/f/
mzKnkpM9CyC/stats.tar.gz2
Post by blubee blubeeme
as far as why there's such high deletions? I can't say I'm only
using cp.
Post by blubee blubeeme
I assume that md99 is for a file-based swap-space, such as
via /var/swap0 file. (As a side note I warn about bugzilla
206048 for such contexts.) Otherwise please describe how
md99 is created. (Below I assume the swap-space usage of
md99.)
The only other device that your pictures show is your
NVMe device nvd0.
No picture shows a device for the LG v30 when it is mentioned
above as being copied to or from. How is it that there is no
mounted device shown for the LG v30?
No picture shows a device for the SSD when it is mentioned
above as being copied to or from. How is it that there
is no mounted device shown for the SSD?
Without a device displayed for the LG-v30/SSD there is nothing
displayed for its reads or writes. This makes the gstat -pd
useless.
May be the p needs to be omitted for some reason? gstat -d
===
Mark Millard
markmi at dsl-only.net
You are correct that md99 is a file backed swap disk, I am aware of
the issues but I had to test some things out.
Post by blubee blubeeme
Those tests earlier was a huge time sink.
. . .
----------------------------------
I don't know why gstat isn't showing the info u are looking for.
You said earlier that something was getting deleted,
I don't know what could be causing that.
Those "deletes" are more commonly called TRIM on SSD's.
FreeBSD called them, BIO_DELETE as I remember.
Those deletes have nothing to do with umounting, deleteing
devices, etc.
I've provided tons of debug out, logs, pciconf, dmesg, etc...
Even say forget the mobile device and go from
zpool
From which I've not been able to figure out the kind of
information that I'm looking for.
Just because a device is present, does not mean that it
is available as a file system. I'm more interested in
how the file systems are made available --or if some
non-file system way of working is involved.
Are you saying that there's something misconfigured on my end?
What other info do you need me to provide to try to figure out
what's going on or why I'm getting these transfer rates?
I'm saying I still can not tell how you make the SSD or the
LGv 30 available to FreeBSD (mount?). Or why no matching
mounted device shows up in gstat's display.
If you wish to keep trying to help me help you, . . .
Please show how you make the file system on the
SSD available to FreeBSD: what FreeBSD commands make
the device available for use. (I'd guess that mount
is used or that something like /etc/fstab is used
to do mounts more implicitly.)
what FreeBSD commands make the device available for
use. (I'd guess that mount is used or that something like
/etc/fstab is used to do mounts more implicitly.)
(I would expect these are mount commands, or at least
involve mount commands/calls. Some of the following makes
that presumption.)
For each of those: with the device available show the
mount
df -m
Similarly, show the exact commands used to make the
copies to and from the SSD. Show the exact commands
used to make the copies to and from the LG v30.
(You can for now stop the commands early or just
not start any that would take a long time.)
I'm looking for a way to get information similar to
what I expected gstat to show. I'd expect a mounted
file system but may be something else is involved?
[Extracted from a reply to a Jon Brawn post.]
Post by blubee blubeeme
@Mark Millard
I use sysutils/simple-mtpfs to mount the android device.
/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
/dev/da0 923913 121450 728550 14%
/mnt
Can you tell me what information you're looking for so that I can gather
it
Post by blubee blubeeme
all up and send it.
I do not find a /usr/ports/sysutils/simple-mtpfs . But I
# ls -lTd /usr/ports/sysutils/*simple*
drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017
/usr/ports/sysutils/fusefs-simple-mtpfs
And that was very important to know.
I had to look it up but this means that you are using
the Media Transfer Protocol (MTP) to transfer files from
the LG v30. It also means that part of that involves use
of the Filesystem in USErspace (FUSE). The two would be
likely to add overheads that slow things down (extra
stages/steps in getting the bytes copied).
[Apparently MTP is an extension to the Picture Transfer
Protocol (PTP) communications protocol. MTP has been
standardized as a full-fledged USB device class but
originated with Microsoft.]
[MTP use involves putting the Android device into MTP mode,
frequently referenced in the Android UI via a selection
of "USB for file transfer" someplace in the user
interface (according to what I read).]
One example of why FreeBSD and sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp might be
It appears that some Linux software has implemented "USB
'Zerocopy' support found in recent Linux kernel" (and,
so, avoid user-space vs. kernel space data copying and
some context switching).
I doubt that FreeBSD and its sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp combination
happen to do that. This difference likely would make a
notable speed difference for the transfer and save to local
file system (if my doubt is correct).
It is not surprising that the speeds would be far less
than the experiments that I reported.
I do not have a context to experiment with the
consequences of using sysutils/fusefs-simple-mtpfs
and what it requires (fusefs-libs and libmtp). I'm
afraid I'll not be able to be much help relative to
the LG v30 MTP-based transfer performance
investigations.
That leaves the SSD context. Is there anything that
you still want to investigate relative to the SSD
usage? Or is there no point because of the LG v30
status?
===
Mark Millard
markmi at dsl-only.net
OK, forget the android specific usb issues for now;
there is quite a few layers of crud between the laptop and the android
device.

I have this SSD.

What are some tests that you'd like to run to test the speeds
on my end?
blubee blubeeme
2018-01-12 17:41:11 UTC
Permalink
On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard <markmi at dsl-only.net>
Post by Mark Millard
[The involvement of sysutils/fusefs-simple-mtpfs
and sysutils/fusefs-libs and multimedia/libmtp
in order to use the Media Transfer Protocol (MTP)
against the LG v30 likely explains much of the
performance difference vs. local UFS file
systems. I provide some related notes.]
blubee blubeeme gurenchan at gmail.com wrote on
[Note: the original was in a reply to a Jon Brawn
post. I've merged it back with my post.]
On 2018-Jan-7, at 11:46 AM, Mark Millard <markmi at dsl-only.net>
On 2018-Jan-7, at 10:23 AM, blubee blubeeme <gurenchan at gmail.com>
On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard <markmi at
On 2018-Jan-7, at 7:50 AM, blubee blubeeme <gurenchan at gmail.com>
I ran this test and here's some results.
18GB file from laptop to phone: https://imgur.com/a/7iHwv
18GB file from laptop to ssd: https://imgur.com/a/40Q6V
https://imgur.com/a/B4v4y
https://imgur.com/a/mDiMu
Post by Mark Millard
The files are missing timestamps but the originals were taken
with scrot and have timestamps available here: https://nofile.io/f/
mzKnkpM9CyC/stats.tar.gz2
Post by Mark Millard
as far as why there's such high deletions? I can't say I'm only
using cp.
Post by Mark Millard
I assume that md99 is for a file-based swap-space, such as
via /var/swap0 file. (As a side note I warn about bugzilla
206048 for such contexts.) Otherwise please describe how
md99 is created. (Below I assume the swap-space usage of
md99.)
The only other device that your pictures show is your
NVMe device nvd0.
No picture shows a device for the LG v30 when it is mentioned
above as being copied to or from. How is it that there is no
mounted device shown for the LG v30?
No picture shows a device for the SSD when it is mentioned
above as being copied to or from. How is it that there
is no mounted device shown for the SSD?
Without a device displayed for the LG-v30/SSD there is nothing
displayed for its reads or writes. This makes the gstat -pd
useless.
May be the p needs to be omitted for some reason? gstat -d
===
Mark Millard
markmi at dsl-only.net
You are correct that md99 is a file backed swap disk, I am aware of
the issues but I had to test some things out.
Post by Mark Millard
Those tests earlier was a huge time sink.
. . .
----------------------------------
I don't know why gstat isn't showing the info u are looking for.
You said earlier that something was getting deleted,
I don't know what could be causing that.
Those "deletes" are more commonly called TRIM on SSD's.
FreeBSD called them, BIO_DELETE as I remember.
Those deletes have nothing to do with umounting, deleteing
devices, etc.
I've provided tons of debug out, logs, pciconf, dmesg, etc...
Even say forget the mobile device and go from
zpool
From which I've not been able to figure out the kind of
information that I'm looking for.
Just because a device is present, does not mean that it
is available as a file system. I'm more interested in
how the file systems are made available --or if some
non-file system way of working is involved.
Are you saying that there's something misconfigured on my end?
What other info do you need me to provide to try to figure out
what's going on or why I'm getting these transfer rates?
I'm saying I still can not tell how you make the SSD or the
LGv 30 available to FreeBSD (mount?). Or why no matching
mounted device shows up in gstat's display.
If you wish to keep trying to help me help you, . . .
Please show how you make the file system on the
SSD available to FreeBSD: what FreeBSD commands make
the device available for use. (I'd guess that mount
is used or that something like /etc/fstab is used
to do mounts more implicitly.)
what FreeBSD commands make the device available for
use. (I'd guess that mount is used or that something like
/etc/fstab is used to do mounts more implicitly.)
(I would expect these are mount commands, or at least
involve mount commands/calls. Some of the following makes
that presumption.)
For each of those: with the device available show the
mount
df -m
Similarly, show the exact commands used to make the
copies to and from the SSD. Show the exact commands
used to make the copies to and from the LG v30.
(You can for now stop the commands early or just
not start any that would take a long time.)
I'm looking for a way to get information similar to
what I expected gstat to show. I'd expect a mounted
file system but may be something else is involved?
[Extracted from a reply to a Jon Brawn post.]
@Mark Millard
I use sysutils/simple-mtpfs to mount the android device.
/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
/dev/da0 923913 121450 728550
14%
Post by Mark Millard
/mnt
Can you tell me what information you're looking for so that I can
gather it
Post by Mark Millard
all up and send it.
I do not find a /usr/ports/sysutils/simple-mtpfs . But I
# ls -lTd /usr/ports/sysutils/*simple*
drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017
/usr/ports/sysutils/fusefs-simple-mtpfs
Post by Mark Millard
And that was very important to know.
. . .
OK, forget the android specific usb issues for now;
there is quite a few layers of crud between the laptop and the android
device.
I have this SSD.
What are some tests that you'd like to run to test the speeds
on my end?
Returning to just the SSD context. . .
Because your pictures were missing the SSD for some
reason, we first need to figure out if and how to
see the SSD activity levels, such as via gstat.
For now I focus on just that.
/dev/da0 923913 121450 728550 14%
/mnt
which is from "df -m". But I'd also asked for "mount"
# mount
/dev/gpt/FBSDFSSDroot on / (ufs, NFS exported, local, noatime,
soft-updates)
devfs on /dev (devfs, local, multilabel)
Note the types of information displayed, which is very different from
what df -m reports.
( /dev/gpt/FBSDFSSDroot is a label reference instead of a physical
device and partition/slice number notation.)
After mounting the partition/slice from the SSD, can you show the
mount command's description of the partition/slice that you mounted?
(Actually, your "df -m" output does not show a partition/slice
notation. I'm not sure what to make of that.)
There is another view of things that can be handy. . .
(output is from one of my example contexts)
# gpart show -p da0
=> 40 937703008 da0 GPT (447G)
40 1024 da0p1 freebsd-boot (512K)
1064 746586112 da0p2 freebsd-ufs (356G)
746587176 31457280 da0p3 freebsd-swap (15G)
778044456 159383552 da0p4 freebsd-swap (76G)
937428008 275040 - free - (134M)
Note: Normally da0 would not show up in a mount
line, instead it would be /dev/da0p2 for the UFS
partition being mounted in my example.
Your da0 might not show GPT or any other partition
or slice structure (given the "df -m" output that
you listed).
(If zfs is involved, there may be better commands
for some types of information above, but I've minimal
ZFS background knowledge. You may have to explain
your configuration if ZFS is in use on the SSD.)
With that much information (if non-ZFS), I know what
I expect to be listed in gstat -pd and in gstat -d .
gstat -d
and the same device and its partitions will show up
multiple times for different ways they can be
dT: 1.073s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps
ms/d %busy Name
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| fd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| cd0
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0p1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0p2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0p3
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da0p4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| label/FBSDx64Cboot
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSSDboot
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSSDroot
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSSDswap
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSSDswap2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da1p1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2p1
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2p2
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2p3
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| da2p4
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSSDbkp
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| ufsid/<REPLACED>
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSboot
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSroot
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| ufsid/<REPLACED>
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFBswap
0 0 0 0 0.0 0 0 0.0 0 0
0.0 0.0| gpt/FBSDFSswap
The sorter list from gstat -pd can be nicer to look at
when its content happens to be sufficient for ones
purpose at the time. Otherwise the fuller list can be
used, giving specific rates and such for individual
partitions.
The initial question for gstat seems to be: can we find the mounted
SSD partition/slice and/or the overall SSD device in the gstat output.
Can you check on that? If you find the partition and/or overall device,
can you show those lines so that I know what they look like?
(gstat might not be an appropriate tool if the SSD is a ZFS-only
device.)
===
Mark Millard
markmi at dsl-only.net
I didn't restart gstat between the tests... so It didn't update to show
the devices after they were added.
dT: 1.064s w: 1.000s filter: d
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
0 0 0 0 0.0 0 0 0.0 0.0| nvd0
0 0 0 0 0.0 0 0 0.0 0.0| nvd0p1
0 0 0 0 0.0 0 0 0.0 0.0| nvd0p2
0 0 0 0 0.0 0 0 0.0 0.0| nvd0p3
0 0 0 0 0.0 0 0 0.0 0.0| nvd0p4
0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI
0 0 0 0 0.0 0 0 0.0 0.0| da0
0 0 0 0 0.0 0 0 0.0 0.0| ufsid/xxxx
0 0 0 0 0.0 0 0 0.0 0.0|
msdosfs/TRANSCEND

This is the current output for a simple USB device but this brings up a
whole new slew of errors;
not related to speed but of encodings.

Mark Millard
2018-01-07 11:42:31 UTC
Permalink
[The other numbers show lots of delete activity on nvd0,
not just primarily reads. Also: Can you test a different
USB device, such as a USB SSD stick?]
Post by Mark Millard
[The following notes a problem with how a test was done.
I omit the rest of the material.]
. . .
This is a larger file, not the largest but hey
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 4 0 0 0.0 2 8 0.0 0 0 0.0 0.1| nvd0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99
128 982 1 32 58.8 981 125428 110.5 0 0 0.0 100.0| da1
. . .
Note that almost complete lack of kBps near r/s but the large
kBps near w/s.
It appears that the file has been cached in RAM and is not
being read from media at all. So this test is of a RAM to
disk transfer, not disk to disk, as far as I can tell.
You need to avoid re-reading the same file unless you
dismount and remount between tests or some such. Or
just use a different file not copied since booting (that
file may or may not be a previous copy of the same file
by content).
See if you can get gstat -pd results that show both
read kBps and write kBps figures.
Can you test another USB device, such as a USB SSD
stick, sometime known to be reliably fast and not
involving reading from the LG v30?

From what I read Android has many file systems supported
or used at one time: ext4, f2fs, yaffs, yaffs2,
vfat, msdos being in the list. Normal SD and SDHC files
systems are FAT32 and SDXC is exFAT.

So "Android 7.1" does not answer my question about which
file system is actually on the usdcard being used. I'd
guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but
I do not really know.


My results show that getting above 8 MiBytes/s over
USB 2.0 is supported for other than the rather low end
of the FreeBSD range of systems. Beyond that is something
more specific to your context and not involved in mine.
The file system might be involved.

So far, from the tables and what you have written, the
LG v30 is required to be involved for the slowdown
to sub 8 MiBytes/s. This is part of why I ask about
testing an alternative USB device that is fast: it
tests USB without involving the LG v30 or the usdcard.

If USB ends up faster, then it is not USB's "stack" that
is the primary source of the current bottleneck for your
context: something else is also involved, such as the
file system may be.

Can you show gstat -pd output for copying from the
LG v30? Copying to the 1TB USB backup device? The
%busy figures might be interesting.


In your other table:

This is an example copying [multiple small files] to the 1TB drive.
------------------------------------------------------------------------------------------------------------------
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
0 547 290 35239 2.0 4 16 73.1 249 44291 93.7 48.8| nvd0
0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99
21 333 0 0 0.0 333 36040 16.2 0 0 0.0 76.2| da1
------------------------------------------------------------------------------------------------------------------

This shows lots of deletes per second for some reason.

Did you move instead of copy? After each file was copied,
was it then deleted?

It is possible that the deletes slowed this down,
whatever they were from.



===
Mark Millard
markmi at dsl-only.net
Chris H
2018-01-08 05:40:24 UTC
Permalink
Post by blubee blubeeme
Post by blubee blubeeme
Post by blubee blubeeme
I ask does FreeBSD usb stack actually implements USB spec 2.0 or
greater
Post by blubee blubeeme
and the topic gets derailed...?
Yes, it does.
Post by blubee blubeeme
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
Post by blubee blubeeme
Post by O'Connor, Daniel
Post by O'Connor, Daniel
What is an "LG v30"?
It's a smartphone from LG and only supports USB2 speed. The
reported
Post by blubee blubeeme
Post by O'Connor, Daniel
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org
Post by blubee blubeeme
"
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: 1st 0xfffffe07c26336c0 bufwait
/usr/src/sys/vm/vm_pager.c:374
/usr/src/sys/dev/md/md.c:952
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: 1st 0xfffffe07c41d5dc0 bufwait
/usr/src/sys/kern/vfs_bio.c:3562
Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
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
@Mark Millard
I use sysutils/simple-mtpfs to mount the android device.
/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
/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.
It's not CURRENT that's the problem, but GENERIC (WITNESS et al; that causes
contention) -- see; performance loss. :-)
Post by blubee blubeeme
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.
--Chris
Loading...