Re: USB stack

[blubee blubeeme]

On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard  wrote:

>
> On 2018-Jan-8, at 1:15 AM, blubee blubeeme  wrote:
>
> > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard 
> wrote:
> >> [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.]
> >>
> >> > On 2018-Jan-7, at 11:46 AM, Mark Millard 
> wrote:
> >> >
> >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  dsl-only.net> wrote:
> >> >>>
> >>  On 2018-Jan-7, at 7:50 AM, blubee blubeeme 
> wrote:
> >> 
> >> > I ran this test and here's some results.
> >> > gstat -pd images:
> >> >
> >> > 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:
> >> >>> . . .
> >> >>> --
> >> >>>
> >> >>> 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.)
> >> >>
> >> >> Please show how you make the LG v30 available to FreeBSD:
> >> >> what FreeBSD commands make the device available for
> >> >> use. (I'd guess that mount is used or that 

Re: USB stack

[Mark Millard]

On 2018-Jan-8, at 1:15 AM, blubee blubeeme  wrote:

> On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard  wrote:
>> [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.]
>> 
>> > On 2018-Jan-7, at 11:46 AM, Mark Millard  wrote:
>> >
>> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme  
>> >> wrote:
>> >>
>> >>
>> >>
>> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  
>> >>> wrote:
>> >>>
>>  On 2018-Jan-7, at 7:50 AM, blubee blubeeme  
>>  wrote:
>> 
>> > I ran this test and here's some results.
>> > gstat -pd images:
>> >
>> > 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:
>> >>> . . .
>> >>> --
>> >>>
>> >>> 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.)
>> >>
>> >> Please show how you make the LG v30 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.)
>> >>
>> >> (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 

Re: USB stack

[Gary Jennejohn]

On Mon, 8 Jan 2018 13:17:22 +0800
blubee blubeeme  wrote:

> On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn  wrote:
> 
> >
> >  
> > > On Jan 7, 2018, at 5:44 PM, Jon Brawn  wrote:
> > >
> > >  
> > >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme   
> > wrote:  
> > >>
> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> > >>  
> > >>>
> > >>>
> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> > >>> wrote:
> > >>>  
> >  I ask does FreeBSD usb stack actually implements USB spec 2.0 or  
> > greater  
> >  and the topic gets derailed...?
> >   
> > >>>
> > >>> Yes, it does.
> > >>>
> > >>>  
> >  Are you guys saying that 7-8MB/s is USB speeds?
> >   
> > >>>
> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with  
> > USB  
> > >>> 1.x. More recently, I've maxed out the writes on a USB stick at about
> > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0...  
> > I've  
> > >>> not tried USB3 with an SSD that can do more
> > >>>
> > >>> Warner
> > >>>
> > >>>  
> >  On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
> >  wrote:
> >   
> > >
> > >  
> > >> On 4 Jan 2018, at 09:23, Gary Jennejohn   
> > wrote:  
> > >>> What is an "LG v30"?
> > >>>  
> > >> It's a smartphone from LG and only supports USB2 speed.  The  
> > reported  
> > >> transfer rate is no big surprise.  
> > >
> > > OK thanks.
> > >
> > > --
> > > Daniel O'Connor
> > > "The nice thing about standards is that there
> > > are so many of them to choose from."
> > > -- Andrew Tanenbaum
> > > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> > >
> > >  
> >  ___
> >  freebsd-current@freebsd.org mailing list
> >  https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >  To unsubscribe, send any mail to "freebsd-current-unsubscribe@  
> > freebsd.org  
> >  "
> >   
> > >>>
> > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone  
> > >> ---
> > >> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
> > >> Jan  7 11:56:56 blubee kernel: umass0:  > >> 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:  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
> > >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait  
> > (bufwait) @  
> > >> /usr/src/sys/vm/vm_pager.c:374
> > >> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> > >> lockmgr_lock_fast_path+0x1ae
> > >> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at  
> > VOP_LOCK1_APV+0xd9  
> > >> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> > >> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at  
> > mdstart_vnode+0x442  
> > >> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> > >> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> > >> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at  
> > fork_trampoline+0xe  
> > >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait  
> > (bufwait) @  
> > >> /usr/src/sys/kern/vfs_bio.c:3562
> > >> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> > >> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at  
> > ufsdirhash_add+0x3d  
> > >> Jan 

Re: USB stack

[blubee blubeeme]

On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard  wrote:

> [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.]
>
> > On 2018-Jan-7, at 11:46 AM, Mark Millard  wrote:
> >
> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme 
> wrote:
> >>
> >>
> >>
> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard 
> wrote:
> >>>
>  On 2018-Jan-7, at 7:50 AM, blubee blubeeme 
> wrote:
> 
> > I ran this test and here's some results.
> > gstat -pd images:
> >
> > 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:
> >>> . . .
> >>> --
> >>>
> >>> 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.)
> >>
> >> Please show how you make the LG v30 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.)
> >>
> >> (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
> >> output of:
> >>
> >> mount
> >>
> >> and of:
> >>
> >> df -m
> >>
> >> Similarly, show the exact commands used to make the
> >> copies to and from the SSD. Show the exact commands
> >> 

Re: USB stack

[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
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.]

> On 2018-Jan-7, at 11:46 AM, Mark Millard  wrote:
> 
>> On 2018-Jan-7, at 10:23 AM, blubee blubeeme  wrote:
>> 
>> 
>> 
>>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  wrote:
>>> 
 On 2018-Jan-7, at 7:50 AM, blubee blubeeme  wrote:
 
> I ran this test and here's some results.
> gstat -pd images:
> 
> 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:
>>> . . .
>>> --
>>> 
>>> 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.)
>> 
>> Please show how you make the LG v30 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.)
>> 
>> (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
>> output of:
>> 
>> mount
>> 
>> and of:
>> 
>> 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 

Re: USB stack

[Chris H]

On Mon, 8 Jan 2018 13:17:22 +0800 "blubee blubeeme"  said


On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn  wrote:

>
>
> > On Jan 7, 2018, at 5:44 PM, Jon Brawn  wrote:
> >
> >
> >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme 
> wrote:
> >>
> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> >>
> >>>
> >>>
> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> >>> wrote:
> >>>
>  I ask does FreeBSD usb stack actually implements USB spec 2.0 or
> greater
>  and the topic gets derailed...?
> 
> >>>
> >>> Yes, it does.
> >>>
> >>>
>  Are you guys saying that 7-8MB/s is USB speeds?
> 
> >>>
> >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
> USB
> >>> 1.x. More recently, I've maxed out the writes on a USB stick at about
> >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0...
> I've
> >>> not tried USB3 with an SSD that can do more
> >>>
> >>> Warner
> >>>
> >>>
>  On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>  wrote:
> 
> >
> >
> >> On 4 Jan 2018, at 09:23, Gary Jennejohn 
> wrote:
> >>> What is an "LG v30"?
> >>>
> >> It's a smartphone from LG and only supports USB2 speed.  The
> reported
> >> transfer rate is no big surprise.
> >
> > OK thanks.
> >
> > --
> > Daniel O'Connor
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> > -- Andrew Tanenbaum
> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> >
> >
>  ___
>  freebsd-current@freebsd.org mailing list
>  https://lists.freebsd.org/mailman/listinfo/freebsd-current
>  To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org
>  "
> 
> >>>
> >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
> >> ---
> >> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
> >> Jan  7 11:56:56 blubee kernel: umass0:  >> 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:  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
> >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> >> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait
> (bufwait) @
> >> /usr/src/sys/vm/vm_pager.c:374
> >> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> >> lockmgr_lock_fast_path+0x1ae
> >> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at
> VOP_LOCK1_APV+0xd9
> >> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> >> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
> mdstart_vnode+0x442
> >> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> >> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> >> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
> fork_trampoline+0xe
> >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> >> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait
> (bufwait) @
> >> /usr/src/sys/kern/vfs_bio.c:3562
> >> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> >> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at
> ufsdirhash_add+0x3d
> >> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at
> ufs_direnter+0x459
> >> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at
> ufs_makeinode+0x613
> >> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
> >> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at
> VOP_CREATE_APV+0xd3
> >> Jan  7 12:06:15 blubee 

Re: USB stack

[blubee blubeeme]

On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn  wrote:

>
>
> > On Jan 7, 2018, at 5:44 PM, Jon Brawn  wrote:
> >
> >
> >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme 
> wrote:
> >>
> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> >>
> >>>
> >>>
> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> >>> wrote:
> >>>
>  I ask does FreeBSD usb stack actually implements USB spec 2.0 or
> greater
>  and the topic gets derailed...?
> 
> >>>
> >>> Yes, it does.
> >>>
> >>>
>  Are you guys saying that 7-8MB/s is USB speeds?
> 
> >>>
> >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
> USB
> >>> 1.x. More recently, I've maxed out the writes on a USB stick at about
> >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0...
> I've
> >>> not tried USB3 with an SSD that can do more
> >>>
> >>> Warner
> >>>
> >>>
>  On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>  wrote:
> 
> >
> >
> >> On 4 Jan 2018, at 09:23, Gary Jennejohn 
> wrote:
> >>> What is an "LG v30"?
> >>>
> >> It's a smartphone from LG and only supports USB2 speed.  The
> reported
> >> transfer rate is no big surprise.
> >
> > OK thanks.
> >
> > --
> > Daniel O'Connor
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> > -- Andrew Tanenbaum
> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> >
> >
>  ___
>  freebsd-current@freebsd.org mailing list
>  https://lists.freebsd.org/mailman/listinfo/freebsd-current
>  To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org
>  "
> 
> >>>
> >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
> >> ---
> >> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
> >> Jan  7 11:56:56 blubee kernel: umass0:  >> 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:  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
> >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> >> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait
> (bufwait) @
> >> /usr/src/sys/vm/vm_pager.c:374
> >> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> >> lockmgr_lock_fast_path+0x1ae
> >> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at
> VOP_LOCK1_APV+0xd9
> >> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> >> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
> mdstart_vnode+0x442
> >> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> >> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> >> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
> fork_trampoline+0xe
> >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> >> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait
> (bufwait) @
> >> /usr/src/sys/kern/vfs_bio.c:3562
> >> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> >> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at
> ufsdirhash_add+0x3d
> >> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at
> ufs_direnter+0x459
> >> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at
> ufs_makeinode+0x613
> >> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
> >> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at
> VOP_CREATE_APV+0xd3
> >> Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at
> vn_open_cred+0x2ad
> >> Jan  7 12:06:15 blubee 

Re: USB stack

[Jon Brawn]

> On Jan 7, 2018, at 5:44 PM, Jon Brawn  wrote:
> 
> 
>> On Jan 6, 2018, at 10:18 PM, blubee blubeeme  wrote:
>> 
>> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
>> 
>>> 
>>> 
>>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
>>> wrote:
>>> 
 I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
 and the topic gets derailed...?
 
>>> 
>>> Yes, it does.
>>> 
>>> 
 Are you guys saying that 7-8MB/s is USB speeds?
 
>>> 
>>> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
>>> 1.x. More recently, I've maxed out the writes on a USB stick at about
>>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
>>> not tried USB3 with an SSD that can do more
>>> 
>>> Warner
>>> 
>>> 
 On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
 wrote:
 
> 
> 
>> On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>>> What is an "LG v30"?
>>> 
>> It's a smartphone from LG and only supports USB2 speed.  The reported
>> transfer rate is no big surprise.
> 
> OK thanks.
> 
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
> -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> 
> 
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
 "
 
>>> 
>>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
>> ---
>> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
>> Jan  7 11:56:56 blubee kernel: umass0: > 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:  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
>> Jan  7 12:06:08 blubee kernel: lock order reversal:
>> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait) @
>> /usr/src/sys/vm/vm_pager.c:374
>> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
>> witness_debugger+0x73
>> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
>> witness_checkorder+0xe02
>> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
>> lockmgr_lock_fast_path+0x1ae
>> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
>> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
>> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442
>> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
>> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
>> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe
>> Jan  7 12:06:15 blubee kernel: lock order reversal:
>> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait) @
>> /usr/src/sys/kern/vfs_bio.c:3562
>> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
>> witness_debugger+0x73
>> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
>> witness_checkorder+0xe02
>> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
>> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d
>> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
>> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613
>> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
>> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3
>> Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
>> Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
>> Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at amd64_syscall+0x79b
>> Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b at Xfast_syscall+0xfb
>> 
>> 
>> Is the slow transfers user error?
> 
> Wotcha!
> 
> I don’t see any read or 

