Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127
There doesn't appear to be a knob to disable building lint for FreeBSD 11.x. Linking or copying /usr/bin/true to /usr/bin/lint works for cross building 11 on on a 12.0-CURRENT machine, but I was not able to get it to work when rebuilding a poudriere jail. On 8 Jan, Warner Losh wrote: > Does building -DWITHOUT_LINT work? Or linking lint to /bin/true > > Warner > > On Jan 7, 2018 11:58 PM, "O. Hartmann"wrote: > >> We have a bunch of CURRENT boxes running poudriere jails providing >> packages for >> 11.1-RELENG. Since a couple of week sfor now, I face this error when I try >> to >> update the p3 and p4 to the recent p6: >> >> [...] >> cc -O2 -pipe >> -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../lint1 >> -DPREFIX=\"\" >> -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../arch/amd64 >> -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../common >> -DNDEBUG >> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k >> -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow >> -Wunused-parameter >> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations >> -Wthread-safety -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable >> -Qunused-arguments -o xlint xlint.o mem.o --- lint.1.gz --- gzip >> -cn /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/lint.1 > >> lint.1.gz ===> usr.bin/xlint/llib (all) --- llib-lposix.ln --- lint >> -cghapbx >> -Cposix /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/llib/ >> llib-lposix >> sh: lint: not found *** [llib-lposix.ln] Error code 127 >> [...] >> >> >> Please advice how this can be resolved. >> >> >> Kind regards, >> >> Oliver >> ___ >> 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" ___ 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: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127
Put the following in /usr/local/etc/poudriere.d/src.conf: LINT=/usr/bin/false That skips the attempt to build the lint library because of this: .if ${LINT} == "lint" _llib= llib .else _llib= .endif SUBDIR= lint1 lint2 xlint ${_llib} in /usr/src/usr.bin/xlint/Makefile On 8 Jan, O. Hartmann wrote: > We have a bunch of CURRENT boxes running poudriere jails providing packages > for > 11.1-RELENG. Since a couple of week sfor now, I face this error when I try to > update the p3 and p4 to the recent p6: > > [...] > cc -O2 -pipe > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../lint1 > -DPREFIX=\"\" > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../arch/amd64 > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../common -DNDEBUG > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable > -Qunused-arguments -o xlint xlint.o mem.o --- lint.1.gz --- gzip > -cn /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/lint.1 > > lint.1.gz ===> usr.bin/xlint/llib (all) --- llib-lposix.ln --- lint -cghapbx > -Cposix /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/llib/llib-lposix > sh: lint: not found *** [llib-lposix.ln] Error code 127 > [...] > > > Please advice how this can be resolved. > > > Kind regards, > > Oliver > ___ > 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
[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: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127
Does building -DWITHOUT_LINT work? Or linking lint to /bin/true Warner On Jan 7, 2018 11:58 PM, "O. Hartmann"wrote: > We have a bunch of CURRENT boxes running poudriere jails providing > packages for > 11.1-RELENG. Since a couple of week sfor now, I face this error when I try > to > update the p3 and p4 to the recent p6: > > [...] > cc -O2 -pipe > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../lint1 > -DPREFIX=\"\" > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../arch/amd64 > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../common > -DNDEBUG > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k > -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable > -Qunused-arguments -o xlint xlint.o mem.o --- lint.1.gz --- gzip > -cn /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/lint.1 > > lint.1.gz ===> usr.bin/xlint/llib (all) --- llib-lposix.ln --- lint > -cghapbx > -Cposix /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/llib/ > llib-lposix > sh: lint: not found *** [llib-lposix.ln] Error code 127 > [...] > > > Please advice how this can be resolved. > > > Kind regards, > > Oliver > ___ > 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"
11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127
We have a bunch of CURRENT boxes running poudriere jails providing packages for 11.1-RELENG. Since a couple of week sfor now, I face this error when I try to update the p3 and p4 to the recent p6: [...] cc -O2 -pipe -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../lint1 -DPREFIX=\"\" -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../arch/amd64 -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../common -DNDEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o xlint xlint.o mem.o --- lint.1.gz --- gzip -cn /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/lint.1 > lint.1.gz ===> usr.bin/xlint/llib (all) --- llib-lposix.ln --- lint -cghapbx -Cposix /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/llib/llib-lposix sh: lint: not found *** [llib-lposix.ln] Error code 127 [...] Please advice how this can be resolved. Kind regards, Oliver ___ 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
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: Make periodic's output log to files if sendmail is disabled on install
On Sun, 7 Jan 2018 23:05:44 -0500said 1) if sendmail is disabled during installation, have periodic's output logged to files (per example in https://www.freebsd.org/cgi/man.cgi?periodic(8) ) 2) make this the default anyway (logging to files), arguably the vast majority of systems' reporting is ignored :) At least now it could be logrotated out! Hmm, if they are "arguably" already ignoring their system emails. Won't they then *also* "arguably" ignore their [system] log files? Why not just remove periodic etc/periodic(daily/weekly/monthly/security)? But maybe I've just misunderstood the attempt here. [22:54.53] AllanJude: will you make the installer smart that if the user disables sendmail, that periodic's output will be sent to logfiles instead? [22:55.17] not sure how doable that is [22:57.20] AllanJude: https://www.freebsd.org/cgi/man.cgi?periodic(8) <-- see examples [22:57.55] ohh [22:57.57] ok then [22:58.04] should be fairly easy to do then [23:00.02] AllanJude: I'd argue logging periodic to files should become the default since I'm willing to bet 99% of fBSD machines' output is ignored. [23:00.34] Myke: that is a reasonable idea for freebsd 12 [23:00.42] :) [23:00.55] want to email that to freebsd-current@freebsd.org [23:00.57] and then i'll do it ;) --Chris ___ 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
On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawnwrote: > > > > 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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
On Sun, 7 Jan 2018 12:31:34 +0100 "O. Hartmann"said Am Thu, 4 Jan 2018 12:14:47 +0100 "O. Hartmann" schrieb: > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen wrote: > > > > On 31. Dec 2017, at 02:45, Warner Losh wrote: > > > > > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann > wrote: > > > > > >> On most recent CURRENT I face the error shwon below on /tmp filesystem > > >> (UFS2) residing > > >> on a Samsung 850 Pro SSD: > > >> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != > > >> bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> > > >> I've already formatted the /tmp filesystem, but obviously without any > > >> success. > > >> > > >> Since I face such strange errors also on NanoBSD images dd'ed to SD > cards, > > >> I guess there > > >> is something fishy ... > > > > > > > > > It indicates a problem. We've seen these 'corruptions' on data in motion > at > > > work, but I hacked fsck to report checksum mismatches (it silently > corrects > > > them today) and we've not seen any mismatch when we unmount and fsck the > > > filesystem. > > Not sure this helps: But we have seen this also after system panics > > when having soft update journaling enabled. Having soft update journaling > > disabled, we do not observed this after several panics. > > Just to be clear: The panics are not related to this issue, > > but to other network development we do. > > > > You can check using tunefs -p devname if soft update journaling is enabled > or > > not. > > In all cases I reported in earlier and now, softupdates ARE ENABLED on all > partitions in question (always GPT, in my cases also all on flash based > devices, SD card and/or SSD). ... and journalling as well! In case of the SD, I produced the layout of the NanoBSD image via "dd" including the /cfg partition. The problem occured even when having overwritten the SD card with a new image. The problem went away once I unmounted /cfg and reformatted via newfs. After that, I did not see any faults again! I have no explanation for this behaviour except the dd didn't overwrite "faulty" areas or the obligate "gpart recover" at the end of the procedure restored something faulty. The /tmp filesystem I reported in was also from an earlier date - and I didn't formatted it as I said - I confused the partition in question with another one. The partition has been created and formatted months ago under CURRENT. In single user mode, I reformatted the partition again - with journaling and softupdates enabled. As with the /cfg partition on NanoBSD with SD card, I didn't realise any faults again since then. FWIW I *also* experience this on gpart/FFS2 partitioned/formatted drives *with* journaling enabled. As a result; if the system crashes, more often times, than not, fsck(8) canNOT use the journal, and indicates that it must "fall through" to complete the task. This is on a SATA (ahci) driven disk. My experiences with this seem to suggest that journaling is the cause. > > > > > > Best regards > > Michael > > > > > > Warner -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). --Chris ___ 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"
Make periodic's output log to files if sendmail is disabled on install
1) if sendmail is disabled during installation, have periodic's output logged to files (per example in https://www.freebsd.org/cgi/man.cgi?periodic(8) ) 2) make this the default anyway (logging to files), arguably the vast majority of systems' reporting is ignored :) At least now it could be logrotated out! [22:54.53] AllanJude: will you make the installer smart that if the user disables sendmail, that periodic's output will be sent to logfiles instead? [22:55.17] not sure how doable that is [22:57.20] AllanJude: https://www.freebsd.org/cgi/man.cgi?periodic(8) <-- see examples [22:57.55] ohh [22:57.57] ok then [22:58.04] should be fairly easy to do then [23:00.02] AllanJude: I'd argue logging periodic to files should become the default since I'm willing to bet 99% of fBSD machines' output is ignored. [23:00.34] Myke: that is a reasonable idea for freebsd 12 [23:00.42] :) [23:00.55] want to email that to freebsd-current@freebsd.org [23:00.57] and then i'll do it ;) ___ 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: status-mail-rejects: appears to be broken
On Sun, 07 Jan 2018 14:13:01 +0100 "Ronald Klop"said On Sun, 17 Dec 2017 20:50:23 +0100, Chris H wrote: > I'm running on r326056, and periodic(8) doesn't seem to be working > as expected; > mail rejects: > > Checking for rejected mail hosts: > usage: fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=host] >[--ca-cert=file] [--ca-path=dir] [--cert=file] [--crl=file] >[-i file] [--key=file] [-N file] [--no-passive] [--no-proxy=list] >[--no-sslv3] [--no-tlsv1] [--no-verify-hostname] > [--no-verify-peer] >[-o file] [--referer=URL] [-S bytes] [-T seconds] >[--user-agent=agent-string] [-w seconds] URL ... >fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=host] >[--ca-cert=file] [--ca-path=dir] [--cert=file] [--crl=file] >[-i file] [--key=file] [-N file] [--no-passive] [--no-proxy=list] >[--no-sslv3] [--no-tlsv1] [--no-verify-hostname] > [--no-verify-peer] >[-o file] [--referer=URL] [-S bytes] [-T seconds] >[--user-agent=agent-string] [-w seconds] -h host -f file [-c dir] > > Also, 520.pfdenied doesn't produce any output. In fact, it doesn't appear > to be run at all. > > Any thoughts, or advice on how to best proceed? > > Thanks! > > --Chris This looks the same as what I experienced. It will be fixed by upgrading until at least this commit: http://www.secnetix.de/olli/FreeBSD/svnews/index.py?r=326343 It appears that you indicate anything past, or including r326343 resolves this I'll look into it. But FWIW I was able to get etc/periodic/security/520.pfdenied output working with the following diff(1): --- /etc/periodic/security/520.pfdenied.orig2017-11-21 06:57:04.0 -0800 +++ /etc/periodic/security/520.pfdenied 2017-03-29 16:22:50.0 -0700 @@ -24,7 +24,7 @@ # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # -# $FreeBSD: head/etc/periodic/security/520.pfdenied 306696 2016-10-04 23:12:35Z lidl $ +# $FreeBSD: head/etc/periodic/security/520.pfdenied 290405 2015-11-05 17:37:14Z lidl $ # # If there is a global system configuration file, suck it in. @@ -44,13 +44,8 @@ if check_yesno_period security_status_pfdenied_enable then TMP=`mktemp -t security` - for _a in "" $(pfctl -a "blacklistd" -sA 2>/dev/null) - do - pfctl -a ${_a} -sr -v -z 2>/dev/null | \ - nawk '{if (/^block/) {buf=$0; getline; gsub(" +"," ",$0); if ($5 > 0) print buf$0;} }' >> ${TMP} - done - if [ -s ${TMP} ]; then - check_diff new_only pf ${TMP} "${host} pf denied packets:" + if pfctl -sr -v 2>/dev/null | nawk '{if (/^block/) {buf=$0; getline; gsub(" +"," ",$0); print buf$0;} }' > ${TMP}; then + check_diff new_only pf ${TMP} "${host} pf denied packets:" fi rc=$? rm -f ${TMP} Thanks for taking the time to reply, Ronald! Ronald. --Chris ___ 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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
On Sun, 7 Jan 2018 12:31:34 +0100 "O. Hartmann"said Am Thu, 4 Jan 2018 12:14:47 +0100 "O. Hartmann" schrieb: > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen wrote: > > > > On 31. Dec 2017, at 02:45, Warner Losh wrote: > > > > > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann > wrote: > > > > > >> On most recent CURRENT I face the error shwon below on /tmp filesystem > > >> (UFS2) residing > > >> on a Samsung 850 Pro SSD: > > >> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != > > >> bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> > > >> I've already formatted the /tmp filesystem, but obviously without any > > >> success. > > >> > > >> Since I face such strange errors also on NanoBSD images dd'ed to SD > cards, > > >> I guess there > > >> is something fishy ... > > > > > > > > > It indicates a problem. We've seen these 'corruptions' on data in motion > at > > > work, but I hacked fsck to report checksum mismatches (it silently > corrects > > > them today) and we've not seen any mismatch when we unmount and fsck the > > > filesystem. > > Not sure this helps: But we have seen this also after system panics > > when having soft update journaling enabled. Having soft update journaling > > disabled, we do not observed this after several panics. > > Just to be clear: The panics are not related to this issue, > > but to other network development we do. > > > > You can check using tunefs -p devname if soft update journaling is enabled > or > > not. > > In all cases I reported in earlier and now, softupdates ARE ENABLED on all > partitions in question (always GPT, in my cases also all on flash based > devices, SD card and/or SSD). ... and journalling as well! In case of the SD, I produced the layout of the NanoBSD image via "dd" including the /cfg partition. The problem occured even when having overwritten the SD card with a new image. The problem went away once I unmounted /cfg and reformatted via newfs. After that, I did not see any faults again! I have no explanation for this behaviour except the dd didn't overwrite "faulty" areas or the obligate "gpart recover" at the end of the procedure restored something faulty. The /tmp filesystem I reported in was also from an earlier date - and I didn't formatted it as I said - I confused the partition in question with another one. The partition has been created and formatted months ago under CURRENT. In single user mode, I reformatted the partition again - with journaling and softupdates enabled. As with the /cfg partition on NanoBSD with SD card, I didn't realise any faults again since then. FWIW I *also* experience this on gpart/FFS2 partitioned/formatted drives *with* journaling enabled. As a result; if the system crashes, more often times, than not, fsck(8) canNOT use the journal, and indicates that it must "fall through" to complete the task. This is on a SATA (ahci) driven disk. My experiences with this seem to suggest that journaling is the cause. > > > > > > Best regards > > Michael > > > > > > Warner -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). --Chris ___ 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
> On Jan 7, 2018, at 5:44 PM, Jon Brawnwrote: > > >> 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
> On Jan 6, 2018, at 10:18 PM, blubee blubeemewrote: > > 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: Running FreeBSD on the Lenovo Thinkpad T470s (success)
On 7. Jan 2018, at 22:40, Rodney W. Grimeswrote: >> >> >> On 7. Jan 2018, at 21:32, Rodney W. Grimes >> wrote: >> >> On 7. Jan 2018, at 20:43, clutton wrote: >> >> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >> Hi, > > Running carbon 5th gen I can't call my setup a success. Wireless iwm > doesn't support even N and AC is not supported at all. The wifi is much > slower then on my old machines. I'm going to replace the wifi card in > mean time, any suggestions which one to buy? > > Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to > resume from sleep, sometimes it does after big timeout and writing > errors to console, sometime it just reboots. > > Thinkpad Thunderbolt Dock Station, here is where things get > interesting. If I boot machine connected to dock station, peripheral > devices would work, external monitor, keyboard, and mouse. There's no > other way I know to make it work. Once detached - it wouldn't see > devices again. Booting and THEN attaching - the same, machine wouldn't > see devices. > > Here is the device being seen (a lot of pcib*): > pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 > rev=0x02 hdr=0x01 > vendor = 'Intel Corporation' > device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge > 4C 2016]' > class = bridge > subclass = PCI-PCI > > > For me the main concern is Thunderbolt thought, docking station is > amazing thing. Any ideas and thought how to make it work would be > highly appreciated. In my setup, plug/unplug events for display port don't work when docking (usually I'm not using a dock though). This means: Mouse, Keyboard can be plugged/unplugged as many time as I want at any point, while displays connected over display port only work when connected before starting X (and they don't disappear after disconnecting). Note that stopping X seems to fix this (so no reboot required), but I don't have the docking station myself (this is the Ultra Dock Pro or something - the one that connects at the bottom of the laptop). Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned interfaces (which isn't something I wouldn't expect I have to do, but in this case I had to). >>> >>> Did you have a >>> wlans_iwm0="wlan0" >>> in /etc/rc.conf? >>> I do not know or see why putting iwm0 in cloned would do much of anything >>> for a wlan device. >>> >>> Also note that is wlans as in plural, not wlan_iwm0. A mistake I >>> often make from finger memory. >>> >> >> I have >> >> wlans_iwm0="wlan0" >> ifconfig_wlan0="WPA DHCP country de" > I use just simply: > ifconfig_wlan0="WPA SYNCDHCP" > > I think without the SYNC you are not waiting for wpa to come up? I works ok, if I really wanted to wait for getting an IP that would make sense, yes. > I do not know of the /etc/rc.d/* stuff is prepared to deal with > your "country de" either. > It is, as country DE shows up in ifconfig after boot and it can actually associate (which it couldn't before adding the country, probably the channel was out of range with default settings). >> >> in rc.conf. Without adding >> >> cloned_interfaces="iwm0" >> >> wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's >> current r326912, setup like described in my blog post). >> >> I just double checked to confirm the behavior. > > Something is broken some place. > Well, if I actually add if_iwm_load="YES" if_iwm3160fw_load="YES" if_iwm7260fw_load="YES" if_iwm7265Dfw_load="YES" if_iwm7265fw_load="YES" if_iwm8000Cfw_load="YES" if_iwm8265fw_load="YES" to /boot/loader.conf (like documented in the man page ^_^), it works without adding iwm0 to cloned_interfaces. Funny how I forgot to do that and how cloned_interfaces just did the right thing by loading the correct modules. Sorry for creating confusion. -m >> Best, >> Michael > > -- > Rod Grimes rgri...@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: Running FreeBSD on the Lenovo Thinkpad T470s (success)
On 7. Jan 2018, at 21:32, Rodney W. Grimeswrote: >> >> On 7. Jan 2018, at 20:43, clutton wrote: On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: Hi, >>> >>> Running carbon 5th gen I can't call my setup a success. Wireless iwm >>> doesn't support even N and AC is not supported at all. The wifi is much >>> slower then on my old machines. I'm going to replace the wifi card in >>> mean time, any suggestions which one to buy? >>> >>> Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to >>> resume from sleep, sometimes it does after big timeout and writing >>> errors to console, sometime it just reboots. >>> >>> Thinkpad Thunderbolt Dock Station, here is where things get >>> interesting. If I boot machine connected to dock station, peripheral >>> devices would work, external monitor, keyboard, and mouse. There's no >>> other way I know to make it work. Once detached - it wouldn't see >>> devices again. Booting and THEN attaching - the same, machine wouldn't >>> see devices. >>> >>> Here is the device being seen (a lot of pcib*): >>> pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 >>> rev=0x02 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge >>> 4C 2016]' >>> class = bridge >>> subclass = PCI-PCI >>> >>> >>> For me the main concern is Thunderbolt thought, docking station is >>> amazing thing. Any ideas and thought how to make it work would be >>> highly appreciated. >> >> In my setup, plug/unplug events for display port don't work when docking >> (usually I'm not using a dock though). This means: Mouse, Keyboard can be >> plugged/unplugged as many time as I want at any point, while displays >> connected over display port only work when connected before starting X (and >> they don't disappear after disconnecting). Note that stopping X seems to fix >> this (so no reboot required), but I don't have the docking station myself >> (this is the Ultra Dock Pro or something - the one that connects at the >> bottom of the laptop). >> >> Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned >> interfaces (which isn't something I wouldn't expect I have to do, but in >> this case I had to). > > Did you have a >wlans_iwm0="wlan0" > in /etc/rc.conf? > I do not know or see why putting iwm0 in cloned would do much of anything > for a wlan device. > > Also note that is wlans as in plural, not wlan_iwm0. A mistake I > often make from finger memory. > I have wlans_iwm0="wlan0" ifconfig_wlan0="WPA DHCP country de" in rc.conf. Without adding cloned_interfaces="iwm0" wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's current r326912, setup like described in my blog post). I just double checked to confirm the behavior. Best, Michael ___ 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: Running FreeBSD on the Lenovo Thinkpad T470s (success)
> On 7. Jan 2018, at 20:43, cluttonwrote: > >> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >> Hi, > > Running carbon 5th gen I can't call my setup a success. Wireless iwm > doesn't support even N and AC is not supported at all. The wifi is much > slower then on my old machines. I'm going to replace the wifi card in > mean time, any suggestions which one to buy? > > Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to > resume from sleep, sometimes it does after big timeout and writing > errors to console, sometime it just reboots. > > Thinkpad Thunderbolt Dock Station, here is where things get > interesting. If I boot machine connected to dock station, peripheral > devices would work, external monitor, keyboard, and mouse. There's no > other way I know to make it work. Once detached - it wouldn't see > devices again. Booting and THEN attaching - the same, machine wouldn't > see devices. > > Here is the device being seen (a lot of pcib*): > pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 > rev=0x02 hdr=0x01 >vendor = 'Intel Corporation' >device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge > 4C 2016]' >class = bridge >subclass = PCI-PCI > > > For me the main concern is Thunderbolt thought, docking station is > amazing thing. Any ideas and thought how to make it work would be > highly appreciated. In my setup, plug/unplug events for display port don't work when docking (usually I'm not using a dock though). This means: Mouse, Keyboard can be plugged/unplugged as many time as I want at any point, while displays connected over display port only work when connected before starting X (and they don't disappear after disconnecting). Note that stopping X seems to fix this (so no reboot required), but I don't have the docking station myself (this is the Ultra Dock Pro or something - the one that connects at the bottom of the laptop). Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned interfaces (which isn't something I wouldn't expect I have to do, but in this case I had to). -m ___ 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
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"
newcons vs syscons
I'm curious why the new console driver vt doesn't have a vesa driver when the traditional syscons driver did. https://wiki.freebsd.org/Newcons Is there any specific reason why vesa driver wasn't implemented? ___ 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
On Mon, Jan 8, 2018 at 1:41 AM, Mark Millardwrote: > > 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: partitioning schemes: GPT <-> MBR
On Sun, 2018-01-07 at 18:58 +0100, Wolfram Schneider wrote: > Hi guys, > > I have 2 small virtual machines running in data center, on similar > hardware. Both are running FreeBSD 12-current. The first one is based > on a 10.3 image, upgraded to current. The second one is based on > 11.1, > upgraded to current. > > I notice a difference in disk partitioning. 10.3 is using GPT, and > 11.1 MBR. > > [FreeBSD 10.3] > $ gpart show > => 34 83886013 vtbd0 GPT (40G) > 34 1024 1 freebsd-boot (512K) > 1058 2097152 2 freebsd-swap (1.0G) > 2098210 81787836 3 freebsd-ufs (39G) > 83886046 1 - free - (512B) > > [FreeBSD 11.1] > $ gpart show > => 63 83886017 vtbd0 MBR (40G) > 63 1 - free - (512B) > 64 79691776 1 freebsd [active] (38G) > 79691840 4194240 - free - (2.0G) > > I thought that MBR is outdated. But the hosting company told me that > FreeBSD 11.1 is using MBR by default. Is that correct? > > My problem with the MBR machine is that I cannot add a swap device. > There are 2GB free space, and I want add a 1GB swap device: > > $ gpart add -s 1G -t freebsd-swap vtbd0 > gpart: Invalid argument > > is this an MBR issue? > > thanks, Wolfram > You need to add a new freebsd slice, then add the freebsd swap partition within it: gpart add -s 1g -t freebsd vtdb0 gpart create -s bsd vtdb0s2 gpart add -t freebsd-swap vtdb0s2 Now you should have a /dev/vtdb0s2b available for swap. There will also be ~1g still available to create another slice. Another alternative is just create the vtdb0s2 slice, then don't subdivide it into BSD partitions at all, just add /dev/vtdb0s2 to fstab as a swap device. -- Ian ___ 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"
partitioning schemes: GPT <-> MBR
Hi guys, I have 2 small virtual machines running in data center, on similar hardware. Both are running FreeBSD 12-current. The first one is based on a 10.3 image, upgraded to current. The second one is based on 11.1, upgraded to current. I notice a difference in disk partitioning. 10.3 is using GPT, and 11.1 MBR. [FreeBSD 10.3] $ gpart show => 34 83886013 vtbd0 GPT (40G) 34 1024 1 freebsd-boot (512K) 1058 2097152 2 freebsd-swap (1.0G) 2098210 81787836 3 freebsd-ufs (39G) 83886046 1 - free - (512B) [FreeBSD 11.1] $ gpart show => 63 83886017 vtbd0 MBR (40G) 63 1 - free - (512B) 64 79691776 1 freebsd [active] (38G) 79691840 4194240 - free - (2.0G) I thought that MBR is outdated. But the hosting company told me that FreeBSD 11.1 is using MBR by default. Is that correct? My problem with the MBR machine is that I cannot add a swap device. There are 2GB free space, and I want add a 1GB swap device: $ gpart add -s 1G -t freebsd-swap vtbd0 gpart: Invalid argument is this an MBR issue? thanks, Wolfram -- Wolfram Schneiderhttps://wolfram.schneider.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
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
On Sun, Jan 7, 2018 at 8:13 PM, Mark Millardwrote: > [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: status-mail-rejects: appears to be broken
This looks the same as what I experienced. It will be fixed by upgrading until at least this commit: http://www.secnetix.de/olli/FreeBSD/svnews/index.py?r=326343 Ronald. On Sun, 17 Dec 2017 20:50:23 +0100, Chris Hwrote: I'm running on r326056, and periodic(8) doesn't seem to be working as expected; mail rejects: Checking for rejected mail hosts: usage: fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=host] [--ca-cert=file] [--ca-path=dir] [--cert=file] [--crl=file] [-i file] [--key=file] [-N file] [--no-passive] [--no-proxy=list] [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] [--no-verify-peer] [-o file] [--referer=URL] [-S bytes] [-T seconds] [--user-agent=agent-string] [-w seconds] URL ... fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=host] [--ca-cert=file] [--ca-path=dir] [--cert=file] [--crl=file] [-i file] [--key=file] [-N file] [--no-passive] [--no-proxy=list] [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] [--no-verify-peer] [-o file] [--referer=URL] [-S bytes] [-T seconds] [--user-agent=agent-string] [-w seconds] -h host -f file [-c dir] Also, 520.pfdenied doesn't produce any output. In fact, it doesn't appear to be run at all. Any thoughts, or advice on how to best proceed? Thanks! --Chris ___ 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
[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
[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 Millardwrote: > [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: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
Am Thu, 4 Jan 2018 12:14:47 +0100 "O. Hartmann"schrieb: > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen wrote: > > > > On 31. Dec 2017, at 02:45, Warner Losh wrote: > > > > > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann > > > wrote: > > > > > >> On most recent CURRENT I face the error shwon below on /tmp filesystem > > >> (UFS2) residing > > >> on a Samsung 850 Pro SSD: > > >> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != > > >> bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > > >> != bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> > > >> I've already formatted the /tmp filesystem, but obviously without any > > >> success. > > >> > > >> Since I face such strange errors also on NanoBSD images dd'ed to SD > > >> cards, > > >> I guess there > > >> is something fishy ... > > > > > > > > > It indicates a problem. We've seen these 'corruptions' on data in motion > > > at > > > work, but I hacked fsck to report checksum mismatches (it silently > > > corrects > > > them today) and we've not seen any mismatch when we unmount and fsck the > > > filesystem. > > Not sure this helps: But we have seen this also after system panics > > when having soft update journaling enabled. Having soft update journaling > > disabled, we do not observed this after several panics. > > Just to be clear: The panics are not related to this issue, > > but to other network development we do. > > > > You can check using tunefs -p devname if soft update journaling is enabled > > or > > not. > > In all cases I reported in earlier and now, softupdates ARE ENABLED on all > partitions in question (always GPT, in my cases also all on flash based > devices, SD card and/or SSD). ... and journalling as well! In case of the SD, I produced the layout of the NanoBSD image via "dd" including the /cfg partition. The problem occured even when having overwritten the SD card with a new image. The problem went away once I unmounted /cfg and reformatted via newfs. After that, I did not see any faults again! I have no explanation for this behaviour except the dd didn't overwrite "faulty" areas or the obligate "gpart recover" at the end of the procedure restored something faulty. The /tmp filesystem I reported in was also from an earlier date - and I didn't formatted it as I said - I confused the partition in question with another one. The partition has been created and formatted months ago under CURRENT. In single user mode, I reformatted the partition again - with journaling and softupdates enabled. As with the /cfg partition on NanoBSD with SD card, I didn't realise any faults again since then. > > > > > > Best regards > > Michael > > > > > > 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" > > > > ___ > > 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" > -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpjfX7synlMU.pgp Description: OpenPGP digital signature
Re: USB stack
[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
On Sun, Jan 7, 2018 at 5:35 PM, Mark Millardwrote: > 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
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
On Sun, Jan 7, 2018 at 4:27 PM, Freddie Cashwrote: > Forgot to include the list. Resending. > > -- Forwarded message -- > From: "Freddie Cash" > Date: Jan 7, 2018 12:26 AM > Subject: Re: USB stack > To: "blubee blubeeme" > Cc: > > On Jan 6, 2018 8:30 PM, "blubee blubeeme" 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
Forgot to include the list. Resending. -- Forwarded message -- From: "Freddie Cash"Date: Jan 7, 2018 12:26 AM Subject: Re: USB stack To: "blubee blubeeme" Cc: On Jan 6, 2018 8:30 PM, "blubee blubeeme" 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"