Date: Sun, 7 Jan 2018 14:32:50 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: freebsd-current@freebsd.org Subject: Re: USB stack Message-ID: <20180107143250.65bcb7cb8d557e4b7f59504f@dec.sakura.ne.jp> In-Reply-To: <CALM2mEkBu7R8T4GLWQzWS9qLDW8Se9UYYbQdaiB_S2qrQR9mLA@mail.gmail.com> References: <CALM2mEmZFP9dGOivJknrCaaa-K1cSxNTTEV%2B8XCMpoZp-xcbqQ@mail.gmail.com> <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <CALM2mE=7cKcPzJ=-bVvmHez2inrAqJsuMaW%2BUZZtXesB3pzDtQ@mail.gmail.com> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <CALM2mE=uFK0BVqxFcrU_K%2BN%2BwYnu9VTewACeNqPTGYFEv93g4g@mail.gmail.com> <CANCZdfqna3dy-29g_fB3-aw71Hps2ph_%2BNMBUW9z7nhMBVztjg@mail.gmail.com> <CALM2mEmgn4FmBLtW4SaGEEqoF6AsFR_y1PUMTZ80_2GpDx1SdQ@mail.gmail.com> <CANCZdfojq3TAcb-oVY7SA2NfayKkyGodZn8s=-UxGKD4thbFEg@mail.gmail.com> <CALM2mEkBu7R8T4GLWQzWS9qLDW8Se9UYYbQdaiB_S2qrQR9mLA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Jan 2018 12:25:17 +0800 blubee blubeeme <gurenchan@gmail.com> wrote: > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh <imp@bsdimp.com> wrote: > > > > > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme <gurenchan@gmail.com> > > wrote: > > > >> > >> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh <imp@bsdimp.com> wrote: > >> > >>> > >>> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme <gurenchan@gmail.com> > >>> wrote: > >>> > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater > >>>> and the topic gets derailed...? > >>>> > >>> > >>> Yes, it does. > >>> > >>> > >>>> Are you guys saying that 7-8MB/s is USB speeds? > >>>> > >>> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've > >>> not tried USB3 with an SSD that can do more.... > >>> > >>> Warner > >>> > >>> > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel <darius@dons.net.au> > >>>> wrote: > >>>> > >>>> > > >>>> > > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn <gljennjohn@gmail.com> > >>>> wrote: > >>>> > >> What is an "LG v30"? > >>>> > >> > >>>> > > It's a smartphone from LG and only supports USB2 speed. The > >>>> reported > >>>> > > transfer rate is no big surprise. > >>>> > > >>>> > OK thanks. > >>>> > > >>>> > -- > >>>> > Daniel O'Connor > >>>> > "The nice thing about standards is that there > >>>> > are so many of them to choose from." > >>>> > -- Andrew Tanenbaum > >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@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: <StoreJet Transcend StoreJet > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > >> 0x0100 > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > >> lun 0 > >> Jan 7 11:56:56 blubee kernel: da0: <StoreJet Transcend 0> Fixed Direct > >> Access SPC-4 SCSI device > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2<NO_6_BYTE> > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait (bufwait) > >> @ /usr/src/sys/vm/vm_pager.c:374 > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > >> /usr/src/sys/dev/md/md.c:952 > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > >> lockmgr_lock_fast_path+0x1ae > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > >> mdstart_vnode+0x442 > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > >> fork_trampoline+0xe > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait (bufwait) > >> @ /usr/src/sys/kern/vfs_bio.c:3562 > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash (dirhash) > >> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > >> ufsdirhash_add+0x3d > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at ufs_direnter+0x459 > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > >> ufs_makeinode+0x613 > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > >> VOP_CREATE_APV+0xd3 > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at vn_open_cred+0x2ad > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at kern_openat+0x212 > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > >> amd64_syscall+0x79b > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > >> Xfast_syscall+0xfb > >> > >> > >> Is the slow transfers user error? > >> > > > > It's likely due to the slow UFS issue... > > > > Warner > > > The Transcend ssd is formated ZFS, I use it as a backup. > > The microsd might suffer from what you say since it's formatted by Android > but I do not get these slow transfer speeds on other OS. > > so a quick roundup. > 1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds; > let's say that's because of the Android OS default format. > I only get these slow speeds on FreeBSD, why is that? Warner is asking "how are you copying" on another thread. How? Although it's over LAN, I experience slooooow copying using shells/fd to copy (1-2MB/s), while 10-60MB/s by /bin/cp. Not measured, but feeling alike for USB memstick (same file to same memstick, with at least one reboot between each copy). It shoud be said to other filers, which doesn't call /bin/cp internally or does just what /bin/cp does. As for USB memsticks, I had a problematic one, which caused plenty of errors, maybe by mismatched quirks. It worked but very slow, sometimes suddenly disappeares, although it claimed 90MB/s capable. :-( > > 2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above; > are the slow speeds user error or something else? > > @Warner Losh > what was your setup where you were able to transfer 23-75MB/s to your USB > device? > _______________________________________________ > 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" > -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180107143250.65bcb7cb8d557e4b7f59504f>