Re: USB stack

[Jon Brawn]

> On Jan 6, 2018, at 10:18 PM, blubee blubeeme  wrote:
> 
> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> 
>> 
>> 
>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
>> wrote:
>> 
>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>>> and the topic gets derailed...?
>>> 
>> 
>> Yes, it does.
>> 
>> 
>>> Are you guys saying that 7-8MB/s is USB speeds?
>>> 
>> 
>> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
>> 1.x. More recently, I've maxed out the writes on a USB stick at about
>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
>> not tried USB3 with an SSD that can do more
>> 
>> Warner
>> 
>> 
>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>>> wrote:
>>> 
 
 
> On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> What is an "LG v30"?
>> 
> It's a smartphone from LG and only supports USB2 speed.  The reported
> transfer rate is no big surprise.
 
 OK thanks.
 
 --
 Daniel O'Connor
 "The nice thing about standards is that there
 are so many of them to choose from."
 -- Andrew Tanenbaum
 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
 
 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>>> "
>>> 
>> 
>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
> ---
> Jan  7 11:56:56 blubee kernel: umass0 on uhub0
> Jan  7 11:56:56 blubee kernel: umass0:  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:  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
> Jan  7 12:06:08 blubee kernel: lock order reversal:
> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait) @
> /usr/src/sys/vm/vm_pager.c:374
> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> witness_debugger+0x73
> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> witness_checkorder+0xe02
> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> lockmgr_lock_fast_path+0x1ae
> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442
> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe
> Jan  7 12:06:15 blubee kernel: lock order reversal:
> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait) @
> /usr/src/sys/kern/vfs_bio.c:3562
> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> witness_debugger+0x73
> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> witness_checkorder+0xe02
> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d
> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613
> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3
> Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
> Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
> Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at amd64_syscall+0x79b
> Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b 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 

Re: USB stack

[Mark Millard]

On 2018-Jan-7, at 10:23 AM, blubee blubeeme  wrote:



> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  wrote:
> 
>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme  wrote:
>> 
>> > I ran this test and here's some results.
>> > gstat -pd images:
>> >
>> > 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:
> . . .
> --
> 
> 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.)

Please show how you make the LG v30 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.)

(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
output of:

mount

and of:

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?


===
Mark Millard
markmi at dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard  wrote:

>
> On 2018-Jan-7, at 7:50 AM, blubee blubeeme  wrote:
>
> > I ran this test and here's some results.
> > gstat -pd images:
> >
> > 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:
r...@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
Jan  7 19:13:17 blubee kernel:
 
Features2=0x7ffafbbf
Jan  7 19:13:17 blubee kernel:   AMD
Features=0x2c100800
Jan  7 19:13:17 blubee kernel:   AMD Features2=0x121
Jan  7 19:13:17 blubee kernel:   Structured Extended
Features=0x29c6fbf
Jan  7 19:13:17 blubee kernel:   XSAVE
Features=0xf
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: 
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  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: 

Re: USB stack

[Mark Millard]

On 2018-Jan-7, at 7:50 AM, blubee blubeeme  wrote:

> I ran this test and here's some results.
> gstat -pd images:
> 
> 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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard  wrote:

> [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.]
>
> On 2018-Jan-7, at 3:42 AM, Mark Millard  wrote:
>
> > [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?]
> >
> > On 2018-Jan-7, at 2:44 AM, Mark Millard  wrote:
> >
> >> [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 
> wrote:
> >>
> >> . . .
> >>> This is a larger file, not the largest but hey
> >>>
> >>> L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> >>>   0  4  0  00.0  2  80.0  0  0
> 0.00.1| nvd0
> >>>   0  0  0  00.0  0  00.0  0  0
> 0.00.0| md99
> >>> 128982  1 32   58.8981 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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> >0547290  352392.0  4 16   73.1249  44291
>  93.7   48.8| nvd0
> >0  0  0  00.0  0  00.0  0  0
> 0.00.0| md99
> >   21333  0  00.0333  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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| fd0
> 0   2346   2346  202340.1  0  00.0  0  0
> 0.0   11.9| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
> 0  0  0  00.0  0  00.0  0 

Re: USB stack

[Mark Millard]

[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?]

On 2018-Jan-7, at 2:44 AM, Mark Millard  wrote:

> [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  wrote:
> 
> . . .
>> This is a larger file, not the largest but hey
>> 
>> L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
>> %busy Name
>>0  4  0  00.0  2  80.0  0  00.0   
>>  0.1| nvd0
>>0  0  0  00.0  0  00.0  0  00.0   
>>  0.0| md99
>>  128982  1 32   58.8981 125428  110.5  0  00.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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
0547290  352392.0  4 16   73.1249  44291   93.7   
48.8| nvd0
0  0  0  00.0  0  00.0  0  00.0
0.0| md99
   21333  0  00.0333  36040   16.2  0  00.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



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[Mark Millard]

[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.]

On 2018-Jan-7, at 3:42 AM, Mark Millard  wrote:

> [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?]
> 
> On 2018-Jan-7, at 2:44 AM, Mark Millard  wrote:
> 
>> [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  wrote:
>> 
>> . . .
>>> This is a larger file, not the largest but hey
>>> 
>>> L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d  
>>>  %busy Name
>>>   0  4  0  00.0  2  80.0  0  00.0   
>>>  0.1| nvd0
>>>   0  0  0  00.0  0  00.0  0  00.0   
>>>  0.0| md99
>>> 128982  1 32   58.8981 125428  110.5  0  00.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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
> %busy Name
>0547290  352392.0  4 16   73.1249  44291   93.7   
> 48.8| nvd0
>0  0  0  00.0  0  00.0  0  00.0
> 0.0| md99
>   21333  0  00.0333  36040   16.2  0  00.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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
0  0  0  00.0  0  00.0  0  00.0
0.0| fd0
0   2346   2346  202340.1  0  00.0  0  00.0   
11.9| da0
0  0  0  00.0  0  00.0  0  00.0
0.0| da1
0  0  0  00.0  0  00.0  0  00.0
0.0| da2
0  0  0  00.0  0  00.0  0  00.0
0.0| da3
0  0  0  00.0  0  00.0  0  00.0
0.0| cd0
 1162   1375 21658   60.1   1354  26962  331.4  0  00.0   
81.1| da4

dT: 1.069s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
   

Re: USB stack

[Mark Millard]

[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  wrote:

. . .
> This is a larger file, not the largest but hey
> 
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
> %busy Name
> 0  4  0  00.0  2  80.0  0  00.0   
>  0.1| nvd0
> 0  0  0  00.0  0  00.0  0  00.0   
>  0.0| md99
>   128982  1 32   58.8981 125428  110.5  0  00.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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 5:35 PM, Mark Millard  wrote:

> blubee blubeeme gurenchan at gmail.com wrote on
> Wed Jan 3 10:31:56 UTC 2018 :
>
> > 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?
>
> > 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.

>
> > 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
> of transfer compared to the above?):
>
I transfer from the phone to the computer.

>
> > 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.
>
> 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.
>
>
> Example performance copying /usr/src/ :
> (lots of small files on a fairly low-end FreeBSD
> machine)
>
> RPi2B V1.1 (with USB 2.0)
> One USB 3.0 powered hub (USB 2.0 compatible) with both:
>
> 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
>
> gstat -pd outputs, a few examples:
>
> dT: 1.007s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> 0255255   55011.9  0  00.0  0  0
> 0.0   48.0| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
>64426  1 32  221.4425   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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
 ms/d   %busy Name
0547290  352392.0  4 16   73.1249  44291
 93.7   48.8| nvd0
0  0  0  00.0  0  00.0  0  0
0.00.0| md99
   21333  0  00.0333  36040   16.2  0  0
0.0   76.2| da1
--


>
> dT: 1.007s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
> 0393393   52951.3  0  00.0  0  0
> 0.0   50.7| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
>46102  2 642.9100   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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps
>  ms/d   %busy Name
>16245245   9761   37.4  0  00.0  0  0
> 0.0   77.4| da0
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da1
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da2
> 0  0  0  00.0  0  00.0  0  0
> 0.00.0| da3
>28481  0  00.0

Re: USB stack

[Mark Millard]

blubee blubeeme gurenchan at gmail.com wrote on
Wed Jan 3 10:31:56 UTC 2018 :

> 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?

> I transferred about 30GB of audio from laptop

The 30GB was on what type of device? Plugged in to what?
What file system?

> to Samsung usb class 10 usb
> device connected to LG v30.

What file system?

And in another message (indicating the other direction
of transfer compared to the above?):

> 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.

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.  


Example performance copying /usr/src/ :
(lots of small files on a fairly low-end FreeBSD
machine)

RPi2B V1.1 (with USB 2.0)
One USB 3.0 powered hub (USB 2.0 compatible) with both:

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

gstat -pd outputs, a few examples:

dT: 1.007s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
0255255   55011.9  0  00.0  0  00.0   
48.0| da0
0  0  0  00.0  0  00.0  0  00.0
0.0| da1
0  0  0  00.0  0  00.0  0  00.0
0.0| da2
0  0  0  00.0  0  00.0  0  00.0
0.0| da3
   64426  1 32  221.4425   6287  140.4  0  00.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.)

dT: 1.007s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
0393393   52951.3  0  00.0  0  00.0   
50.7| da0
0  0  0  00.0  0  00.0  0  00.0
0.0| da1
0  0  0  00.0  0  00.0  0  00.0
0.0| da2
0  0  0  00.0  0  00.0  0  00.0
0.0| da3
   46102  2 642.9100   2101  116.9  0  00.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/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
   16245245   9761   37.4  0  00.0  0  00.0   
77.4| da0
0  0  0  00.0  0  00.0  0  00.0
0.0| da1
0  0  0  00.0  0  00.0  0  00.0
0.0| da2
0  0  0  00.0  0  00.0  0  00.0
0.0| da3
   28481  0  00.0481  10809   95.1  0  00.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
file system based:

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

gstat -pd outputs, a couple of examples:

dT: 1.023s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/wd/s   kBps   ms/d   
%busy Name
0  0  0  00.0  0  00.0  0  00.0
0.0| fd0
0   6519   6519 1033390.1  0  00.0  0  00.0   
35.5| da0
0  0  0  00.0  0  0

Re: Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 4:27 PM, Freddie Cash <fjwc...@gmail.com> wrote:

> Forgot to include the list. Resending.
>
> -- Forwarded message --
> From: "Freddie Cash" <fjwc...@gmail.com>
> Date: Jan 7, 2018 12:26 AM
> Subject: Re: USB stack
> To: "blubee blubeeme" <gurenc...@gmail.com>
> Cc:
>
> On Jan 6, 2018 8:30 PM, "blubee blubeeme" <gurenc...@gmail.com> wrote:
>
> > 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:  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:  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
>
>
> 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
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
Here's the latest unmodified GENERIC kernel boot log.

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

pastebin: https://pastebin.com/66NZEFtp

Anything else that I can provide?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: Re: USB stack

[Freddie Cash]

Forgot to include the list. Resending.

-- Forwarded message --
From: "Freddie Cash" <fjwc...@gmail.com>
Date: Jan 7, 2018 12:26 AM
Subject: Re: USB stack
To: "blubee blubeeme" <gurenc...@gmail.com>
Cc:

On Jan 6, 2018 8:30 PM, "blubee blubeeme" <gurenc...@gmail.com> wrote:

> 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:  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:  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


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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 1:32 PM, Tomoaki AOKI 
wrote:

> On Sun, 7 Jan 2018 12:25:17 +0800
> blubee blubeeme  wrote:
>
> > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh  wrote:
> >
> > >
> > >
> > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme 
> > > wrote:
> > >
> > >>
> > >>
> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> > >>
> > >>>
> > >>>
> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme  >
> > >>> wrote:
> > >>>
> >  I ask does FreeBSD usb stack actually implements USB spec 2.0 or
> greater
> >  and the topic gets derailed...?
> > 
> > >>>
> > >>> Yes, it does.
> > >>>
> > >>>
> >  Are you guys saying that 7-8MB/s is USB speeds?
> > 
> > >>>
> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
> > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at
> about
> > >>> 75MB/s (the fastest it will do), which isn't possible with USB
> 2.0... I've
> > >>> not tried USB3 with an SSD that can do more
> > >>>
> > >>> Warner
> > >>>
> > >>>
> >  On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel <
> dar...@dons.net.au>
> >  wrote:
> > 
> >  >
> >  >
> >  > > On 4 Jan 2018, at 09:23, Gary Jennejohn 
> >  wrote:
> >  > >> What is an "LG v30"?
> >  > >>
> >  > > It's a smartphone from LG and only supports USB2 speed.  The
> >  reported
> >  > > transfer rate is no big surprise.
> >  >
> >  > OK thanks.
> >  >
> >  > --
> >  > Daniel O'Connor
> >  > "The nice thing about standards is that there
> >  > are so many of them to choose from."
> >  >  -- Andrew Tanenbaum
> >  > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F
> CE8C
> >  >
> >  >
> >  ___
> >  freebsd-current@freebsd.org mailing list
> >  https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >  To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
> >  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:  > >> 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:  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
> > >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait
> (bufwait)
> > >> @ /usr/src/sys/vm/vm_pager.c:374
> > >> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> > >> lockmgr_lock_fast_path+0x1ae
> > >> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at
> VOP_LOCK1_APV+0xd9
> > >> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> > >> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
> > >> mdstart_vnode+0x442
> > >> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at
> md_kthread+0x1fe
> > >> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> > >> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
> > >> fork_trampoline+0xe
> > >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> > >> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait
> (bufwait)
> > >> @ /usr/src/sys/kern/vfs_bio.c:3562
> > >> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> > >> witness_debugger+0x73
> > >> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> > >> witness_checkorder+0xe02
> > >> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> > >> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at
> > >> ufsdirhash_add+0x3d
> > >> Jan  7 12:06:15 blubee 

Re: USB stack

[Tomoaki AOKI]

On Sun, 7 Jan 2018 12:25:17 +0800
blubee blubeeme  wrote:

> On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh  wrote:
> 
> >
> >
> > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme 
> > wrote:
> >
> >>
> >>
> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
> >>
> >>>
> >>>
> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> >>> wrote:
> >>>
>  I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>  and the topic gets derailed...?
> 
> >>>
> >>> Yes, it does.
> >>>
> >>>
>  Are you guys saying that 7-8MB/s is USB speeds?
> 
> >>>
> >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
> >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about
> >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
> >>> not tried USB3 with an SSD that can do more
> >>>
> >>> Warner
> >>>
> >>>
>  On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>  wrote:
> 
>  >
>  >
>  > > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>  wrote:
>  > >> What is an "LG v30"?
>  > >>
>  > > It's a smartphone from LG and only supports USB2 speed.  The
>  reported
>  > > transfer rate is no big surprise.
>  >
>  > OK thanks.
>  >
>  > --
>  > Daniel O'Connor
>  > "The nice thing about standards is that there
>  > are so many of them to choose from."
>  >  -- Andrew Tanenbaum
>  > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>  >
>  >
>  ___
>  freebsd-current@freebsd.org mailing list
>  https://lists.freebsd.org/mailman/listinfo/freebsd-current
>  To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>  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:  >> 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:  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
> >> Jan  7 12:06:08 blubee kernel: lock order reversal:
> >> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait)
> >> @ /usr/src/sys/vm/vm_pager.c:374
> >> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> >> lockmgr_lock_fast_path+0x1ae
> >> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
> >> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> >> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
> >> mdstart_vnode+0x442
> >> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> >> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> >> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
> >> fork_trampoline+0xe
> >> Jan  7 12:06:15 blubee kernel: lock order reversal:
> >> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait)
> >> @ /usr/src/sys/kern/vfs_bio.c:3562
> >> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> >> witness_debugger+0x73
> >> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> >> witness_checkorder+0xe02
> >> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> >> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at
> >> ufsdirhash_add+0x3d
> >> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
> >> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at
> >> ufs_makeinode+0x613
> >> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
> >> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at
> >> VOP_CREATE_APV+0xd3
> >> Jan  7 12:06:15 blubee kernel: #8 

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:25 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme 
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh  wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme 
>>> wrote:
>>>
 On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
 wrote:

 > 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?
 >
 > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
 > wrote:
 >
 >>
 >>
 >> > On 4 Jan 2018, at 09:23, Gary Jennejohn 
 wrote:
 >> >> What is an "LG v30"?
 >> >>
 >> > It's a smartphone from LG and only supports USB2 speed.  The
 reported
 >> > transfer rate is no big surprise.
 >>
 >> OK thanks.
 >>
 >> --
 >> Daniel O'Connor
 >> "The nice thing about standards is that there
 >> are so many of them to choose from."
 >>  -- Andrew Tanenbaum
 >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
 >>
 >>
 > 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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
> wrote:
>
>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>> and the topic gets derailed...?
>>
>
> Yes, it does.
>
>
>> Are you guys saying that 7-8MB/s is USB speeds?
>>
>
> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
> 1.x. More recently, I've maxed out the writes on a USB stick at about
> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
> not tried USB3 with an SSD that can do more
>
> Warner
>
>
>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>> wrote:
>>
>> >
>> >
>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> > >> What is an "LG v30"?
>> > >>
>> > > It's a smartphone from LG and only supports USB2 speed.  The reported
>> > > transfer rate is no big surprise.
>> >
>> > OK thanks.
>> >
>> > --
>> > Daniel O'Connor
>> > "The nice thing about standards is that there
>> > are so many of them to choose from."
>> >  -- Andrew Tanenbaum
>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>> >
>> >
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
> I just connected a Transcend StorageJet 1TB hdd not a mobile phone
---
Jan  7 11:56:56 blubee kernel: umass0 on uhub0
Jan  7 11:56:56 blubee kernel: umass0:  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:  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
Jan  7 12:06:08 blubee kernel: lock order reversal:
Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait) @
/usr/src/sys/vm/vm_pager.c:374
Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
witness_debugger+0x73
Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
witness_checkorder+0xe02
Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
lockmgr_lock_fast_path+0x1ae
Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442
Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe
Jan  7 12:06:15 blubee kernel: lock order reversal:
Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3562
Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
witness_debugger+0x73
Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
witness_checkorder+0xe02
Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d
Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613
Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3
Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at amd64_syscall+0x79b
Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b at Xfast_syscall+0xfb


Is the slow transfers user error?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[Warner Losh]

On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme  wrote:

> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
> and the topic gets derailed...?
>

Yes, it does.


> Are you guys saying that 7-8MB/s is USB speeds?
>

I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
1.x. More recently, I've maxed out the writes on a USB stick at about
75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
not tried USB3 with an SSD that can do more

Warner


> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
> wrote:
>
> >
> >
> > > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
> > >> What is an "LG v30"?
> > >>
> > > It's a smartphone from LG and only supports USB2 speed.  The reported
> > > transfer rate is no big surprise.
> >
> > OK thanks.
> >
> > --
> > Daniel O'Connor
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> >  -- Andrew Tanenbaum
> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> >
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme 
> wrote:
>
>>
>>
>> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
>>
>>>
>>>
>>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
>>> wrote:
>>>
 I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
 and the topic gets derailed...?

>>>
>>> Yes, it does.
>>>
>>>
 Are you guys saying that 7-8MB/s is USB speeds?

>>>
>>> I've gotten up to 24MB/s for maybe a decade. That's not possible with
>>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about
>>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
>>> not tried USB3 with an SSD that can do more
>>>
>>> Warner
>>>
>>>
 On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
 wrote:

 >
 >
 > > On 4 Jan 2018, at 09:23, Gary Jennejohn 
 wrote:
 > >> What is an "LG v30"?
 > >>
 > > It's a smartphone from LG and only supports USB2 speed.  The
 reported
 > > transfer rate is no big surprise.
 >
 > OK thanks.
 >
 > --
 > Daniel O'Connor
 > "The nice thing about standards is that there
 > are so many of them to choose from."
 >  -- Andrew Tanenbaum
 > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
 >
 >
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
 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: > 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:  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
>> Jan  7 12:06:08 blubee kernel: lock order reversal:
>> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait)
>> @ /usr/src/sys/vm/vm_pager.c:374
>> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
>> witness_debugger+0x73
>> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
>> witness_checkorder+0xe02
>> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
>> lockmgr_lock_fast_path+0x1ae
>> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
>> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
>> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at
>> mdstart_vnode+0x442
>> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
>> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
>> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at
>> fork_trampoline+0xe
>> Jan  7 12:06:15 blubee kernel: lock order reversal:
>> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait)
>> @ /usr/src/sys/kern/vfs_bio.c:3562
>> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
>> witness_debugger+0x73
>> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
>> witness_checkorder+0xe02
>> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
>> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at
>> ufsdirhash_add+0x3d
>> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
>> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at
>> ufs_makeinode+0x613
>> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
>> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at
>> VOP_CREATE_APV+0xd3
>> Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
>> Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
>> Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at
>> amd64_syscall+0x79b
>> Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b at
>> Xfast_syscall+0xfb
>>
>>
>> Is the slow transfers user error?

Re: USB stack

[Warner Losh]

On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme  wrote:

>
>
> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh  wrote:
>
>>
>>
>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme 
>> wrote:
>>
>>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
>>> wrote:
>>>
>>> > 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?
>>> >
>>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>>> > wrote:
>>> >
>>> >>
>>> >>
>>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>>> wrote:
>>> >> >> What is an "LG v30"?
>>> >> >>
>>> >> > It's a smartphone from LG and only supports USB2 speed.  The
>>> reported
>>> >> > transfer rate is no big surprise.
>>> >>
>>> >> OK thanks.
>>> >>
>>> >> --
>>> >> Daniel O'Connor
>>> >> "The nice thing about standards is that there
>>> >> are so many of them to choose from."
>>> >>  -- Andrew Tanenbaum
>>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>> >>
>>> >>
>>> > 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh  wrote:

>
>
> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme 
> wrote:
>
>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
>> wrote:
>>
>> > 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?
>> >
>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>> > wrote:
>> >
>> >>
>> >>
>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>> wrote:
>> >> >> What is an "LG v30"?
>> >> >>
>> >> > It's a smartphone from LG and only supports USB2 speed.  The reported
>> >> > transfer rate is no big surprise.
>> >>
>> >> OK thanks.
>> >>
>> >> --
>> >> Daniel O'Connor
>> >> "The nice thing about standards is that there
>> >> are so many of them to choose from."
>> >>  -- Andrew Tanenbaum
>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>> >>
>> >>
>> > 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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[Warner Losh]

On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme  wrote:

>
>
> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh  wrote:
>
>>
>>
>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme 
>> wrote:
>>
>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater
>>> and the topic gets derailed...?
>>>
>>
>> Yes, it does.
>>
>>
>>> Are you guys saying that 7-8MB/s is USB speeds?
>>>
>>
>> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB
>> 1.x. More recently, I've maxed out the writes on a USB stick at about
>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've
>> not tried USB3 with an SSD that can do more
>>
>> Warner
>>
>>
>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
>>> wrote:
>>>
>>> >
>>> >
>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn 
>>> wrote:
>>> > >> What is an "LG v30"?
>>> > >>
>>> > > It's a smartphone from LG and only supports USB2 speed.  The reported
>>> > > transfer rate is no big surprise.
>>> >
>>> > OK thanks.
>>> >
>>> > --
>>> > Daniel O'Connor
>>> > "The nice thing about standards is that there
>>> > are so many of them to choose from."
>>> >  -- Andrew Tanenbaum
>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>> >
>>> >
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> 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:  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:  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
> Jan  7 12:06:08 blubee kernel: lock order reversal:
> Jan  7 12:06:08 blubee kernel:  1st 0xfe07c26336c0 bufwait (bufwait) @
> /usr/src/sys/vm/vm_pager.c:374
> Jan  7 12:06:08 blubee kernel:  2nd 0xf80148c425f0 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 0x80acfa03 at
> witness_debugger+0x73
> Jan  7 12:06:08 blubee kernel: #1 0x80acf882 at
> witness_checkorder+0xe02
> Jan  7 12:06:08 blubee kernel: #2 0x80a41b8e at
> lockmgr_lock_fast_path+0x1ae
> Jan  7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9
> Jan  7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66
> Jan  7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442
> Jan  7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe
> Jan  7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84
> Jan  7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe
> Jan  7 12:06:15 blubee kernel: lock order reversal:
> Jan  7 12:06:15 blubee kernel:  1st 0xfe07c41d5dc0 bufwait (bufwait) @
> /usr/src/sys/kern/vfs_bio.c:3562
> Jan  7 12:06:15 blubee kernel:  2nd 0xf8002bb31a00 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 0x80acfa03 at
> witness_debugger+0x73
> Jan  7 12:06:15 blubee kernel: #1 0x80acf882 at
> witness_checkorder+0xe02
> Jan  7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68
> Jan  7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d
> Jan  7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459
> Jan  7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613
> Jan  7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34
> Jan  7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3
> Jan  7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad
> Jan  7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212
> Jan  7 12:06:15 blubee kernel: #10 0x80f16d2b at
> amd64_syscall+0x79b
> Jan  7 12:06:15 blubee kernel: #11 0x80ef5b7b at Xfast_syscall+0xfb
>
>
> Is the slow transfers user error?
>

It's likely due to the slow UFS issue...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, 

Re: USB stack

[Warner Losh]

On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme  wrote:

> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
> wrote:
>
> > 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?
> >
> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
> > wrote:
> >
> >>
> >>
> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
> >> >> What is an "LG v30"?
> >> >>
> >> > It's a smartphone from LG and only supports USB2 speed.  The reported
> >> > transfer rate is no big surprise.
> >>
> >> OK thanks.
> >>
> >> --
> >> Daniel O'Connor
> >> "The nice thing about standards is that there
> >> are so many of them to choose from."
> >>  -- Andrew Tanenbaum
> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
> >>
> >>
> > 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme 
wrote:

> 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?
>
> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel 
> wrote:
>
>>
>>
>> > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> >> What is an "LG v30"?
>> >>
>> > It's a smartphone from LG and only supports USB2 speed.  The reported
>> > transfer rate is no big surprise.
>>
>> OK thanks.
>>
>> --
>> Daniel O'Connor
>> "The nice thing about standards is that there
>> are so many of them to choose from."
>>  -- Andrew Tanenbaum
>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>>
>>
> 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?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[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?

On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel  wrote:

>
>
> > On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
> >> What is an "LG v30"?
> >>
> > It's a smartphone from LG and only supports USB2 speed.  The reported
> > transfer rate is no big surprise.
>
> OK thanks.
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>  -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[O'Connor, Daniel]

> On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> What is an "LG v30"?
>> 
> It's a smartphone from LG and only supports USB2 speed.  The reported
> transfer rate is no big surprise.

OK thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[Gary Jennejohn]

On Wed, 3 Jan 2018 20:29:08 +0100
"O'Connor, Daniel"  wrote:

> > On 3 Jan 2018, at 11:56, blubee blubeeme  wrote:
> > On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel  wrote:
> > 
> >   
> > > On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> > > Does FreeBSD current USB stack support usb >= 2.0 devices?  
> > 
> > Absolutely.
> >   
> > > 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.
> > 
> > current usbconfig shows this:
> > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER 
> > (5.0Gbps) pwr=SAVE (0mA)
> > ugen0.3:  at usbus0, cfg=0 md=HOST 
> > spd=HIGH (480Mbps) pwr=ON (500mA)
> > ugen0.2:  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"?
> 

It's a smartphone from LG and only supports USB2 speed.  The reported
transfer rate is no big surprise.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:56, blubee blubeeme  wrote:
> On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel  wrote:
> 
> 
> > On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> > Does FreeBSD current USB stack support usb >= 2.0 devices?
> 
> Absolutely.
> 
> > 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.
> 
> current usbconfig shows this:
> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) 
> pwr=SAVE (0mA)
> ugen0.3:  at usbus0, cfg=0 md=HOST 
> spd=HIGH (480Mbps) pwr=ON (500mA)
> ugen0.2:  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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> Does FreeBSD current USB stack support usb >= 2.0 devices?

Absolutely.

> 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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB stack

[blubee blubeeme]

On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel  wrote:

>
>
> > On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> > Does FreeBSD current USB stack support usb >= 2.0 devices?
>
> Absolutely.
>
> > 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
>
> I transferred about 30GB of audio from laptop to Samsung usb class 10 usb
device connected to LG v30.

current usbconfig shows this:
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE (0mA)
ugen0.3:  at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (500mA)
ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"