From owner-freebsd-current@freebsd.org Sun Jan 7 04:20:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0D04E65B02 for ; Sun, 7 Jan 2018 04:20:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE9E7484B for ; Sun, 7 Jan 2018 04:20:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id n14so9709384iob.4 for ; Sat, 06 Jan 2018 20:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J2tsNpd5a/ldBKWge62j7cVN2UyVHTZIK/3L/ksTO9Q=; b=VIArw18DFU+EQnEIMmiU1R5v4jxPp+pj7mHWz36okOJ0QHHqP5cLn14/pb0Of0QXRx eIO3g8H16jVCHV8LnG0vwQd7mrftzGdza8CcxcXsAAa1Kf8th3pBPHWr4RighvMrXRaH WoO/uYj+o/qPAiKIMHUyWGsvcXfjLbNBOyeYHhDHhaV69Y+3woh7r/92W4sgWM1CD2mB vwwQH6vQeO/VcsOWdaT4xV+2dA3MUKttc4xcWB22spaLe/SD0hfW36O6b6+s04m8NPoR 6LdXaKwFjqPP7StXDKvcrUb4N3GTG8MmCTcOedcv83MU+joYlhP2THAe2Zk3B4YuIAzs frAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=J2tsNpd5a/ldBKWge62j7cVN2UyVHTZIK/3L/ksTO9Q=; b=G21o8WKyzWJgvaL86B8ml9xzMCzga4MWzrritTggnfaTBVtvaoP1Q8gsyKyHFeQlCe UYPMXSrNMpmhtKL8lr/QRKoSSXq3hJ11iOkiItUSLMC9MqFGOWFkA66FJZeoQn95/HDJ RL9B2OBTF0Ey33tZ4Aeud6NIBFCbEOopPKoaPlqCF4qXO+SEag9llHaoM5vXhKwi679D 8GKInj4o10lFQj1hfzOVFtpfRcXLhj+Yxgzy7Np11Qf50DOkGYT21/ffsg1Qg1LabMvO DX9N5XCA0BVjq8pMqEMIwbM+SBS02bBiyimwoK+W0CnRlz6XWVvVskOApYN3XepugKlM mJNA== X-Gm-Message-State: AKwxytf4UTun/H+Q7u6+0ulzxzSNK0J1QdU72HqUJfWPPpQHVKnPmNch pj/8RNf0wfB0tu6MbvXL5TvpeIs3nWX1jXOmtarV/A== X-Google-Smtp-Source: ACJfBosinBsNzTSuuXQvM738+3EvchJaSsx/RU1NqgpA6f2d1hw2L/q5l8jgBldECdwYg990V0VbooLgzAB5xDY4ZDo= X-Received: by 10.107.78.12 with SMTP id c12mr7320995iob.63.1515298819920; Sat, 06 Jan 2018 20:20:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 20:20:19 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: Warner Losh Date: Sat, 6 Jan 2018 21:20:19 -0700 X-Google-Sender-Auth: U4J7CwAxB44lSP2iNoELs9KECxs Message-ID: Subject: Re: USB stack To: blubee blubeeme Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:20:20 -0000 On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme wrote: > > > On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > >> >> >> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme >> wrote: >> >>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater >>> and the topic gets derailed...? >>> >> >> Yes, it does. >> >> >>> Are you guys saying that 7-8MB/s is USB speeds? >>> >> >> I've gotten up to 24MB/s for maybe a decade. That's not possible with USB >> 1.x. More recently, I've maxed out the writes on a USB stick at about >> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've >> not tried USB3 with an SSD that can do more.... >> >> Warner >> >> >>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>> wrote: >>> >>> > >>> > >>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn >>> wrote: >>> > >> What is an "LG v30"? >>> > >> >>> > > It's a smartphone from LG and only supports USB2 speed. The reported >>> > > transfer rate is no big surprise. >>> > >>> > OK thanks. >>> > >>> > -- >>> > Daniel O'Connor >>> > "The nice thing about standards is that there >>> > are so many of them to choose from." >>> > -- Andrew Tanenbaum >>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>> > >>> > >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>> reebsd.org" >>> >> >> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > ------------------------------------------------------------------- > Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > Jan 7 11:56:56 blubee kernel: umass0: Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > 0x0100 > Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun > 0 > Jan 7 11:56:56 blubee kernel: da0: Fixed Direct > Access SPC-4 SCSI device > Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) > Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > Jan 7 12:06:08 blubee kernel: lock order reversal: > Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait (bufwait) @ > /usr/src/sys/vm/vm_pager.c:374 > Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > /usr/src/sys/dev/md/md.c:952 > Jan 7 12:06:08 blubee kernel: stack backtrace: > Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > witness_debugger+0x73 > Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > witness_checkorder+0xe02 > Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > lockmgr_lock_fast_path+0x1ae > Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 > Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at mdstart_vnode+0x442 > Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe > Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at fork_trampoline+0xe > Jan 7 12:06:15 blubee kernel: lock order reversal: > Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3562 > Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > Jan 7 12:06:15 blubee kernel: stack backtrace: > Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > witness_debugger+0x73 > Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > witness_checkorder+0xe02 > Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at ufsdirhash_add+0x3d > Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at ufs_direnter+0x459 > Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at ufs_makeinode+0x613 > Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 > Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at VOP_CREATE_APV+0xd3 > Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at vn_open_cred+0x2ad > Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at kern_openat+0x212 > Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > amd64_syscall+0x79b > Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at Xfast_syscall+0xfb > > > Is the slow transfers user error? > It's likely due to the slow UFS issue... Warner From owner-freebsd-current@freebsd.org Sun Jan 7 04:25:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85A46E662F6 for ; Sun, 7 Jan 2018 04:25:22 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9686674E68 for ; Sun, 7 Jan 2018 04:25:19 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id m11so8227430iti.1 for ; Sat, 06 Jan 2018 20:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9VJOcKaOAoPMJuRL0v83LHKGYNjyczXYfqZPwg0KLE8=; b=KLmdle357+lXSg+4hmMt+phqv2blW0I4xnxXWJwa2G4gsc1X/+BL1cYyvRfIW7nIT8 6yib0/U4HpTUmG8v21dyA/SROq1CX1sJxyqlHLfQLJye/CBBSyFU4A5HgvdcYkk5G0Iu QmT19La4OAdlrnZ4fncQZv2jG7FrLgfUd7H0yuAfgVYzO3SdS0ZrTRa2cLSF207w0/sJ uKJ7nqeN+yI3bf4aratE/RuwIGx3PvrWSQpTQztcowJIB6NgvOMWWWR4TB+iHkvhjRLc /3TtxNTR6xSnV2pDmEEB3M4UnwZYXVxyaWW4llEWSBkOZdqmnIlxrZmZD2DyYwai8C4i mMqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9VJOcKaOAoPMJuRL0v83LHKGYNjyczXYfqZPwg0KLE8=; b=R0potR/JY7Grh/e4/i38radgCThIXJd+1zU0LWP4u0/4htoDwgn1DmrolygW3TXUj1 z4K4GEgwqDP2Ctn/vPEisc9Z7UjpITaa0Ijhucu+yqVmvhxLLN4qmRZW/rflqx73QpX2 moNh1QFOD6fUDWY7/RjqZCsxvfWTEPTSk3TuSPyWcgpbu0L1f8nd2PIffW8M1X1WwB4C LLH6Yhln5Itwf0cZQab/36C1M181SNy9p3Z6acS3qMdp4ZUV3mC9a25ytdJFE8JFQrtf t7+gmpaovQWNscnDmsLFXE+B2KQ944aw8ZXJ6XVPuR77khwuDh1cCzYO3ebx97/EnoMf 9Shg== X-Gm-Message-State: AKwxytfVXqxCa8X+beq+A4qNg54IpsAxsdFFhNOpb/pc7N2iIRP6vwvX 9iqHohZI2xeSTV06+Bqgs08WOm3yg+qoisUttxVgJDMK X-Google-Smtp-Source: ACJfBotFSdntOjKb6Pz7BLu+49/GbWVeordRlHnCCLcaNwGTeUNqnXHQ9FFiFeuHvHd5FhOHvblmgoQlmlWQSZ0i+Kw= X-Received: by 10.36.185.18 with SMTP id w18mr513091ite.140.1515299118397; Sat, 06 Jan 2018 20:25:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 20:25:17 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 12:25:17 +0800 Message-ID: Subject: Re: USB stack To: Warner Losh Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:25:22 -0000 On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: >> >>> >>> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme >>> wrote: >>> >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater >>>> and the topic gets derailed...? >>>> >>> >>> Yes, it does. >>> >>> >>>> Are you guys saying that 7-8MB/s is USB speeds? >>>> >>> >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've >>> not tried USB3 with an SSD that can do more.... >>> >>> Warner >>> >>> >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>>> wrote: >>>> >>>> > >>>> > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn >>>> wrote: >>>> > >> What is an "LG v30"? >>>> > >> >>>> > > It's a smartphone from LG and only supports USB2 speed. The >>>> reported >>>> > > transfer rate is no big surprise. >>>> > >>>> > OK thanks. >>>> > >>>> > -- >>>> > Daniel O'Connor >>>> > "The nice thing about standards is that there >>>> > are so many of them to choose from." >>>> > -- Andrew Tanenbaum >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> > >>>> > >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>>> reebsd.org" >>>> >>> >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone >> ------------------------------------------------------------------- >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 >> Jan 7 11:56:56 blubee kernel: umass0: > Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = >> 0x0100 >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 >> lun 0 >> Jan 7 11:56:56 blubee kernel: da0: Fixed Direct >> Access SPC-4 SCSI device >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 >> Jan 7 12:06:08 blubee kernel: lock order reversal: >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait (bufwait) >> @ /usr/src/sys/vm/vm_pager.c:374 >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ >> /usr/src/sys/dev/md/md.c:952 >> Jan 7 12:06:08 blubee kernel: stack backtrace: >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at >> witness_debugger+0x73 >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at >> witness_checkorder+0xe02 >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at >> lockmgr_lock_fast_path+0x1ae >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at >> mdstart_vnode+0x442 >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at >> fork_trampoline+0xe >> Jan 7 12:06:15 blubee kernel: lock order reversal: >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait (bufwait) >> @ /usr/src/sys/kern/vfs_bio.c:3562 >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash (dirhash) >> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 >> Jan 7 12:06:15 blubee kernel: stack backtrace: >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at >> witness_debugger+0x73 >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at >> witness_checkorder+0xe02 >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at >> ufsdirhash_add+0x3d >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at ufs_direnter+0x459 >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at >> ufs_makeinode+0x613 >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at >> VOP_CREATE_APV+0xd3 >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at vn_open_cred+0x2ad >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at kern_openat+0x212 >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at >> amd64_syscall+0x79b >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at >> Xfast_syscall+0xfb >> >> >> Is the slow transfers user error? >> > > It's likely due to the slow UFS issue... > > Warner > The Transcend ssd is formated ZFS, I use it as a backup. The microsd might suffer from what you say since it's formatted by Android but I do not get these slow transfer speeds on other OS. so a quick roundup. 1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds; let's say that's because of the Android OS default format. I only get these slow speeds on FreeBSD, why is that? 2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above; are the slow speeds user error or something else? @Warner Losh what was your setup where you were able to transfer 23-75MB/s to your USB device? From owner-freebsd-current@freebsd.org Sun Jan 7 03:56:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2F48E63B0F for ; Sun, 7 Jan 2018 03:56:10 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7444473465 for ; Sun, 7 Jan 2018 03:56:10 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id t63so9711625iod.0 for ; Sat, 06 Jan 2018 19:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a34VVL2OIlVRF41NW1FzqSPLeWH9hN07jtZgDj5MCv8=; b=pIIB24ZCzZ/yaw2qxO193MqAvQMcgqs1o0CkIDmlUnM5avJsEp1VcJCZHwTijtCSUj COn+fVVSrPt/6QhUuHc7WKA9Yj/bAaJ82FueXFyqWbmyP3xEwXPJKnvZ6lJENcIcvYSi Yi/mjoZOVLEBRKTJK2LKcyZPn8DMGtSIAGxUvc0vFc8C1gJGI4UvjX5NoXHlCQOkjglV k4TzQnvkFJQWM+Ae+a1+n6L/RmKU0y0KA607RN53K4egcALIsL3QKGuY+W0tDmmemqDg 3W+5SBnKtF04Hz+0qaLUvvCNi6UG2h7GTxEI6f9SxJsFBItYRxrUQIYTMR5m1yHQ028U dsng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a34VVL2OIlVRF41NW1FzqSPLeWH9hN07jtZgDj5MCv8=; b=Rc58tpnnJGthAsLYYjtlAdqfiP1dYWufehQrBXxhkmdIL4C9KjBxdFlgW+UVqq4NW8 QpEQOvWaXRwzp1hXzYbe3f2eqbx0jb5llkoJrP2VNfbzkpXYfo+vUvGiNoRNqtImrna3 myG8ySxol1IGZurvy+jaEYXNgt9f+RAcCceypwtqz9K1gjBhYvxRYbLoD7Ct6XOb+QNl PtCGf2Giwo4o0cxGOmP+tmWeVW6vlf6ELfMq+KEHgFTyY3RYkJTOYryL03rW+1Yylh3Y 0lhjP0JFNPBQpTivYG3iICFG4HOOmPJzZDnYpoMNs7xXmH817vbFY4X++OEUn86b3R3A exag== X-Gm-Message-State: AKwxytcqxkT4wBHH7TsfEMYA1JvECSj8a0/MvnR4gWYXEl9KlBQBvEh6 8RCuGQqO8g0VW4GOp1lAuhNquK5w7+NgTNNBXVw= X-Google-Smtp-Source: ACJfBovi22m8NmXp3qrBLI907SkN2DZWwqZD7svi52EvVpiyDnaZ1DgEQu2pTDl5K2evtm6qdUx0JLZ7+4zwXOyMzuI= X-Received: by 10.107.12.36 with SMTP id w36mr8170251ioi.291.1515297369778; Sat, 06 Jan 2018 19:56:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 19:56:09 -0800 (PST) In-Reply-To: <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 11:56:09 +0800 Message-ID: Subject: Re: USB stack To: "O'Connor, Daniel" Cc: gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 03:56:10 -0000 I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater and the topic gets derailed...? Are you guys saying that 7-8MB/s is USB speeds? On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel wrote: > > > > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: > >> What is an "LG v30"? > >> > > It's a smartphone from LG and only supports USB2 speed. The reported > > transfer rate is no big surprise. > > OK thanks. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > From owner-freebsd-current@freebsd.org Sun Jan 7 04:08:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70822E64C60 for ; Sun, 7 Jan 2018 04:08:39 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4240874037 for ; Sun, 7 Jan 2018 04:08:39 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x233.google.com with SMTP id p139so5715090itb.1 for ; Sat, 06 Jan 2018 20:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=av06yMdGcSOoifeATcWlzkeGt1mhpD22WL662C/IRbs=; b=G4FEknUU6ErjTO54RuxvWS3WRw2JR3ryYmvLnmx50BOV7JfDd4a1FPJlLB7FFIuVKe M1eYTOAOmTHGnxTYO3Pq+0AbojN30/aVtQfIBxh6yM4nVnpOcpesSAz3OBpeM4b7ZnrW puEne3NDsA9XKe3D5iw7cbbZeV1kvQez2RTM67/eMGgIpY2AwbzJTfmaClgyOrAfi1Bf uY3NUX62xU2Koo7LZXUqKxUOMce5R5zpKYBb/soQD7VtYCej9HAFvKKVDDAZCcdqAiyy tsZN3gRqRihjvVjPL8LicxQkbk/mC9TkSGhor6OYHcyTNQBsWCgdYDWX/KM2/cCr/Jgs IDhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=av06yMdGcSOoifeATcWlzkeGt1mhpD22WL662C/IRbs=; b=WvZi0PcsW+v1mNAXc7mKRP0PUfMkKfncFDqd2IwnkPvocsT4ysB4M8t7K0KzUplOXg r/DafwkVeXwyhLc/PRI84Z9xEbK+WSGGKhZXRrHA5NB9mQhlFyf9PN8Wha/qs0DLsxzy /A/6gEE6FAw6zwr1E8jkYE/aqsr/iDO72U4HeR+xLpvWAt7i7kJCyAEGJJi2G+CRP5LR 4u8Zeps1A+I6AkjcQ3rvmr1RNa99wbs533BaIsS24JmyimAEx4uMdauVg2rjV0Hk/u6Q P+4RCHrPkJ39gaZZtjMsrj5IM5sjMkn2LTzJ5cw/FfY3o52Cbjw/xVrKZSrNXcaoQYY+ 0Y8Q== X-Gm-Message-State: AKGB3mITH7/xVF4/t7KNUnGuhLwnXHbvvSDo18NjtEAJIEZd6as6X1hW bw55quO0GA6fPfTi3Op+T6AIvns5/wnVX01l6hA= X-Google-Smtp-Source: ACJfBotk1nOYC0mnfGGG0KGRGiv55gFlOPH8fYp0NKwEQdLoSGw+BHZUdNsU8w5HtI9DMYkcjUhJTU+LRs7CzPXTqH8= X-Received: by 10.36.110.71 with SMTP id w68mr7160656itc.119.1515298118489; Sat, 06 Jan 2018 20:08:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 20:08:37 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 12:08:37 +0800 Message-ID: Subject: Re: USB stack To: "O'Connor, Daniel" Cc: gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:08:39 -0000 On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme wrote: > I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater > and the topic gets derailed...? > > Are you guys saying that 7-8MB/s is USB speeds? > > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > wrote: > >> >> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: >> >> What is an "LG v30"? >> >> >> > It's a smartphone from LG and only supports USB2 speed. The reported >> > transfer rate is no big surprise. >> >> OK thanks. >> >> -- >> Daniel O'Connor >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> > Actually, this post: https://forums.freebsd.org/threads/41041/ on the forum from 2013 pretty well describes what I am experiencing when moving data over USB. I have no problems hitting very high read/ write speeds using dd or downloading something but copying by USB is excruciatingly slow. Why is that? From owner-freebsd-current@freebsd.org Sun Jan 7 04:11:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEE45E64DA7 for ; Sun, 7 Jan 2018 04:11:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2B72740CA for ; Sun, 7 Jan 2018 04:11:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id w188so9698870iod.10 for ; Sat, 06 Jan 2018 20:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CNgCgMyL8ALA6BXY3bo2FpygNU3kxqHbdtznI5+Puk4=; b=zs3Oxa7sDbGpDYLbVaW3+nEa9jdJ2Nj4QkvR3vdb6Qu4zc7XU+qpw6v9nvxjyflkcL SkmFyygMMEsulcgYeEcTOiQlTiTGGO/B4JWrtpCnuoUYM25Uh4F2xbcOVdXdoIVC9mlI zDLMADPWR8fbPLhgV+x4A7eI3g2Hc1TNw3NFazZSi6lig1x3/O5hCzYM68inuzX+rWSd Bev/W964+bQDMSFPAUO6t8QB94E6+U7MFsBF9Xn12phZaOy3noPffu3IbnncR7i1sjnD I2/yyNfTbo/o8sBP9VpVYJnXPNU6SZApnTWhJ2Rxy8NKZ8v6lIXcG876Z9/zB6hODs4v +6bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CNgCgMyL8ALA6BXY3bo2FpygNU3kxqHbdtznI5+Puk4=; b=QZhbXlnXcUJ0PKB7R57ikjjMLT7ReK9AXzaJ4HsUPVZ/U42TFzmet1v3QNbaEfmeOf qrtBK6SgpOegVt6nll+cOOJyJrSlaLb3gC/TyCIubqhCV619rIdd/XDe3F8VjtTyF+Pf hlPmDqfHuaVPr0s9wXPWwrZ3Lg2xWJDq3B2ozrQWkztk32N6DRHqOC1TPz9/TjKIvJ/d VGgadMhi7wAu5dYQjsOJYOTtgj7Q6hnq5/44sxF2qF8CHn8RgoXeluc5sH3RRlTUJJD5 FTGWTyZBvJVoEffii11oNHW8vj10N++8m3Kz9T/Gh4xuxgWIhebYiIHiC3smDkKlXxUm NadQ== X-Gm-Message-State: AKwxytcRdmbIVasCAPRzINYiJ0R91YXAQzwUXpSl5odWh3hbd//zy+WY F8psWlnNL5dikM6pnFrkgLIkDwx63um8hBnfd/KzYw== X-Google-Smtp-Source: ACJfBosacooidBkbGLEW+ybIfU2+SnlIRfynCYGPlzAu2e9Nd/BMAj32Q2ptrS3cbg7zPlddiO2Imlwz6qu40emvCvQ= X-Received: by 10.107.12.36 with SMTP id w36mr8192669ioi.291.1515298265917; Sat, 06 Jan 2018 20:11:05 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 20:11:05 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: Warner Losh Date: Sat, 6 Jan 2018 21:11:05 -0700 X-Google-Sender-Auth: ZbZvlOHqTBHRXQIlFdlwZwBOs5M Message-ID: Subject: Re: USB stack To: blubee blubeeme Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:11:07 -0000 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" > From owner-freebsd-current@freebsd.org Sun Jan 7 04:28:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08B1BE66871 for ; Sun, 7 Jan 2018 04:28:39 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBF38751C9 for ; Sun, 7 Jan 2018 04:28:38 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id b77so2561135itd.0 for ; Sat, 06 Jan 2018 20:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W+V0ZIP6/5HimUP1IpFgtB0jLeYt7ph1T+1211xOUXI=; b=tR885UIYFXVEX+1GFyKolHcpssC+2VNKDCx3w6xRgKwpnhiZPVMEqHloaW2PatkI5C uT5gEgH/2Do6OxleTv3u6MtrH+UCI3mc1UUWW+CGyOqc0bqUO8tinIwyhPPEK1Yw6x5Z u5PbSjjr+L5LrpFY2fTq8jCHxOocGk0aaMWU15Ftlss9ZJ0ABTUwVs/LYzsUM9LyhjVT lO4kjqO6QYHpJ3EOi4bN9FSxqbuvCjYFfnY+w2EhNOX/zSMlUO7UoR+yfA25UuBPJu4+ L6A/hsTo7v6BzO0bIwn2Ca6Xbkm+XqPCggSuLd5lTqSC8a9fPECgOtBaj8Sl7sFUM4Ae vnuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W+V0ZIP6/5HimUP1IpFgtB0jLeYt7ph1T+1211xOUXI=; b=iQ1CsDxhMJIRV4xx6eJ7R/fm6qHhP8Tel1EA5tkdq+JHcEWxmmrDzSiRmfKy6VOre8 pAbhpIjGMuRYbYNqLzoBF/ijxd/ZSGjpIDCe5+GC7oRI55wsmN+usKruwj8Ar7tIjtTx pBOcRnhQh3mera9wkHMhKRkRNjbDs++MKwmZ/l4dK+o61xyL+OYE+bo1cFJNrW31ML9Q CZSx+R/YhtM9tINkrzzfKev/jLjCYSapPeuoY4eNre0bGgBO9o+ZqmPF6DNx4l8WhMnR IRmVadfzsCp/DttN501WDWb+x20tdpZAezLUgBiraazQEZ76uvYqNPH16bALrnhuxyR3 dOrg== X-Gm-Message-State: AKGB3mI6aMamneNmvMn6u0PZ1DPvAMxjO/sKeyB29Yubpqkj74BFyU2s 9mEjza61+0+iCL6Ix0TZoSPUiaozpPgCqPotOII= X-Google-Smtp-Source: ACJfBou5f0Pj+aa0UBj4yYsI3mV0VMbnmewssf18dxeBXtGhWzafA+5lhM7BcRFQFm2nmRntO6jvGicDj8vTk0CNFe4= X-Received: by 10.36.110.71 with SMTP id w68mr7182233itc.119.1515299318054; Sat, 06 Jan 2018 20:28:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 20:28:37 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 12:28:37 +0800 Message-ID: Subject: Re: USB stack To: Warner Losh Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:28:39 -0000 On Sun, Jan 7, 2018 at 12:25 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh wrote: >> >>> >>> >>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme >>> wrote: >>> >>>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme >>>> wrote: >>>> >>>> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or >>>> greater >>>> > and the topic gets derailed...? >>>> > >>>> > Are you guys saying that 7-8MB/s is USB speeds? >>>> > >>>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>>> > wrote: >>>> > >>>> >> >>>> >> >>>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn >>>> wrote: >>>> >> >> What is an "LG v30"? >>>> >> >> >>>> >> > It's a smartphone from LG and only supports USB2 speed. The >>>> reported >>>> >> > transfer rate is no big surprise. >>>> >> >>>> >> OK thanks. >>>> >> >>>> >> -- >>>> >> Daniel O'Connor >>>> >> "The nice thing about standards is that there >>>> >> are so many of them to choose from." >>>> >> -- Andrew Tanenbaum >>>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> >> >>>> >> >>>> > Actually, this post: https://forums.freebsd.org/threads/41041/ >>>> >>>> on the forum from 2013 pretty well describes what I am experiencing wh= en >>>> moving data over USB. >>>> >>>> I have no problems hitting very high read/ write speeds using dd or >>>> downloading something but copying by USB is excruciatingly slow. >>>> >>>> Why is that? >>> >>> >>> If you are copying a boatload of tiny files to USB there's two issues. >>> Both our UFS and MSDOS don't do well in this case. Second, for flash ba= sed >>> USB thumbdrives, most of them have horrible write performance unless yo= u >>> buy quality drives... >>> >>> Warner >>> >> I would consider this=EF=BC=9A https://www.samsung.com/ >> us/computing/memory-storage/memory-cards/micro-sd-evo-256gb- >> memory-card-w-adapter-mb-mc256da-am/ >> 256GB Samsung microsd card quality. >> > > At most, you can get 90MB/s read/write on this card. What are you seeing? > And how are you copying? > > Warner > I use the phone, LG V30 to record basically ungraded RAW video files to the microsd card; they are large files. I transfer them to my computer copy a backup to the 1TB driver; then do edits/ color grading, etc in blender, then I transfer the finished to another 1TB hdd for backup as well. From owner-freebsd-current@freebsd.org Sun Jan 7 04:17:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16D2BE6561C for ; Sun, 7 Jan 2018 04:17:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE75174625 for ; Sun, 7 Jan 2018 04:17:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id f190so5883499ita.5 for ; Sat, 06 Jan 2018 20:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XFNYqr1z4xB97DcVxfmpf/B4L/aYbWRTvoiCYAbF6eY=; b=Mdj3tb8SOsRgv2Luppd7vQlZbboN/JDmthzcDVzSl1ogi0amMS2hWV8HQLEOdLRVs2 K6uoOHjGF9LMOafwFZw8IxawqaFph/GPRMjDZauK+EFczO9JNDfktn1BDceWWkodp8Lp W6kArOMXeAJ78B4ocMhvoX27cZXcnStluo0fs7VnDfJSPAlmOWSLQDOHw6NKQu3g+Qce W83Y3prV2HSF8cH4H8j5sjhdYf0/GjBVWFj54s3pt4KBIjJoAzv1RngZayZ33+V6475V fN7aAQ37xwz3r9hSRPpRg4DTbiOLE2WuGxBAyfFP7xILEtLtzWzf+DE37f6YfmnXOlhZ UloA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XFNYqr1z4xB97DcVxfmpf/B4L/aYbWRTvoiCYAbF6eY=; b=jUS+jvTNFVH1y7afF7Ai4AZX4wyew4Y8LqWgfLr6DYMD1x5Av/KW9EIxIgd7p8auru B7R+6qFvNv88SV8YEjtaNTHoLhXbMaWLbnqJNvifOCQKoPLqNBREhYEyo0LLF51utRZQ kidnkyDXUg92uhdKpGMlDM1cdAJvCEY074R6jt6mtXRHauf+ViMuda/ZOvck1Dxjql4R /nZHogZ3+iPMcSc4M6yCKd9rYBLmAWsQYaPjACxvANOKAGUJqIMpOOUagohnsnjQ2Gbt HDk8JpJDk8O/hsKOWpXhuDGOAoWGV7eJHlD5HdFePluhIen2nVWW5RGCqeqyiOxoN215 uTfA== X-Gm-Message-State: AKGB3mLS2EOiTQSOyg9EwlNc8P6h8T2hdIiGrblcdCtUAZYci/HhuB4F pMgqRSSTnlOSTD3NyVKuqTXA+2wRJ6SoxET0aQkD0Q== X-Google-Smtp-Source: ACJfBosjxvBiVAaaheNcBpkvqO6Zn8Gd4k3xZKIpXDqNNnig6HqiiDQ9Cf5vc/nvYAwk9QLx2df22+n6Ob0Ja+yWZvY= X-Received: by 10.36.104.210 with SMTP id v201mr7054179itb.64.1515298674904; Sat, 06 Jan 2018 20:17:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 20:17:54 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: Warner Losh Date: Sat, 6 Jan 2018 21:17:54 -0700 X-Google-Sender-Auth: OeOtJ-7gAYC4dAH_J3pMyU9diEs Message-ID: Subject: Re: USB stack To: blubee blubeeme Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:17:56 -0000 On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme wrote: > On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme > wrote: > > > I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater > > and the topic gets derailed...? > > > > Are you guys saying that 7-8MB/s is USB speeds? > > > > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > > wrote: > > > >> > >> > >> > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: > >> >> What is an "LG v30"? > >> >> > >> > It's a smartphone from LG and only supports USB2 speed. The reported > >> > transfer rate is no big surprise. > >> > >> OK thanks. > >> > >> -- > >> Daniel O'Connor > >> "The nice thing about standards is that there > >> are so many of them to choose from." > >> -- Andrew Tanenbaum > >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > >> > >> > > Actually, this post: https://forums.freebsd.org/threads/41041/ > > on the forum from 2013 pretty well describes what I am experiencing when > moving data over USB. > > I have no problems hitting very high read/ write speeds using dd or > downloading something but copying by USB is excruciatingly slow. > > Why is that? If you are copying a boatload of tiny files to USB there's two issues. Both our UFS and MSDOS don't do well in this case. Second, for flash based USB thumbdrives, most of them have horrible write performance unless you buy quality drives... Warner From owner-freebsd-current@freebsd.org Sun Jan 7 04:25:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 105F8E662CA for ; Sun, 7 Jan 2018 04:25:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C402774E1E for ; Sun, 7 Jan 2018 04:25:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id x42so2154489ita.4 for ; Sat, 06 Jan 2018 20:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6EUH7rSlaI24Sih1U28FvFx5NyBVfzYJuT/RfT/ShRc=; b=2QX7gN1bD+0Tk04bIUNRQGF0XPStj1Z2TMgg2sKPPBf1CvaSOh6ugia19m1dA+qhm4 4owXJ7BXhWN75dEUl/hRWx2yVNMa6i7v+2H/5fgVYAyrb5O6WCq2OqW4eRxLIdXAx0Vf 1HVdlIbJk2MHbDE4SoMeeoBJrFjiOJq+x6vbpg9puWhe8nvxOXtv2u70s0/cu/oKzU4x DNSxdmQadmMjw5TvvuchrfO6wZaoHAJ0z75HfSv33IoCWekUyut04/GqRhUcqDljgSEZ kBN/CiPMjoXxBY7Qrtvfn9+4QXc1OQ2AD46QSCrbikD19tOOmIyQQBjRix5JzQRUZWWZ ynZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6EUH7rSlaI24Sih1U28FvFx5NyBVfzYJuT/RfT/ShRc=; b=W+ogFqfjZxpdIHuTzfQCXgS1bfsxCEVpNuJsLjRANU9CXmb2RwpQohaWNcQouIUzWB ZGrqPkaLTszJIhz7+VoJbyBAUTvxoveofOZwVF9+vxo0GeqvVWKC5o+2553HSJMw7ZAm Om9ZRQfeslHegu2fBTl+skN471gV1wH6iMNVKnLmlrzBpm4QJo1iiY5m4sHovYhMwUxY 10PFCBHsvkivwafEVC5Ax8GUretubfRlh1LOETvonbc4ciKbIsAbSwJwXLzdDYxplvRx Vh+PwEjnTu6G7MLpk7F8FtCQhZf/syMdnJWlMMZOACJ1Fs0pNao9MsVsUmDAL1b1E1Vs FoZg== X-Gm-Message-State: AKGB3mJz0FK+GZDgjaL7KcsMgRNQ+Ik6GBFIpWRImIsZURTBr61rXdg4 7v24Co6zgEu18w7K8KwnfD6w7wC2UVCT1pE9V3UBKQ== X-Google-Smtp-Source: ACJfBosPshMXcwQy6XeokhHh5wrZugGsroXP+a+R1CvW+84YQE5yaOx4V69ROlOI4wtE8zv241sPX4gq9AkVIP/od8w= X-Received: by 10.36.104.210 with SMTP id v201mr7061016itb.64.1515299107089; Sat, 06 Jan 2018 20:25:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sat, 6 Jan 2018 20:25:06 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: Warner Losh Date: Sat, 6 Jan 2018 21:25:06 -0700 X-Google-Sender-Auth: 0kQD_ykm1qouBa31CGWsuWRAcQc Message-ID: Subject: Re: USB stack To: blubee blubeeme Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:25:08 -0000 On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme wrote= : > > > On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh wrote: > >> >> >> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme >> wrote: >> >>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme >>> wrote: >>> >>> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or >>> greater >>> > and the topic gets derailed...? >>> > >>> > Are you guys saying that 7-8MB/s is USB speeds? >>> > >>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>> > wrote: >>> > >>> >> >>> >> >>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn >>> wrote: >>> >> >> What is an "LG v30"? >>> >> >> >>> >> > It's a smartphone from LG and only supports USB2 speed. The >>> reported >>> >> > transfer rate is no big surprise. >>> >> >>> >> OK thanks. >>> >> >>> >> -- >>> >> Daniel O'Connor >>> >> "The nice thing about standards is that there >>> >> are so many of them to choose from." >>> >> -- Andrew Tanenbaum >>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>> >> >>> >> >>> > Actually, this post: https://forums.freebsd.org/threads/41041/ >>> >>> on the forum from 2013 pretty well describes what I am experiencing whe= n >>> moving data over USB. >>> >>> I have no problems hitting very high read/ write speeds using dd or >>> downloading something but copying by USB is excruciatingly slow. >>> >>> Why is that? >> >> >> If you are copying a boatload of tiny files to USB there's two issues. >> Both our UFS and MSDOS don't do well in this case. Second, for flash bas= ed >> USB thumbdrives, most of them have horrible write performance unless you >> buy quality drives... >> >> Warner >> > I would consider this=EF=BC=9A https://www.samsung.com/ > us/computing/memory-storage/memory-cards/micro-sd-evo- > 256gb-memory-card-w-adapter-mb-mc256da-am/ > 256GB Samsung microsd card quality. > At most, you can get 90MB/s read/write on this card. What are you seeing? And how are you copying? Warner From owner-freebsd-current@freebsd.org Sun Jan 7 04:18:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27A30E656E2 for ; Sun, 7 Jan 2018 04:18:19 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB60E746C3 for ; Sun, 7 Jan 2018 04:18:18 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id z130so9695699ioe.13 for ; Sat, 06 Jan 2018 20:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/DNf43c4HgFnZUZSDiXDKCJgMVRx6SBkOVDz6kT3Bm4=; b=VSzG1CGjGwx0v41wUn+t/VrKBGO7Ee7umjsOJnEkpysbkWCVMsyks7KZr5vvrcdHYh nFVukvyIvB7Ha+aBsWczbRhswdDyNqly5EpkMhFXJzVpjq0lj5Rdx5kb0nn0+cTzdCkR ZGhiI6nuhx+FPZurulNxtbOuBdkDDTMq7BhYje1ky6NXiykwFbv9xP6rdKlB7uLt9Rpw 1gANcMTJHDtSEbSpacuA4Lk9OJT/exXv+c36u2fN9nYloz519/YPyuKIBrvOBzwXiRnl TFNabTntei6yplVXaE4wHfjxYsCFa6tawYTIZCHIH52DevrNdHWvYwT9qafWdFN6qd9g Ivaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/DNf43c4HgFnZUZSDiXDKCJgMVRx6SBkOVDz6kT3Bm4=; b=P22ejCpFWI4L6laXlYkHdpz8TAMAoXSayNp2kHrqkILla9tEPyiR2/xV+odwI/GuLJ qwJp1fMjOvcjYFfidrG2PP+T/6hVN2TyY0F8on1oSiIgEcmfGrbdVzJbu+q5uKomY9ZF w9TQJR1MVusV5X4v0/rjbAeVGgjytKzQv7QK963INw/ajnXugGIBnwqfVz8DmNIry3SY EUuPkXHg3BJOxcMXdSoxKs5+XVNc8OSKnL5yGeMbOw5EaZ6wIrDlbZCzyCW0ZJe8Z53R nLYqpc4A5Z2tAEpWJqbEq8OJ8qKrZqaLSDoj6zevMfl3s1qX+u3te5lmF30f12kuxl9W 4Xzw== X-Gm-Message-State: AKwxytf86kjX3lhcgYIINxCIJtR4V6BFbXWCVfh3y2rBEVtSMoypd/OU 8jLU4Hz3j+Y9QH7NkY/B7MDTf13q4IuKBme+cCo= X-Google-Smtp-Source: ACJfBotNKFhjZTXnw8RDEgJj/A37n5cxWFBUt98YU36faF+gfW0F4nrpfiwe1v2f/ThGetL3IbBBCQG5At2ki5ZA+J0= X-Received: by 10.107.7.67 with SMTP id 64mr7452825ioh.296.1515298697614; Sat, 06 Jan 2018 20:18:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 20:18:17 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 12:18:17 +0800 Message-ID: Subject: Re: USB stack To: Warner Losh Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:18:19 -0000 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: 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 0xfffffe07c26336c0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:374 Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ /usr/src/sys/dev/md/md.c:952 Jan 7 12:06:08 blubee kernel: stack backtrace: Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at lockmgr_lock_fast_path+0x1ae Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at mdstart_vnode+0x442 Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at fork_trampoline+0xe Jan 7 12:06:15 blubee kernel: lock order reversal: Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3562 Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 Jan 7 12:06:15 blubee kernel: stack backtrace: Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at ufsdirhash_add+0x3d Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at ufs_direnter+0x459 Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at ufs_makeinode+0x613 Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at VOP_CREATE_APV+0xd3 Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at vn_open_cred+0x2ad Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at kern_openat+0x212 Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at Xfast_syscall+0xfb Is the slow transfers user error? From owner-freebsd-current@freebsd.org Sun Jan 7 04:20:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52BE6E65BB4 for ; Sun, 7 Jan 2018 04:20:58 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 302417496C for ; Sun, 7 Jan 2018 04:20:57 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id k18so9720849ioc.11 for ; Sat, 06 Jan 2018 20:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XlzE+/54OEb50f1ZDZkK7rXBX+JXT6QUtg7AER6EnRk=; b=tzyQFMmG5TT1JmJ0wxhcLKr9uH56jfjFUZ0T2NvZavx5ViZmVAheksPnucWQmnsXZn VAJNWbN5n+uY6NkUcVn9wsbgROkWAQwowTXTqX1lp52e5HESCEUOlfXpBP1bVExKqCvs CowTRvFu0cvD3rZU6DhTYa79x79TZGk1MgPsdmVgm/eFWK4F5vvs8VWUPithbyYEQxHE K422GyrOf5Q6HA7DOjfxfGIeC+BjZN8272qZYPlUumzF4Xy3CFuKByezQDwh86yyOhjN TvZA2hx2TMdN8EHOJ5fPANOAyK0vWpQHPZ7L/wfagfmh3U+LWqlPo7tOnARcFiKG/9T6 eOeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XlzE+/54OEb50f1ZDZkK7rXBX+JXT6QUtg7AER6EnRk=; b=MUgHE5SavC0sZeZjaWudeK7OI9Y1Yv7VRKysma3Klhdoi2Ex+CU79/wZ1lOEQIdn5j jGhnGXgq2OvhQ4keyhmmMLvaB5fXeZL8ZDMrY6RCxlVYKsSH2jGrA+IzcjbBxC8YQS7h wR5JpMkEoPSCrC/KxpOP3F3y8n4IDFbxzuk6as+PRnQ8O6vpveodDglM3uxjpuNTtlmJ Pn5Jreobj/j700PV12LgM+yuDZcA2L62kOqz7SZ4TQhOTChcvMs8qyNRsD9thgq20G9n V6k+1HEC1bodZIsk9TLyPRxvuTw9db5PrNH4rHmv3lKonVDQEy95qSK/yrTiPQfKDOL5 UfIg== X-Gm-Message-State: AKGB3mKh263pq5RakKKJoDuLG19KMRyNz7GHSRWe8Erlp0FrGjt/FddX Wj/E1ZKzxTyMkD1T49XfQy6GrDsC1zErwe8I3aQ= X-Google-Smtp-Source: ACJfBousAc4GrPJZqesWBMJbv+CU0jXSrUmhtx879XSGKvwVlb6xqTeeebEgnnWsojYyPidVo9JOF49B3zu3i+X5QDg= X-Received: by 10.107.34.147 with SMTP id i141mr7695553ioi.184.1515298856500; Sat, 06 Jan 2018 20:20:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 20:20:56 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 12:20:56 +0800 Message-ID: Subject: Re: USB stack To: Warner Losh Cc: "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 04:20:58 -0000 On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme > wrote: > >> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme >> wrote: >> >> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or great= er >> > and the topic gets derailed...? >> > >> > Are you guys saying that 7-8MB/s is USB speeds? >> > >> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >> > wrote: >> > >> >> >> >> >> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn >> wrote: >> >> >> What is an "LG v30"? >> >> >> >> >> > It's a smartphone from LG and only supports USB2 speed. The report= ed >> >> > transfer rate is no big surprise. >> >> >> >> OK thanks. >> >> >> >> -- >> >> Daniel O'Connor >> >> "The nice thing about standards is that there >> >> are so many of them to choose from." >> >> -- Andrew Tanenbaum >> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> >> >> >> > Actually, this post: https://forums.freebsd.org/threads/41041/ >> >> on the forum from 2013 pretty well describes what I am experiencing when >> moving data over USB. >> >> I have no problems hitting very high read/ write speeds using dd or >> downloading something but copying by USB is excruciatingly slow. >> >> Why is that? > > > If you are copying a boatload of tiny files to USB there's two issues. > Both our UFS and MSDOS don't do well in this case. Second, for flash base= d > USB thumbdrives, most of them have horrible write performance unless you > buy quality drives... > > Warner > I would consider this=EF=BC=9A https://www.samsung.com/us/computing/memory-storage/memory-cards/micro-sd-e= vo-256gb-memory-card-w-adapter-mb-mc256da-am/ 256GB Samsung microsd card quality. From owner-freebsd-current@freebsd.org Sun Jan 7 05:33:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5CEEE6A269 for ; Sun, 7 Jan 2018 05:33:00 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71CF9777F1 for ; Sun, 7 Jan 2018 05:32:59 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-70-98.dz.commufa.jp [124.18.70.98]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w075Wpt9001569 for ; Sun, 7 Jan 2018 14:32:51 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 7 Jan 2018 14:32:50 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: USB stack Message-Id: <20180107143250.65bcb7cb8d557e4b7f59504f@dec.sakura.ne.jp> In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> Organization: Junchoon corps X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 05:33:00 -0000 On Sun, 7 Jan 2018 12:25:17 +0800 blubee blubeeme wrote: > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh wrote: > > > > > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme > > wrote: > > > >> > >> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > >> > >>> > >>> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > >>> wrote: > >>> > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater > >>>> and the topic gets derailed...? > >>>> > >>> > >>> Yes, it does. > >>> > >>> > >>>> Are you guys saying that 7-8MB/s is USB speeds? > >>>> > >>> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've > >>> not tried USB3 with an SSD that can do more.... > >>> > >>> Warner > >>> > >>> > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > >>>> wrote: > >>>> > >>>> > > >>>> > > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn > >>>> wrote: > >>>> > >> What is an "LG v30"? > >>>> > >> > >>>> > > It's a smartphone from LG and only supports USB2 speed. The > >>>> reported > >>>> > > transfer rate is no big surprise. > >>>> > > >>>> > OK thanks. > >>>> > > >>>> > -- > >>>> > Daniel O'Connor > >>>> > "The nice thing about standards is that there > >>>> > are so many of them to choose from." > >>>> > -- Andrew Tanenbaum > >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f > >>>> reebsd.org" > >>>> > >>> > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > >> ------------------------------------------------------------------- > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > >> Jan 7 11:56:56 blubee kernel: umass0: >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > >> 0x0100 > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > >> lun 0 > >> Jan 7 11:56:56 blubee kernel: da0: Fixed Direct > >> Access SPC-4 SCSI device > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait (bufwait) > >> @ /usr/src/sys/vm/vm_pager.c:374 > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > >> /usr/src/sys/dev/md/md.c:952 > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > >> lockmgr_lock_fast_path+0x1ae > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > >> mdstart_vnode+0x442 > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > >> fork_trampoline+0xe > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait (bufwait) > >> @ /usr/src/sys/kern/vfs_bio.c:3562 > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash (dirhash) > >> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > >> ufsdirhash_add+0x3d > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at ufs_direnter+0x459 > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > >> ufs_makeinode+0x613 > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > >> VOP_CREATE_APV+0xd3 > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at vn_open_cred+0x2ad > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at kern_openat+0x212 > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > >> amd64_syscall+0x79b > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > >> Xfast_syscall+0xfb > >> > >> > >> Is the slow transfers user error? > >> > > > > It's likely due to the slow UFS issue... > > > > Warner > > > The Transcend ssd is formated ZFS, I use it as a backup. > > The microsd might suffer from what you say since it's formatted by Android > but I do not get these slow transfer speeds on other OS. > > so a quick roundup. > 1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds; > let's say that's because of the Android OS default format. > I only get these slow speeds on FreeBSD, why is that? Warner is asking "how are you copying" on another thread. How? Although it's over LAN, I experience slooooow copying using shells/fd to copy (1-2MB/s), while 10-60MB/s by /bin/cp. Not measured, but feeling alike for USB memstick (same file to same memstick, with at least one reboot between each copy). It shoud be said to other filers, which doesn't call /bin/cp internally or does just what /bin/cp does. As for USB memsticks, I had a problematic one, which caused plenty of errors, maybe by mismatched quirks. It worked but very slow, sometimes suddenly disappeares, although it claimed 90MB/s capable. :-( > > 2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above; > are the slow speeds user error or something else? > > @Warner Losh > what was your setup where you were able to transfer 23-75MB/s to your USB > device? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jan 7 05:44:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F955E6B122 for ; Sun, 7 Jan 2018 05:44:20 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F514780C3 for ; Sun, 7 Jan 2018 05:44:20 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id n14so9787732iob.4 for ; Sat, 06 Jan 2018 21:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZHa8grf9q3ZxprOFMI4RgMlJQdN9zIM84bDu3UEPsuw=; b=Premk0jFcxiSpR8dkyJl8My04UgZK7BrnCvWRdWXTYgwpda6DxAWR2hesCSyb6AWXh bT3CYPscJfvtqeAILuSR2iI+Ek70yx30Ok1PHhXD2h2jq9vkG3VJmeYA7uLHpaQ8YYiC AIoAHqQsI6s2wZAwewhiISLUbBKSMa8VKksHe5PPBpTrynNqYIG04vgr6wfE1qFwJPnL 8uFzL1pATa6scXn6CEnaEYf2eOXUtmJC6+piTcdJidJ5ULIdEmeiPBIOcS271rh1D0rF fx+9bk8XfJzfq/XkAoqXUNaVtp9WHek6JR9wVeKlVKtAqGDAm7htIkxaVzrMunnq1fQx LDnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZHa8grf9q3ZxprOFMI4RgMlJQdN9zIM84bDu3UEPsuw=; b=QD2DDQZMBgQeBJlCx9BqjkdLq6CAkh74sYz4nB/Es6LYzGPZ/oJwvsWacO0iF9Cwvp fraNne1KHIagdMtt4sYUsceo4R9KE0JN9gA3OUT3aL6xiKezIZGGTOCaG0TrDkjPiAN1 aMdaZcV4xELiOaHoOCz+xpLlvKNprrPYTfs232hSpGFChMG8W8ao8/1tV07+ZxelrwbV TqFKZuk8W1aNyYi/0J1puWQWB0udaD2+naCwRLHii8IIhaTpOjsLlTltqHFSUcXYfOR+ LCFoqCUX2Tcyl5VIzsociGuaS9G96v8y8Z/vVEV6zR6KDT6fDghVTgZg31lJYZSt0ldN 6qKw== X-Gm-Message-State: AKwxytfVLMRcbp8VZFbK5i4u0DgG6MB1sLiQ0PTh3kpxz4guf4Rxu9yI bsdTB85HmMlVYV3oUIJfRMMB4DU/aj5Y4LJfaOXl9A== X-Google-Smtp-Source: ACJfBotm/Rf651cJqL66lKPRvHYTiyIFpyz5cbjXyaRy/RhTDn1SctRWEk0zrxz0YXPe+IL1gKdg2GnwL4wtJZQ0Grs= X-Received: by 10.107.16.79 with SMTP id y76mr7542615ioi.213.1515303859288; Sat, 06 Jan 2018 21:44:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sat, 6 Jan 2018 21:44:18 -0800 (PST) In-Reply-To: <20180107143250.65bcb7cb8d557e4b7f59504f@dec.sakura.ne.jp> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <20180107143250.65bcb7cb8d557e4b7f59504f@dec.sakura.ne.jp> From: blubee blubeeme Date: Sun, 7 Jan 2018 13:44:18 +0800 Message-ID: Subject: Re: USB stack To: Tomoaki AOKI Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 05:44:20 -0000 On Sun, Jan 7, 2018 at 1:32 PM, Tomoaki AOKI wrote: > On Sun, 7 Jan 2018 12:25:17 +0800 > blubee blubeeme wrote: > > > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh wrote: > > > > > > > > > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme > > > wrote: > > > > > >> > > >> > > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > > >> > > >>> > > >>> > > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > > > >>> wrote: > > >>> > > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or > greater > > >>>> and the topic gets derailed...? > > >>>> > > >>> > > >>> Yes, it does. > > >>> > > >>> > > >>>> Are you guys saying that 7-8MB/s is USB speeds? > > >>>> > > >>> > > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at > about > > >>> 75MB/s (the fastest it will do), which isn't possible with USB > 2.0... I've > > >>> not tried USB3 with an SSD that can do more.... > > >>> > > >>> Warner > > >>> > > >>> > > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel < > darius@dons.net.au> > > >>>> wrote: > > >>>> > > >>>> > > > >>>> > > > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn > > >>>> wrote: > > >>>> > >> What is an "LG v30"? > > >>>> > >> > > >>>> > > It's a smartphone from LG and only supports USB2 speed. The > > >>>> reported > > >>>> > > transfer rate is no big surprise. > > >>>> > > > >>>> > OK thanks. > > >>>> > > > >>>> > -- > > >>>> > Daniel O'Connor > > >>>> > "The nice thing about standards is that there > > >>>> > are so many of them to choose from." > > >>>> > -- Andrew Tanenbaum > > >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F > CE8C > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > >>>> freebsd-current@freebsd.org mailing list > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f > > >>>> reebsd.org" > > >>>> > > >>> > > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > > >> ------------------------------------------------------------------- > > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > > >> Jan 7 11:56:56 blubee kernel: umass0: > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > > >> 0x0100 > > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > > >> lun 0 > > >> Jan 7 11:56:56 blubee kernel: da0: Fixed > Direct > > >> Access SPC-4 SCSI device > > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > sectors) > > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait > (bufwait) > > >> @ /usr/src/sys/vm/vm_pager.c:374 > > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > > >> /usr/src/sys/dev/md/md.c:952 > > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > > >> lockmgr_lock_fast_path+0x1ae > > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at > VOP_LOCK1_APV+0xd9 > > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > > >> mdstart_vnode+0x442 > > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at > md_kthread+0x1fe > > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > > >> fork_trampoline+0xe > > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait > (bufwait) > > >> @ /usr/src/sys/kern/vfs_bio.c:3562 > > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash > (dirhash) > > >> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > > >> ufsdirhash_add+0x3d > > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at > ufs_direnter+0x459 > > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > > >> ufs_makeinode+0x613 > > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at > ufs_create+0x34 > > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > > >> VOP_CREATE_APV+0xd3 > > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at > vn_open_cred+0x2ad > > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at > kern_openat+0x212 > > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > > >> amd64_syscall+0x79b > > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > > >> Xfast_syscall+0xfb > > >> > > >> > > >> Is the slow transfers user error? > > >> > > > > > > It's likely due to the slow UFS issue... > > > > > > Warner > > > > > The Transcend ssd is formated ZFS, I use it as a backup. > > > > The microsd might suffer from what you say since it's formatted by > Android > > but I do not get these slow transfer speeds on other OS. > > > > so a quick roundup. > > 1) 256GB Samsung microsd card gets 7-8MB/s transfer speeds; > > let's say that's because of the Android OS default format. > > I only get these slow speeds on FreeBSD, why is that? > > Warner is asking "how are you copying" on another thread. How? > Although it's over LAN, I experience slooooow copying using shells/fd > to copy (1-2MB/s), while 10-60MB/s by /bin/cp. > Not measured, but feeling alike for USB memstick (same file to same > memstick, with at least one reboot between each copy). > It shoud be said to other filers, which doesn't call /bin/cp internally > or does just what /bin/cp does. > > As for USB memsticks, I had a problematic one, which caused plenty of > errors, maybe by mismatched quirks. It worked but very slow, sometimes > suddenly disappeares, although it claimed 90MB/s capable. :-( > > > > > 2) 1TB Transcend SSD formatted to ZFS I pasted the dmesg log above; > > are the slow speeds user error or something else? > > > > @Warner Losh > > what was your setup where you were able to transfer 23-75MB/s to your USB > > device? > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > > > -- > Tomoaki AOKI > _______________________________________________ > 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 copy using /bin/cp to and from /mnt after I mount said device. The devices are; LG v30 with 256GB Samsung microsd 1TB Trascend SSD Both were linked earlier in this thread. so, any reason why i'm getting these slow speeds? I asked what was his setup to get 23-75MB/s but no response to that question as of yet, why? From owner-freebsd-current@freebsd.org Sun Jan 7 08:27:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6EDBE5E7EA for ; Sun, 7 Jan 2018 08:27:20 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 687B97C651 for ; Sun, 7 Jan 2018 08:27:20 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id o76so2692967lfi.10 for ; Sun, 07 Jan 2018 00:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=avvvbJLGD9BGsl87+nzZRZN9AZI8VCZPYW0JF/Y+PR0=; b=A98XYwX7Hrv9gYg3xF6ur2S+ZwZ7L4xQrX9xF3aF3k/LaWxgc3FyFE3h0J/D7p5t5X V8fOlYxPArHMQ6USqpTpxnKoU+ambhoM7rPHlpLZ0ie4hyCcNQbhqEZHzKDQjX6AbiNm ZHqzY67bWHFeuq+ybnNRDZJg6hjQqBabpKGsgRFIGiVb0s85ZcJh9Ed6G0XXTr/X7626 rQLa0vKki8PHcGPra4j+8iZiuUa03Zzpgx3NYh2Vq/58M2mynRBFZ4TX8QKPdec2l270 xV/5fGhdMDxM8urzF/YA1GtR/VB8r0UC9Is4oSIx4DpEq9NrghcNAoglviaVG5piydRx JU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=avvvbJLGD9BGsl87+nzZRZN9AZI8VCZPYW0JF/Y+PR0=; b=oCGduvYoxmE7jb90bGXjGfG1UBSmpkF/OoUaZgP6VDEs6lfdZy6TieGNhs4Z2RytKX ktkN7GECsr8uNcKmut2pqAEXM7X0vi1QYLWOmF5owmkoKvcj1lgzCQhAzkMP8WUOBYxM 8Y0VCQeEvrHw9b50WYrww3WG4uPFObhvFfoCTLqrfI3dHfFGxnTABFZzD7f1Edzrqpis iqSqOXaX2Ddfk0nBKiz1X/KwSwPhBg+m9Lb/ImY/cp3XG0sTHULjYXM7fWogkCFjam7L hev/BMsH0RZ4P22FOTe7QxkVBCAIdqNaG+snX0GB/uuPuDA41afUBy4+g/R7mgKgM4eg 8k6w== X-Gm-Message-State: AKGB3mI4xTMVZKPgcpbhn2Gf8DsEM4oioRUS2rCFyulOGmAPXqTmYWbb pUg5rpDyzbcBqP62erbKgefDunEyq7MJUQwA/ABY7Q== X-Google-Smtp-Source: ACJfBosCn9nil0aSNCqWvVt+b7A7whmDi5uT5CWDsp9mllU2e1xaVF2Bq/iJqbWgLnGHqwXLdN/QT9KiSFo9NPfeEHM= X-Received: by 10.46.50.19 with SMTP id y19mr5246833ljy.113.1515313637590; Sun, 07 Jan 2018 00:27:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Sun, 7 Jan 2018 00:27:16 -0800 (PST) Received: by 10.25.163.207 with HTTP; Sun, 7 Jan 2018 00:27:16 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: Freddie Cash Date: Sun, 7 Jan 2018 00:27:16 -0800 Message-ID: Subject: Fwd: Re: USB stack To: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 08:27:21 -0000 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 From owner-freebsd-current@freebsd.org Sun Jan 7 08:36:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B09AE5F0B5 for ; Sun, 7 Jan 2018 08:36:35 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5CA7CBCE for ; Sun, 7 Jan 2018 08:36:35 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x232.google.com with SMTP id x42so2402536ita.4 for ; Sun, 07 Jan 2018 00:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pdeaqKbsDYnxCA81zuzeyWUZ7ztfVbTt+WwRqp6ih64=; b=oDEB5meK7DUlhK9ea9Pi4fU2PxdNg/sm5hwk8TJHs2R9aGtbpqQutgrpL5kK6ueYuC Gr/wxiQ7p9RnHWZ7F6hmu1ltuE4mwnu2LKCjL+NouEzsVYDXhRJEswAq358f1nWgmGzL G5kflu5xgeCyLPXbJrJ093ZIvNJmXviwD+YaYSX7+CzcJjRruknxScuNpj11vM9yK558 ZxV/REaZspXcAQma8HtOGFNr9VeO8zEyIX/MiOuPIWVNqqrL106BdyGrqeo7RnRKdpYH ARzl/cQIEnqFUMnpSrcc5m48iZlbdaeqxy/FV9HsurAuziHhpAu9O8ZqUI3XbkLpVdH2 T5lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pdeaqKbsDYnxCA81zuzeyWUZ7ztfVbTt+WwRqp6ih64=; b=dy+GgzASwMoIy2Js5B9V1AASPQ0JjCq0X5kzxldYPHVgNCOA6SeFICA5YWvIpJY2ka ly1L+k5+3HgUxIpJK7TgMcu99I/LYnTYPpb/OObJeeuKkbpPcvR8tEo5CjLB8wCMCtZ3 Re1F+TB+QMgZM3kSBeovT2jMFa/Ly8CVk1+MOYSjasYv0WS1bOxS+ke+6dnMCxNEmlTg NbK6HLwWTH6mggNA2L1vTd0gDCc3w4TTQUO1IZk8MLpBBEsxWqph7jTbTiPvIbK3+OjV 40pAs8ijyfkFr//r1DOczo6M5W/uZT1bK4039aj6P6JfRRIk1atUZF2XKoni0yNclKtK 5Q2g== X-Gm-Message-State: AKGB3mLpHZR1niRxmwtUzrFDQZs0vJLIwbhmkQ5FIAI55viKgzc0b17E 6sm654x0qOujGXBts/N2herMWpAGkw0V8tiDVwU= X-Google-Smtp-Source: ACJfBovQQue1Q1Ez1wofQgkDoSqb2gO/Xlp5i/VFIqCKi8l/evGEXZQzi+FLSKd2+nfOam2KRwOSCT9eH4aPA3JUXZI= X-Received: by 10.36.110.71 with SMTP id w68mr7527619itc.119.1515314194265; Sun, 07 Jan 2018 00:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 00:36:33 -0800 (PST) In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> From: blubee blubeeme Date: Sun, 7 Jan 2018 16:36:33 +0800 Message-ID: Subject: Re: Re: USB stack To: Freddie Cash Cc: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 08:36:35 -0000 On Sun, Jan 7, 2018 at 4:27 PM, Freddie Cash wrote: > 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-unsubscribe@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 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 pastebin: https://pastebin.com/66NZEFtp Anything else that I can provide? From owner-freebsd-current@freebsd.org Sun Jan 7 09:36:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95F71E62346 for ; Sun, 7 Jan 2018 09:36:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-149.reflexion.net [208.70.210.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5ACFB7EBCC for ; Sun, 7 Jan 2018 09:36:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26540 invoked from network); 7 Jan 2018 09:35:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 09:35:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 04:35:53 -0500 (EST) Received: (qmail 9478 invoked from network); 7 Jan 2018 09:35:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 09:35:53 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F3817EC8BF3; Sun, 7 Jan 2018 01:35:52 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack Message-Id: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> Date: Sun, 7 Jan 2018 01:35:52 -0800 To: blubee blubeeme , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 09:36:01 -0000 blubee blubeeme gurenchan at gmail.com wrote on Wed Jan 3 10:31:56 UTC 2018 : > Does FreeBSD current USB stack support usb >=3D 2.0 devices? >=20 > 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. =20 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/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 255 255 5501 1.9 0 0 0.0 0 0 = 0.0 48.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 64 426 1 32 221.4 425 6287 140.4 0 0 = 0.0 62.9| da4 Note that the read kBps + write kBps means around 11MiByte/s for r+w. (There is only one USB connection at the RPi2B V1.1 here, not multiple, independent channels.) dT: 1.007s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 393 393 5295 1.3 0 0 0.0 0 0 = 0.0 50.7| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 46 102 2 64 2.9 100 2101 116.9 0 0 = 0.0 19.5| da4 The above last shows a period with around 7 MiBytes/s for r+w. dT: 1.007s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 16 245 245 9761 37.4 0 0 0.0 0 0 = 0.0 77.4| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 28 481 0 0 0.0 481 10809 95.1 0 0 = 0.0 93.7| da4 That last shows a period with around 20 MiBytes/s for r+w. (Probably copying fewer, bigger files at the time.) This might be around 8 MiBytes/s being written (mean rate overall for the copy). Example high end machine copying /usr/src/ to fast USB 3.0 SSD stick over USB 3.0, all UFS 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/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 6519 6519 103339 0.1 0 0 0.0 0 0 = 0.0 35.5| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 676 6635 0 0 0.0 6635 119898 43.6 0 0 = 0.0 43.0| da3 dT: 1.058s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 6839 6839 106968 0.1 0 0 0.0 0 0 = 0.0 34.7| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1 6967 0 0 0.0 6967 133410 42.4 0 0 = 0.0 46.1| da3 In this context there are 2 independent channels and reading from one and writing from the other can potentially happen at the same time. Vastly faster than 8 MiBytes/s mean rate for writes. Example high end machine copying /usr/src/ from and to fast USB 3.0 SSD sticks over USB 3.0, all UFS file system based: Ryzen Threadripper 1950X Running FreeBSD under Hyper-V under Windows 10 Pro USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection (UFS) Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection = (UFS) (These are Hyper-V "Physical disk drive" bindings, not NTFS files used as a virtual file system.) mount -o noatime in use for both. UFS file systems. soft-updates. cp -ax /mnt/usr/src /media/root/srccpy_test gstat -pd outputs, a couple of examples: dT: 1.008s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 2388 2388 36317 0.3 0 0 0.0 0 0 = 0.0 80.5| da3 0 2197 0 0 0.0 2197 38206 35.7 0 0 = 0.0 14.8| da4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 2443 2443 44537 0.3 0 0 0.0 0 0 = 0.0 82.5| da3 0 2309 0 0 0.0 2309 51142 36.0 0 0 = 0.0 18.7| da4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 2664 2664 65516 0.3 0 0 0.0 0 0 = 0.0 82.8| da3 0 2932 0 0 0.0 2932 84290 34.5 0 0 = 0.0 32.2| da4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 dT: 1.047s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 2542 2542 28571 0.3 0 0 0.0 0 0 = 0.0 77.7| da3 778 1803 13 428 0.4 1789 15985 27.8 0 0 = 0.0 8.0| da4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 I doubt that this has independent channels at all stages. Faster than 8 MiBytes/s mean rate for writes. Example high end machine copying /usr/src/ from and to fast USB 3.0 SSD sticks over USB 2.0, all UFS file system based: Ryzen Threadripper 1950X Running FreeBSD under Hyper-V under Windows 10 Pro USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection (UFS) Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection = (UFS) (These are Hyper-V "Physical disk drive" bindings, not NTFS files used as a virtual file system.) mount -o noatime in use for both. UFS file systems. soft-updates. cp -ax /mnt/usr/src /media/root/srccpy_test gstat -pd outputs, a couple of examples: dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 812 812 10487 0.8 0 0 0.0 0 0 = 0.0 62.6| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 0 949 5 150 66.9 944 13853 229.0 0 0 = 0.0 48.6| da4 dT: 1.042s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 1093 1093 12903 0.7 0 0 0.0 0 0 = 0.0 71.5| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 180 1003 8 246 94.9 996 9443 242.7 0 0 = 0.0 35.9| da4 dT: 1.068s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 1 617 617 15973 1.4 0 0 0.0 0 0 = 0.0 87.4| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1 1147 2 60 49.2 1145 17220 187.0 0 0 = 0.0 78.1| da4 Still solidly more than 8 MiBytes/s being written (mean rate). Having a few large files to copy instead should normally be faster in each of the earlier example contexts. But no hard drives or flash drives were involved: all SSDs of one form or another. Hard drive properties and file system fragmentation could make things much slower by comparison. Flash drives also can have issues. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 10:09:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45975E63BE8 for ; Sun, 7 Jan 2018 10:09:09 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C3BF7FD09 for ; Sun, 7 Jan 2018 10:09:09 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x235.google.com with SMTP id x67so10053650ioi.9 for ; Sun, 07 Jan 2018 02:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5X6+zgXN45nOLdC0xvvVfSGWyYwB7Fsp7HlessQGOBE=; b=Jx2VrvP4CuHzgjWLDwdY+FbEDUGvfqPSGhYQUDxqO4+nJkjLZzlViOWU0aWk1oIzbn LA+OosESzl+4TvFI4GX0ySGuhMGLENrQriGac4U5MmdORgDtIPCzEZHdiH2HrDQvlpgl 0xHPKEDCUO1SphOryvXSo7Pu3+WEb05uQwCkluDUHXt3bc8/UgoTTrnMviemFmpUkmd8 u4HehRbqA/EuJiN5MoOEGQulQLwn1IaGVrPV91D8L3YfbMmVlb1RKpEhOttAy+HvuFPC 3OsE6+2vSI5JPBjEViipnFjavXTJG4/0JO4LuY6qb0sn7DH5l+NHy6C5QMUeOk7JgFIS PkbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5X6+zgXN45nOLdC0xvvVfSGWyYwB7Fsp7HlessQGOBE=; b=Q99MH3xYWWOjBWtDaHwTcUw61qTQuau4ru7ue+vz4GW0GLDDx5OpxxN1dN1bx3G+fn WlraZVTGJNMLYD1UUmj+aeYqdFFi24Nso1nF7PWbSU2JufJcVHjnVznAcaJQcwTvwjUO lLokrbl9tp47dWxHqFpCJxeqOeRvU9pUy6XkewlYqDhJC7Bc3M9Norku6J2SKLsteOer tlj2MSWJxBDp8330vYo92MHYDRi6GkaXH52Mh+t+fI+fOhyvPxr+oJ8wMSGKetftpBjD nRVdSSC1w30PIBvkRvsrVc2F9TmGP7/6woXfbq5Zg2akktgVAw9KN8MHmUVCuwCjF7kv sioA== X-Gm-Message-State: AKwxytfKoUU4uHzSUSGpV6TCkUiDPF6m9yra3pG48W7X+iVnCwhTvoJD lh0mHbadgWV8G9iCjtgq6jukGswg4ODirmnFGIBUjJY5 X-Google-Smtp-Source: ACJfBou7VyhnOmRJpPTywk0nSLtFNiHdrAknLpgTubCkdP2vAxqbgaveee084pjY0OkbqGZwOegop6IupH7/z3F7WZE= X-Received: by 10.107.35.145 with SMTP id j139mr9026645ioj.153.1515319747923; Sun, 07 Jan 2018 02:09:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 02:09:07 -0800 (PST) In-Reply-To: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> From: blubee blubeeme Date: Sun, 7 Jan 2018 18:09:07 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 10:09:09 -0000 On Sun, Jan 7, 2018 at 5:35 PM, Mark Millard wrote: > blubee blubeeme gurenchan at gmail.com wrote on > Wed Jan 3 10:31:56 UTC 2018 : > > > Does FreeBSD current USB stack support usb >= 2.0 devices? > > > > Testing out the USB devices support I get about 7.2-7.8 megabytes per > > second which seems odd. > > > FreeBSD machine: Pine64+ 2GB? Ryzen Threadripper 1950X? . . .? > > It would help to specify the type of system and its > relevant properties (not just the processor). > > What independent channels are in use? Any? Or are > the source and destination on the same channel at > some stage? > > > I transferred about 30GB of audio from laptop > > The 30GB was on what type of device? Plugged in to what? > What file system? > ZFS file system on the main machine and the 1TB Transcend drive. I am not 100% sure what format android device is; I can look into this further but I've been testing on the Transcend device linked above in this list. > > > to Samsung usb class 10 usb > > device connected to LG v30. > > What file system? > Android 7.1 > > And in another message (indicating the other direction > of transfer compared to the above?): > I transfer from the phone to the computer. > > > I use the phone, LG V30 to record basically ungraded RAW video files to > the > > microsd card; they are large files. > > I transfer them to my computer copy a backup to the 1TB driver; then do > > edits/ color grading, etc in blender, > > then I transfer the finished to another 1TB hdd for backup as well. > > So the LG v30 was plugged in as a USB device, effectively > acting as a media reader/writer? What file system? > (It seems unlikely that the LG v30 would use a FreeBSD > native file system to record RAW video files.) > > > Going the other direction of providing some examples > of files copies for UFS. . . > > Note: These are based on head -r327485 with > non-debug kernel builds. > > > Example performance copying /usr/src/ : > (lots of small files on a fairly low-end FreeBSD > machine) > > RPi2B V1.1 (with USB 2.0) > One USB 3.0 powered hub (USB 2.0 compatible) with both: > > A) USB 3.0 SSD stick (USB 2.0 compatible) with the root file system > > B) 64 GB eMMC on a usdcard adapter, plugged into a USB 3.0 media > reader/writer (USB 2.0 compatible). > > mount -o noatime in use for (A) and (B). UFS file systems. > soft-updates enabled. > > cp -ax /usr/src/ /mnt/root/srccpy_test > > gstat -pd outputs, a few examples: > > dT: 1.007s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 255 255 5501 1.9 0 0 0.0 0 0 > 0.0 48.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 64 426 1 32 221.4 425 6287 140.4 0 0 > 0.0 62.9| da4 > > Note that the read kBps + write kBps means around 11MiByte/s for r+w. > (There is only one USB connection at the RPi2B V1.1 here, > not multiple, independent channels.) > This is an example copying [multiple small files] to the 1TB drive. ------------------------------------------------------------------------------------------------------------------ L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 547 290 35239 2.0 4 16 73.1 249 44291 93.7 48.8| nvd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99 21 333 0 0 0.0 333 36040 16.2 0 0 0.0 76.2| da1 ------------------------------------------------------------------------------------------------------------------ > > dT: 1.007s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 393 393 5295 1.3 0 0 0.0 0 0 > 0.0 50.7| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 46 102 2 64 2.9 100 2101 116.9 0 0 > 0.0 19.5| da4 > > The above last shows a period with around 7 MiBytes/s for r+w. > > dT: 1.007s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 16 245 245 9761 37.4 0 0 0.0 0 0 > 0.0 77.4| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 28 481 0 0 0.0 481 10809 95.1 0 0 > 0.0 93.7| da4 > > That last shows a period with around 20 MiBytes/s for r+w. > (Probably copying fewer, bigger files at the time.) > > This might be around 8 MiBytes/s being written (mean rate > overall for the copy). > > > Example high end machine copying /usr/src/ to > fast USB 3.0 SSD stick over USB 3.0, all UFS > 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/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 6519 6519 103339 0.1 0 0 0.0 0 0 > 0.0 35.5| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 676 6635 0 0 0.0 6635 119898 43.6 0 0 > 0.0 43.0| da3 > > dT: 1.058s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 6839 6839 106968 0.1 0 0 0.0 0 0 > 0.0 34.7| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1 6967 0 0 0.0 6967 133410 42.4 0 0 > 0.0 46.1| da3 > > In this context there are 2 independent channels > and reading from one and writing from the other > can potentially happen at the same time. > > Vastly faster than 8 MiBytes/s mean rate for writes. > > > Example high end machine copying /usr/src/ from > and to fast USB 3.0 SSD sticks over USB 3.0, all > UFS file system based: > > Ryzen Threadripper 1950X > Running FreeBSD under Hyper-V under Windows 10 Pro > USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection (UFS) > Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 3.0 connection > (UFS) > (These are Hyper-V "Physical disk drive" bindings, > not NTFS files used as a virtual file system.) > > mount -o noatime in use for both. UFS file systems. > soft-updates. > > cp -ax /mnt/usr/src /media/root/srccpy_test > > gstat -pd outputs, a couple of examples: > > dT: 1.008s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 2388 2388 36317 0.3 0 0 0.0 0 0 > 0.0 80.5| da3 > 0 2197 0 0 0.0 2197 38206 35.7 0 0 > 0.0 14.8| da4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 2443 2443 44537 0.3 0 0 0.0 0 0 > 0.0 82.5| da3 > 0 2309 0 0 0.0 2309 51142 36.0 0 0 > 0.0 18.7| da4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 2664 2664 65516 0.3 0 0 0.0 0 0 > 0.0 82.8| da3 > 0 2932 0 0 0.0 2932 84290 34.5 0 0 > 0.0 32.2| da4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > > dT: 1.047s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 2542 2542 28571 0.3 0 0 0.0 0 0 > 0.0 77.7| da3 > 778 1803 13 428 0.4 1789 15985 27.8 0 0 > 0.0 8.0| da4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > > I doubt that this has independent channels at > all stages. > > Faster than 8 MiBytes/s mean rate for writes. > > > > Example high end machine copying /usr/src/ from > and to fast USB 3.0 SSD sticks over USB 2.0, all > UFS file system based: > > Ryzen Threadripper 1950X > Running FreeBSD under Hyper-V under Windows 10 Pro > USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection (UFS) > Another USB 3.0 SSD stick (USB 2.0 compatible) on a USB 2.0 connection > (UFS) > (These are Hyper-V "Physical disk drive" bindings, > not NTFS files used as a virtual file system.) > > mount -o noatime in use for both. UFS file systems. > soft-updates. > > cp -ax /mnt/usr/src /media/root/srccpy_test > > gstat -pd outputs, a couple of examples: > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 812 812 10487 0.8 0 0 0.0 0 0 > 0.0 62.6| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 0 949 5 150 66.9 944 13853 229.0 0 0 > 0.0 48.6| da4 > > dT: 1.042s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 1093 1093 12903 0.7 0 0 0.0 0 0 > 0.0 71.5| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 180 1003 8 246 94.9 996 9443 242.7 0 0 > 0.0 35.9| da4 > > dT: 1.068s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 1 617 617 15973 1.4 0 0 0.0 0 0 > 0.0 87.4| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1 1147 2 60 49.2 1145 17220 187.0 0 0 > 0.0 78.1| da4 > > Still solidly more than 8 MiBytes/s being written (mean rate). > > > Having a few large files to copy instead should normally > be faster in each of the earlier example contexts. > > But no hard drives or flash drives were involved: all SSDs of > one form or another. Hard drive properties and file system > fragmentation could make things much slower by comparison. > Flash drives also can have issues. > > This is a larger file, not the largest but hey L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 4 0 0 0.0 2 8 0.0 0 0 0.0 0.1| nvd0 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| md99 128 982 1 32 58.8 981 125428 110.5 0 0 0.0 100.0| da1 === > Mark Millard > markmi at dsl-only.net > > I'm having a few issues with USB but just to simplify things; let's focus on speed for the device that I am currently using. Device spec: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 14:54:55 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x6a011558 chip=0x19108086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x6a011558 chip=0x19018086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16)' class = bridge subclass = PCI-PCI xhci0@pci0:0:20:0: class=0x0c0330 card=0x6a011558 chip=0xa12f8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H USB 3.0 xHCI Controller' class = serial bus subclass = USB none0@pci0:0:22:0: class=0x078000 card=0x6a011558 chip=0xa13a8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H CSME HECI' class = simple comms ahci0@pci0:0:23:0: class=0x010601 card=0x6a011558 chip=0xa1038086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H SATA Controller [AHCI mode]' class = mass storage subclass = SATA pcib2@pci0:0:28:0: class=0x060400 card=0x6a011558 chip=0xa1108086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:4: class=0x060400 card=0x6a011558 chip=0xa1148086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:6: class=0x060400 card=0x6a011558 chip=0xa1168086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:29:0: class=0x060400 card=0x6a011558 chip=0xa1188086 rev=0xf1 hdr=0x01 vendor = 'Intel Corporation' device = 'Sunrise Point-H PCI Express Root Port' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x6a011558 chip=0xa14e8086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H LPC Controller' class = bridge subclass = PCI-ISA none1@pci0:0:31:2: class=0x058000 card=0x6a011558 chip=0xa1218086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H PMC' class = memory hdac0@pci0:0:31:3: class=0x040300 card=0x6a021558 chip=0xa1708086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H HD Audio' class = multimedia subclass = HDA none2@pci0:0:31:4: class=0x0c0500 card=0x6a011558 chip=0xa1238086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H SMBus' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x6a021558 chip=0x1ba110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GP104M [GeForce GTX 1070 Mobile]' class = display subclass = VGA none3@pci0:109:0:0: class=0xff0000 card=0x6a011558 chip=0x528710ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8411B PCI Express Card Reader' re0@pci0:109:0:1: class=0x020000 card=0x6a011558 chip=0x816810ec rev=0x12 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet iwm0@pci0:110:0:0: class=0x028000 card=0x50108086 chip=0x095a8086 rev=0x48 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 7265' class = network nvme0@pci0:111:0:0: class=0x010802 card=0x390a8086 chip=0xf1a58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = mass storage subclass = NVM I have the 1TB Transcend drive that I linked before [ZFS format] I have a LG v30 with 256GB Samsung microsd. I do not transfer to multiple USB devices at any one time. I either transfer from phone [LG v30] to this machine; [pciconf output above] Transfer from this machine to 1TB USB device for backup. I never have two or more USB devices connected to this machine. From owner-freebsd-current@freebsd.org Sun Jan 7 10:44:26 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B962AE6526E for ; Sun, 7 Jan 2018 10:44:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-119.reflexion.net [208.70.210.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C47F80E5A for ; Sun, 7 Jan 2018 10:44:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22354 invoked from network); 7 Jan 2018 10:44:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 10:44:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 05:44:19 -0500 (EST) Received: (qmail 30795 invoked from network); 7 Jan 2018 10:44:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 10:44:19 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E5DEDEC8BF3; Sun, 7 Jan 2018 02:44:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: Date: Sun, 7 Jan 2018 02:44:18 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 10:44:26 -0000 [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 >=20 > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 4 0 0 0.0 2 8 0.0 0 0 = 0.0 0.1| nvd0 > 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| md99 > 128 982 1 32 58.8 981 125428 110.5 0 0 = 0.0 100.0| da1 . . . Note that almost complete lack of kBps near r/s but the large kBps near w/s. It appears that the file has been cached in RAM and is not being read from media at all. So this test is of a RAM to disk transfer, not disk to disk, as far as I can tell. You need to avoid re-reading the same file unless you dismount and remount between tests or some such. Or just use a different file not copied since booting (that file may or may not be a previous copy of the same file by content). See if you can get gstat -pd results that show both read kBps and write kBps figures. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 11:32:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78FF2E674D7 for ; Sun, 7 Jan 2018 11:32:13 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE59D823D9; Sun, 7 Jan 2018 11:32:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.181.255.64]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzKQf-1eug6D2cYj-014TxE; Sun, 07 Jan 2018 12:32:08 +0100 Date: Sun, 7 Jan 2018 12:31:34 +0100 From: "O. Hartmann" To: "O. Hartmann" Cc: Michael Tuexen , Warner Losh , FreeBSD CURRENT Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Message-ID: <20180107123201.19ea0fde@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/ZmNi6G2KhPSkwUp9=voe_7f"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:8uYr4Zuh0Ufb4//Yb4R8izn7r2WGeO+U9nwAoIpxNDLX9CIuFA6 h4eDlBfvDi3bhDQw5OqHZtdcoFQdzejI+DMMOhj/a72QZ9aFTFENjI0SdsRyP7wHmQdzaql 8Qz3uui0PyJ9uSPUp0z1q8XtpkMolvTx003kzO3B+EzWQvDEy0bZtdafzzxb4khIxMdLJjc Nkh0/5B3vx0SkbM3iMRtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TH6GYwudZ0k=:yqTRlAZw0wrg08Gqpe16w7 kyJn5AoRViZ3HgPlJjzug+/yYTdQgV5BNfYOQpSWhxa09wPHfd5ziXHSheZRUfqqbtaRINUU2 tVbXp6+UumYqoVMwgjmar3IpiCFsTek2VmLaajB72mmseXDTIN/+ujw2U3tVkhJEo5GH/le3y AwldE6HxnDC4AMvw5sV7+NzCMXu9DxoxZXnwjeK2129jhfl2gkXiJIIvAdnTKOei2xWocrDUk 52L/3GgDsVWSGtbmdfjbAl1joJvQNi5/Lwh9BMRZbMJ7k37YE5Q8Uu0BJjBfarjjITHwaZ3wb YByAQMDC36pVSo2UBhRy4aMpdeB16x9HKg7tl/oea2n12B9KA1dun9BH+XKGtvzRIVj8qR1q+ OvJWEU0wDIEPg5MWbwJii/tVIIf0pUTtFxDn3WKhUiwiTj+s0wgnsw+UIs/WxADvwN+cvyQ1l Dw6ONw3in4kTZ5VnN67PBe/ij5pQsed/W5O0CoIoPn+PUG8mBPi4nz0h45i3azgvQF/+j0DRQ EY/Vt8xmb+XF0EkV94jlFXTNMKfLZhmyxBgA0bNHdQoenOGD45tPLC2FkKvt8hCM/wPlZlvF/ lfvx0pcImlcPtRHvhiLRLacr4vJwzaAFjgzL6OwexvpZBCoYyYsVXA1vTi84Ez+zxl4reeNyI gH6jHhetQv3u5X6ec5gH0mpl3oKkiwSA8cSjP2ScEZwkUphSLPng2/Y56AisyXVoGaNNwXLwa 1+aEXDivOm8RmpLDrMh9T6M8GScRGVbjKgUGFDOiP19eL9zalJ0RrSHo0WrnADNbxoBqn2HHE CS49RioH4fDY6xX4mx2f4ZpGAmrZA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 11:32:13 -0000 --Sig_/ZmNi6G2KhPSkwUp9=voe_7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Thu, 4 Jan 2018 12:14:47 +0100 "O. Hartmann" schrieb: > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen wrote: >=20 > > > On 31. Dec 2017, at 02:45, Warner Losh wrote: > > >=20 > > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann = wrote: > > > =20 > > >> On most recent CURRENT I face the error shwon below on /tmp filesyst= em > > >> (UFS2) residing > > >> on a Samsung 850 Pro SSD: > > >>=20 > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d= 2a3 !=3D > > >> bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d= 2a3 > > >> !=3D bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d= 2a3 > > >> !=3D bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d= 2a3 > > >> !=3D bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d= 2a3 > > >> !=3D bp: 0xd9fba319 > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > >>=20 > > >> I've already formatted the /tmp filesystem, but obviously without any > > >> success. > > >>=20 > > >> Since I face such strange errors also on NanoBSD images dd'ed to SD = cards, > > >> I guess there > > >> is something fishy ... =20 > > >=20 > > >=20 > > > It indicates a problem. We've seen these 'corruptions' on data in mot= ion at > > > work, but I hacked fsck to report checksum mismatches (it silently co= rrects > > > them today) and we've not seen any mismatch when we unmount and fsck = the > > > filesystem. =20 > > Not sure this helps: But we have seen this also after system panics > > when having soft update journaling enabled. Having soft update journali= ng > > 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. > >=20 > > You can check using tunefs -p devname if soft update journaling is enab= led or > > not. =20 >=20 > 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" incl= uding the /cfg partition. The problem occured even when having overwritten the SD card wit= h a new image. The problem went away once I unmounted /cfg and reformatted via newfs. Afte= r that, I did not see any faults again! I have no explanation for this behaviour except t= he 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 did= n't formatted it as I said - I confused the partition in question with another one. The p= artition has been created and formatted months ago under CURRENT. In single user mode, I reformatted the partition again - with journaling an= d softupdates enabled. As with the /cfg partition on NanoBSD with SD card, I didn't reali= se any faults again since then.=20 >=20 >=20 > >=20 > > Best regards > > Michael =20 > > >=20 > > > Warner > > > _______________________________________________ > > > 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" =20 > >=20 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" =20 >=20 --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/ZmNi6G2KhPSkwUp9=voe_7f Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWlIFMQAKCRDS528fyFhY lKOVAf9U0wLiMcFmMo6vj+YFoRo8OZVXJTENyPXV1nUxL0Hwz4kQ7D2n3i+OJD9y fgDfS9JDmLDqH/9/61GxVYkG3Z5CAf9f2Bc3g3RDqLCp0bnFtL36Uf2bETCNEDt6 zxpzawAJgjPo3OsIQZaxqLVfJg6P6bh+su0hU8la8m/+I85fl77Y =xzmX -----END PGP SIGNATURE----- --Sig_/ZmNi6G2KhPSkwUp9=voe_7f-- From owner-freebsd-current@freebsd.org Sun Jan 7 12:13:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7196EE69E26 for ; Sun, 7 Jan 2018 12:13:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-127.reflexion.net [208.70.210.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 310FAB2E for ; Sun, 7 Jan 2018 12:13:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29135 invoked from network); 7 Jan 2018 12:13:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 12:13:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 07:13:35 -0500 (EST) Received: (qmail 29915 invoked from network); 7 Jan 2018 12:13:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 12:13:35 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1406EEC88E2; Sun, 7 Jan 2018 04:13:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: Date: Sun, 7 Jan 2018 04:13:33 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 12:13:42 -0000 [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?] >=20 > On 2018-Jan-7, at 2:44 AM, Mark Millard = wrote: >=20 >> [The following notes a problem with how a test was done. >> I omit the rest of the material.] >>=20 >> On 2018-Jan-7, at 2:09 AM, blubee blubeeme = wrote: >>=20 >> . . . >>> This is a larger file, not the largest but hey >>>=20 >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >>> 0 4 0 0 0.0 2 8 0.0 0 0 = 0.0 0.1| nvd0 >>> 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| md99 >>> 128 982 1 32 58.8 981 125428 110.5 0 0 = 0.0 100.0| da1 >> . . . >>=20 >> Note that almost complete lack of kBps near r/s but the large >> kBps near w/s. >>=20 >> 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. >>=20 >> 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). >>=20 >> See if you can get gstat -pd results that show both >> read kBps and write kBps figures. >=20 > 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? >=20 > =46rom 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. >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > In your other table: >=20 > This is an example copying [multiple small files] to the 1TB drive. > = --------------------------------------------------------------------------= ---------------------------------------- > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 547 290 35239 2.0 4 16 73.1 249 44291 = 93.7 48.8| nvd0 > 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| md99 > 21 333 0 0 0.0 333 36040 16.2 0 0 = 0.0 76.2| da1 > = --------------------------------------------------------------------------= ---------------------------------------- >=20 > This shows lots of deletes per second for some reason. >=20 > Did you move instead of copy? After each file was copied, > was it then deleted? >=20 > It is possible that the deletes slowed this down, > whatever they were from. Here are "gstat -pd" samples from during a: cp -ax /usr/src /media/root/srccpy_test (which is to USB2 from non-USB.) dT: 1.071s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 2346 2346 20234 0.1 0 0 0.0 0 0 = 0.0 11.9| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1162 1375 21 658 60.1 1354 26962 331.4 0 0 = 0.0 81.1| da4 dT: 1.069s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 859 859 7657 0.1 0 0 0.0 0 0 = 0.0 4.8| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 841 1544 7 240 5.3 1536 31956 261.7 0 0 = 0.0 93.0| da4 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 1709 1709 15074 0.1 0 0 0.0 0 0 = 0.0 9.3| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1257 1423 15 479 43.9 1408 31011 277.5 0 0 = 0.0 91.9| da4 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 4350 4350 44982 0.1 0 0 0.0 0 0 = 0.0 22.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 943 1028 27 867 5.0 1001 19315 614.8 0 0 = 0.0 59.8| da4 Here are "gstat -pd" samples from during a: cp -ax /media/usr/src /root/srccpy_test (which is to non-USB from USB2.) dT: 1.069s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 306 0 0 0.0 306 38383 0.3 0 0 = 0.0 2.6| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1 548 548 37533 52.7 0 0 0.0 0 0 = 0.0 100.2| da4 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 934 7 209 0.1 927 12438 2.2 0 0 = 0.0 1.5| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1 1296 1296 20674 0.7 0 0 0.0 0 0 = 0.0 90.1| da4 dT: 1.070s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 1208 5 150 0.1 1203 32069 2.3 0 0 = 0.0 2.2| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 1 931 931 27073 6.9 0 0 0.0 0 0 = 0.0 93.6| da4 No bottlenecks causing < 8 MiBytes/s: much faster then that. USB2 is not such a bottleneck in my context. But, again, all UFS and the USB SSD stick is the slower device but is, in turn, limited by USB2 in these. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 12:42:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98A39E6B75E for ; Sun, 7 Jan 2018 12:42:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56FF3201F for ; Sun, 7 Jan 2018 12:42:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8181 invoked from network); 7 Jan 2018 11:42:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 11:42:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 06:42:32 -0500 (EST) Received: (qmail 28111 invoked from network); 7 Jan 2018 11:42:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 11:42:32 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A20ABEC9458; Sun, 7 Jan 2018 03:42:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> Date: Sun, 7 Jan 2018 03:42:31 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 12:42:39 -0000 [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.] >=20 > On 2018-Jan-7, at 2:09 AM, blubee blubeeme = wrote: >=20 > . . . >> This is a larger file, not the largest but hey >>=20 >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 4 0 0 0.0 2 8 0.0 0 0 = 0.0 0.1| nvd0 >> 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| md99 >> 128 982 1 32 58.8 981 125428 110.5 0 0 = 0.0 100.0| da1 > . . . >=20 > Note that almost complete lack of kBps near r/s but the large > kBps near w/s. >=20 > 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. >=20 > 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). >=20 > 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? =46rom what I read Android has many file systems supported or used at one time: ext4, f2fs, yaffs, yaffs2, vfat, msdos being in the list. Normal SD and SDHC files systems are FAT32 and SDXC is exFAT. So "Android 7.1" does not answer my question about which file system is actually on the usdcard being used. I'd guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but I do not really know. My results show that getting above 8 MiBytes/s over USB 2.0 is supported for other than the rather low end of the FreeBSD range of systems. Beyond that is something more specific to your context and not involved in mine. The file system might be involved. So far, from the tables and what you have written, the LG v30 is required to be involved for the slowdown to sub 8 MiBytes/s. This is part of why I ask about testing an alternative USB device that is fast: it tests USB without involving the LG v30 or the usdcard. If USB ends up faster, then it is not USB's "stack" that is the primary source of the current bottleneck for your context: something else is also involved, such as the file system may be. Can you show gstat -pd output for copying from the LG v30? Copying to the 1TB USB backup device? The %busy figures might be interesting. In your other table: This is an example copying [multiple small files] to the 1TB drive. = --------------------------------------------------------------------------= ---------------------------------------- L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 547 290 35239 2.0 4 16 73.1 249 44291 = 93.7 48.8| nvd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| md99 21 333 0 0 0.0 333 36040 16.2 0 0 = 0.0 76.2| da1 = --------------------------------------------------------------------------= ---------------------------------------- This shows lots of deletes per second for some reason. Did you move instead of copy? After each file was copied, was it then deleted? It is possible that the deletes slowed this down, whatever they were from. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 13:29:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B605AE6D4DB for ; Sun, 7 Jan 2018 13:29:03 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8043535D4 for ; Sun, 7 Jan 2018 13:29:02 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1eYAlA-00010o-Or; Sun, 07 Jan 2018 14:13:09 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "FreeBSD Current" , "Chris H" Subject: Re: status-mail-rejects: appears to be broken References: Date: Sun, 07 Jan 2018 14:13:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: ba572e8a3bde05b4b19613c12a9e49fc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 13:29:03 -0000 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 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 > > > _______________________________________________ > 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" From owner-freebsd-current@freebsd.org Sun Jan 7 15:50:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF870E72FB1 for ; Sun, 7 Jan 2018 15:50:18 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8415C6B93E for ; Sun, 7 Jan 2018 15:50:18 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id b77so3339055itd.0 for ; Sun, 07 Jan 2018 07:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPTpOFOmKNLsPIFhrF+QHp0wG+NrIr2YaJ1np9e0/lc=; b=IMsbdf7U2nDKtnwRlguLPUqsqFhcK9Q6TfIr2RH9YVzOZmVQuoEUhw7t9LjoKXYdt3 zCtfrEdlD9a8pA+wAyuKVNq9nOCxFfH/xJ6rFk8ezfISlWQ15AR55gtHDpbDBc6i0ALj sRNA9mR3AG0BJ5SEP8H6+GuIUfAVRkAOSufZilQYgD5h6wfSX0X+dykcS1x9J9NsYe62 TILmct3mKKuR4sVh/gA71w7OwR0ECf1cC6bzfF5XdYNKtIbiUlpW+GzTdsUS2manYy2H 6+3fLD/hnHhBHSvmTpWJeuTO3xYRCQER/AFtO2QfL66crbppIH9/arrHp81wySle8abl BXuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TPTpOFOmKNLsPIFhrF+QHp0wG+NrIr2YaJ1np9e0/lc=; b=kff13bc8BbSQ/lpYeJ0NKS8WEQfQaqrVnQBFbee+lWw2DhGC1LHTUQD47WJaSp+jrV 9I8dM8QvTs/5tH0DCCMA0wgQTfUKPjXou51BdN4bRKT7NQBAK71U74K8wUtFkXArfuI9 QqSyiBMpnzHpZTsMbRc8GwR6KvG7abiyD3IV3S1PBryMmCGCS3ZEYdCvegURHdN44fIW F1lcP5W+f6dHBo0N+DL/UrB/iF02U1JSJuTp/O2jktfGI0VszhSbZ7hUnd899pmB6Ubw e7x/O2UBwTEFjRz73d1iEBXNgpwGAg5vtXRhoAK3baid0uCv+1xlgj7VyT9oZxMUEfBz TmsA== X-Gm-Message-State: AKwxytdzeSJlfmlGMgkF6Jx5zBnHIta+CxJN3WDGQmNXJpq9YtjodARK N89WnCAIJTd4HEYMxX25llOUiH9gJxEGHYuaPIE= X-Google-Smtp-Source: ACJfBot2L67m6zwvXjtOUwQyCwIZMazQWjgNONw0+Iwok0DKtyS61n8OuZx0HigYVx5o9H3kKJXDyBw48xwwpxWgwwk= X-Received: by 10.36.185.18 with SMTP id w18mr1795358ite.140.1515340216867; Sun, 07 Jan 2018 07:50:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 07:50:16 -0800 (PST) In-Reply-To: References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> From: blubee blubeeme Date: Sun, 7 Jan 2018 23:50:16 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 15:50:18 -0000 On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard wrote: > [I add an example of a none-USB to USB2 copy and > a USB2 to non-USB copy. They do not show any > < 8 MiByte/s bottlenecks.] > > On 2018-Jan-7, at 3:42 AM, Mark Millard wrote: > > > [The other numbers show lots of delete activity on nvd0, > > not just primarily reads. Also: Can you test a different > > USB device, such as a USB SSD stick?] > > > > On 2018-Jan-7, at 2:44 AM, Mark Millard wrote: > > > >> [The following notes a problem with how a test was done. > >> I omit the rest of the material.] > >> > >> On 2018-Jan-7, at 2:09 AM, blubee blubeeme > wrote: > >> > >> . . . > >>> This is a larger file, not the largest but hey > >>> > >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > >>> 0 4 0 0 0.0 2 8 0.0 0 0 > 0.0 0.1| nvd0 > >>> 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| md99 > >>> 128 982 1 32 58.8 981 125428 110.5 0 0 > 0.0 100.0| da1 > >> . . . > >> > >> Note that almost complete lack of kBps near r/s but the large > >> kBps near w/s. > >> > >> It appears that the file has been cached in RAM and is not > >> being read from media at all. So this test is of a RAM to > >> disk transfer, not disk to disk, as far as I can tell. > >> > >> You need to avoid re-reading the same file unless you > >> dismount and remount between tests or some such. Or > >> just use a different file not copied since booting (that > >> file may or may not be a previous copy of the same file > >> by content). > >> > >> See if you can get gstat -pd results that show both > >> read kBps and write kBps figures. > > > > Can you test another USB device, such as a USB SSD > > stick, sometime known to be reliably fast and not > > involving reading from the LG v30? > > > > From what I read Android has many file systems supported > > or used at one time: ext4, f2fs, yaffs, yaffs2, > > vfat, msdos being in the list. Normal SD and SDHC files > > systems are FAT32 and SDXC is exFAT. > > > > So "Android 7.1" does not answer my question about which > > file system is actually on the usdcard being used. I'd > > guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but > > I do not really know. > > > > > > My results show that getting above 8 MiBytes/s over > > USB 2.0 is supported for other than the rather low end > > of the FreeBSD range of systems. Beyond that is something > > more specific to your context and not involved in mine. > > The file system might be involved. > > > > So far, from the tables and what you have written, the > > LG v30 is required to be involved for the slowdown > > to sub 8 MiBytes/s. This is part of why I ask about > > testing an alternative USB device that is fast: it > > tests USB without involving the LG v30 or the usdcard. > > > > If USB ends up faster, then it is not USB's "stack" that > > is the primary source of the current bottleneck for your > > context: something else is also involved, such as the > > file system may be. > > > > Can you show gstat -pd output for copying from the > > LG v30? Copying to the 1TB USB backup device? The > > %busy figures might be interesting. > > > > > > In your other table: > > > > This is an example copying [multiple small files] to the 1TB drive. > > ------------------------------------------------------------ > ------------------------------------------------------ > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 0 547 290 35239 2.0 4 16 73.1 249 44291 > 93.7 48.8| nvd0 > > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| md99 > > 21 333 0 0 0.0 333 36040 16.2 0 0 > 0.0 76.2| da1 > > ------------------------------------------------------------ > ------------------------------------------------------ > > > > This shows lots of deletes per second for some reason. > > > > Did you move instead of copy? After each file was copied, > > was it then deleted? > > > > It is possible that the deletes slowed this down, > > whatever they were from. > > > Here are "gstat -pd" samples from during a: > > cp -ax /usr/src /media/root/srccpy_test > (which is to USB2 from non-USB.) > > dT: 1.071s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 2346 2346 20234 0.1 0 0 0.0 0 0 > 0.0 11.9| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1162 1375 21 658 60.1 1354 26962 331.4 0 0 > 0.0 81.1| da4 > > dT: 1.069s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 859 859 7657 0.1 0 0 0.0 0 0 > 0.0 4.8| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 841 1544 7 240 5.3 1536 31956 261.7 0 0 > 0.0 93.0| da4 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 1709 1709 15074 0.1 0 0 0.0 0 0 > 0.0 9.3| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1257 1423 15 479 43.9 1408 31011 277.5 0 0 > 0.0 91.9| da4 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 4350 4350 44982 0.1 0 0 0.0 0 0 > 0.0 22.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 943 1028 27 867 5.0 1001 19315 614.8 0 0 > 0.0 59.8| da4 > > > > Here are "gstat -pd" samples from during a: > > cp -ax /media/usr/src /root/srccpy_test > (which is to non-USB from USB2.) > > dT: 1.069s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 306 0 0 0.0 306 38383 0.3 0 0 > 0.0 2.6| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1 548 548 37533 52.7 0 0 0.0 0 0 > 0.0 100.2| da4 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 934 7 209 0.1 927 12438 2.2 0 0 > 0.0 1.5| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1 1296 1296 20674 0.7 0 0 0.0 0 0 > 0.0 90.1| da4 > > dT: 1.070s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 1208 5 150 0.1 1203 32069 2.3 0 0 > 0.0 2.2| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 1 931 931 27073 6.9 0 0 0.0 0 0 > 0.0 93.6| da4 > > > No bottlenecks causing < 8 MiBytes/s: much faster then that. > USB2 is not such a bottleneck in my context. > > But, again, all UFS and the USB SSD stick is the slower > device but is, in turn, limited by USB2 in these. > > === > Mark Millard > markmi at dsl-only.net > > > > > 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. From owner-freebsd-current@freebsd.org Sun Jan 7 17:41:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D74EAE77BC3 for ; Sun, 7 Jan 2018 17:41:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-119.reflexion.net [208.70.210.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8295C6FB56 for ; Sun, 7 Jan 2018 17:41:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14607 invoked from network); 7 Jan 2018 17:41:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 17:41:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 12:41:44 -0500 (EST) Received: (qmail 25431 invoked from network); 7 Jan 2018 17:41:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 17:41:44 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BEE5EEC8BF3; Sun, 7 Jan 2018 09:41:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: Date: Sun, 7 Jan 2018 09:41:43 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 17:41:46 -0000 On 2018-Jan-7, at 7:50 AM, blubee blubeeme = wrote: > I ran this test and here's some results. > gstat -pd images: >=20 > 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 >=20 > 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 >=20 > 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 17:59:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B968E78657 for ; Sun, 7 Jan 2018 17:59:06 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3B770551 for ; Sun, 7 Jan 2018 17:59:06 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yw0-x22b.google.com with SMTP id l23so3553908ywb.13 for ; Sun, 07 Jan 2018 09:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=4XoF8LtD1EQdnMXCe8pzQkjjK666ecG9wDbfwG77UAk=; b=oYe5W6eb9fSwiihFe5Vp6f/0yJuNKUNuf3KO7/5GZwmigLOSh16gGlDCOcnstI1AVB MzAycDKoA2UgU/hAwVkckOf7o7Onbub1hyDozlEEyGNx2CovdN9+zKAt+DRu801Wv7Jz lihBTiGanGl1OR9tjUsdMDmopYEoyxr6Zx65jFsXkpJmAJ8HtXJE3OrFzG8xbT3AjvFb C3qKQJfs6/Y5WMRwWrIYpY6u3SiHobZ9EBP7Hw+US0Wi1t7t68YtdLpaEXzkMF1g881C VbTM5C5PcovlrAekYRfG6M89diuD8GsiO2CujlbJkDBuENfTHDZ37Uxh0aofYhBf26hp P9AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=4XoF8LtD1EQdnMXCe8pzQkjjK666ecG9wDbfwG77UAk=; b=AAYZYtKtRnoqQeVN+Uz81aEnx0Tp3zf5ARfnWEFkwZ+gNeFlvVove3vP7gClPPKle8 pkpxJD4CIvRIh6pDSWkYQoee/PiqR+CLKG0altL1wFxb+f/WufTsfWiAkn/j7F4E3h7c cQzJGuQkK4l3dmUNbq00rW9mZ7VC5mqXpjdihjyT00R21K8viUM2X8vL7XoRwKrxvHtm myKmhFWVSqxRuQ1HRY3jiRyiIANX9IzlaXKx93nINe2Lkc/mMRI0pou4bsbq94rdsxV8 yVneoyVdQIL4oj5VXcRSumgypCpBnxukk1wMDMnGg94iPrnjhd/TO7fgLAw3GXjGqh5u eCnQ== X-Gm-Message-State: AKGB3mK1xW4pMWgil7N9WQpRMMmbrXFNnm1uDAPCUHeKyrxzcvdMz39W mcQ9OGHGaxjZzMaeBb/jKdaOzEqiy9XpAl6XKoQPzA== X-Google-Smtp-Source: ACJfBoswvNGgDGOBB4J/mJUZMYBOTP2KGw220UMs+U01buAjPfh/UZiDt4AOPtTKjbU6x3lLAFpP4W/GDYGuHKOTr94= X-Received: by 10.129.67.1 with SMTP id q1mr9268111ywa.464.1515347945178; Sun, 07 Jan 2018 09:59:05 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.101.197 with HTTP; Sun, 7 Jan 2018 09:58:49 -0800 (PST) From: Wolfram Schneider Date: Sun, 7 Jan 2018 18:58:49 +0100 X-Google-Sender-Auth: vi5l3RQp96R9oXflctoh3gOQpJk Message-ID: Subject: partitioning schemes: GPT <-> MBR To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 17:59:06 -0000 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 Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Sun Jan 7 18:03:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F066DE78AD5 for ; Sun, 7 Jan 2018 18:03:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D47AA70C32 for ; Sun, 7 Jan 2018 18:03:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 06c9457b-f3d5-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 06c9457b-f3d5-11e7-93a5-cd02e7dc7692; Sun, 07 Jan 2018 18:03:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w07I3i4A004030; Sun, 7 Jan 2018 11:03:44 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515348224.54935.3.camel@freebsd.org> Subject: Re: partitioning schemes: GPT <-> MBR From: Ian Lepore To: Wolfram Schneider , freebsd-current Date: Sun, 07 Jan 2018 11:03:44 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 18:03:54 -0000 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 From owner-freebsd-current@freebsd.org Sun Jan 7 18:23:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16C36E7994E for ; Sun, 7 Jan 2018 18:23:40 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFAB271F40 for ; Sun, 7 Jan 2018 18:23:39 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x233.google.com with SMTP id q188so10727722iod.1 for ; Sun, 07 Jan 2018 10:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PusIFytZwGVDQX/lfxOA8tA+HeEQe7DvCtkutr0TCww=; b=JJU0l++0cjDDjmtBjm9YAzhb96ujGh4+vhS9jiZG27fy0txQF8ILa/K2Uskw1pqdch BKCfJBQssrrjvQmEXLGAq+QHCFF4r5zwBHyxPThdO5luqS2/uuljYKcVXC4E0pcpiI2j BeMliw7y9+/9Gig96jS6nSSu79DBhPDcVKkhoenPxmbCLf/KouyFo9ChUWoEk1j7GOuQ Xc7f32d9wsLiOYhetAV6BtosRz2wBOOdkUjrrp400rPK3q6osduRA9QHKBVpbajPBzMu iKtaqnkJNH+TX/Kp9Lw3SnJT+dSouDrgpVFqNBcbqy85QJnUdeBNtOrSb3/4C5cBtkxR u3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PusIFytZwGVDQX/lfxOA8tA+HeEQe7DvCtkutr0TCww=; b=LYy7z/H+sVytmAwH6zLpCS3ma6ZTqfjA8WAazi+LqlZ/AveayUcWdpPu+v6qZmdHyW hbfWBoxZEEOprEfK/fhGCNkI0I4B6WPvcUPIwX258M3QAsttD+vZJNg+XnPi8nZ/uIF7 3OZxUNZWiLrIETVt7Kaa/XqbSLI5FdbwvrZxtXgbK7ZbEXnkd63Sj9DwgcM87iKgF2uX aRBmOA8qqqX79ORYIofhx5hgSdhxMnKPztpgcaOVZI+TBgyLguUYUJRISU0smtFLv9Qi uvqFiMUTwjiI7Z4AlXmPtGQagWBxUbyzFu7gRfCeCZAQMiSj0kTPebu33yy2pMoQbRMy yYVg== X-Gm-Message-State: AKwxytcB9ehYcA77sewa1ZieVQ7ICVO0a1xNgEF82gCHrrHckcha7Fxm gtHy79C0pHIvw6+fCAI2hSHgAvvt0b52fU53ySg= X-Google-Smtp-Source: ACJfBos6tZQ9qHIJkmebCcjabI823a1DumxankbRsspv5MedDg3gqZSYitXSBrWgMiKlI139dTKKxtbo33RN/J5f0Wg= X-Received: by 10.107.16.79 with SMTP id y76mr9005318ioi.213.1515349417539; Sun, 07 Jan 2018 10:23:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 10:23:36 -0800 (PST) In-Reply-To: <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> From: blubee blubeeme Date: Mon, 8 Jan 2018 02:23:36 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 18:23:40 -0000 On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard wrote: > > On 2018-Jan-7, at 7:50 AM, blubee blubeeme wrote: > > > I ran this test and here's some results. > > gstat -pd images: > > > > 18GB file from laptop to phone: https://imgur.com/a/7iHwv > > 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > > multiple small files from laptop to phone: https://imgur.com/a/B4v4y > > multiple small files from laptop to ssd: https://imgur.com/a/mDiMu > > > > The files are missing timestamps but the originals were taken with scrot > and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > > > > as far as why there's such high deletions? I can't say I'm only using cp. > > I assume that md99 is for a file-based swap-space, such as > via /var/swap0 file. (As a side note I warn about bugzilla > 206048 for such contexts.) Otherwise please describe how > md99 is created. (Below I assume the swap-space usage of > md99.) > > The only other device that your pictures show is your > NVMe device nvd0. > > No picture shows a device for the LG v30 when it is mentioned > above as being copied to or from. How is it that there is no > mounted device shown for the LG v30? > > No picture shows a device for the SSD when it is mentioned > above as being copied to or from. How is it that there > is no mounted device shown for the SSD? > > Without a device displayed for the LG-v30/SSD there is nothing > displayed for its reads or writes. This makes the gstat -pd > useless. > > May be the p needs to be omitted for some reason? gstat -d > > === > Mark Millard > markmi at dsl-only.net > > You are correct that md99 is a file backed swap disk, I am aware of the issues but I had to test some things out. Those tests earlier was a huge time sink. Here's the dmesg output from earlier: ------------------------ Jan 7 19:13:17 blubee kernel: Copyright (c) 1992-2017 The FreeBSD Project. Jan 7 19:13:17 blubee kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 7 19:13:17 blubee kernel: The Regents of the University of California. All rights reserved. Jan 7 19:13:17 blubee kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 7 19:13:17 blubee kernel: FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 14:54:55 UTC 2017 Jan 7 19:13:17 blubee kernel: root@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: netmap: loaded module Jan 7 19:13:17 blubee kernel: [ath_hal] loaded Jan 7 19:13:17 blubee kernel: module_register_init: MOD_LOAD (vesa, 0xffffffff80f95c20, 0) error 19 Jan 7 19:13:17 blubee kernel: random: registering fast source Intel Secure Key RNG Jan 7 19:13:17 blubee kernel: random: fast provider: "Intel Secure Key RNG" Jan 7 19:13:17 blubee kernel: kbd1 at kbdmux0 Jan 7 19:13:17 blubee kernel: nexus0 Jan 7 19:13:17 blubee kernel: cryptosoft0: on motherboard Jan 7 19:13:17 blubee kernel: acpi0: on motherboard Jan 7 19:13:17 blubee kernel: acpi0: Power Button (fixed) Jan 7 19:13:17 blubee kernel: cpu0: on acpi0 Jan 7 19:13:17 blubee kernel: cpu1: on acpi0 Jan 7 19:13:17 blubee kernel: cpu2: on acpi0 Jan 7 19:13:17 blubee kernel: cpu3: on acpi0 Jan 7 19:13:17 blubee kernel: cpu4: on acpi0 Jan 7 19:13:17 blubee kernel: cpu5: on acpi0 Jan 7 19:13:17 blubee kernel: cpu6: on acpi0 Jan 7 19:13:17 blubee kernel: cpu7: on acpi0 Jan 7 19:13:17 blubee kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 7 19:13:17 blubee kernel: Timecounter "HPET" frequency 24000000 Hz quality 950 Jan 7 19:13:17 blubee kernel: Event timer "HPET" frequency 24000000 Hz quality 550 Jan 7 19:13:17 blubee kernel: atrtc0: port 0x70-0x77 irq 8 on acpi0 Jan 7 19:13:17 blubee kernel: atrtc0: Warning: Couldn't map I/O. Jan 7 19:13:17 blubee kernel: atrtc0: registered as a time-of-day clock, resolution 1.000000s Jan 7 19:13:17 blubee kernel: Event timer "RTC" frequency 32768 Hz quality 0 Jan 7 19:13:17 blubee kernel: attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Jan 7 19:13:17 blubee kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 7 19:13:17 blubee kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Jan 7 19:13:17 blubee kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Jan 7 19:13:17 blubee kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 Jan 7 19:13:17 blubee kernel: acpi_ec0: port 0x62,0x66 on acpi0 Jan 7 19:13:17 blubee kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 7 19:13:17 blubee kernel: pci0: on pcib0 Jan 7 19:13:17 blubee kernel: pcib1: at device 1.0 on pci0 Jan 7 19:13:17 blubee kernel: pci1: on pcib1 Jan 7 19:13:17 blubee kernel: vgapci0: port 0xe000-0xe07f mem 0xdb000000-0xdbffffff,0x90000000-0x9fffffff,0xa0000000-0xa1ffffff at device 0.0 on pci1 Jan 7 19:13:17 blubee kernel: nvidia0: on vgapci0 Jan 7 19:13:17 blubee kernel: vgapci0: child nvidia0 requested pci_enable_io Jan 7 19:13:17 blubee kernel: vgapci0: child nvidia0 requested pci_enable_io Jan 7 19:13:17 blubee kernel: vgapci0: Boot video device Jan 7 19:13:17 blubee kernel: xhci0: mem 0x2ffff10000-0x2ffff1ffff at device 20.0 on pci0 Jan 7 19:13:17 blubee kernel: xhci0: 32 bytes context size, 64-bit DMA Jan 7 19:13:17 blubee kernel: usbus0 on xhci0 Jan 7 19:13:17 blubee kernel: usbus0: 5.0Gbps Super Speed USB v3.0 Jan 7 19:13:17 blubee kernel: pci0: at device 22.0 (no driver attached) Jan 7 19:13:17 blubee kernel: ahci0: port 0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xdc404000-0xdc405fff,0xdc407000-0xdc4070ff,0xdc406000-0xdc4067ff at device 23.0 on pci0 Jan 7 19:13:17 blubee kernel: ahci0: AHCI v1.31 with 3 6Gbps ports, Port Multiplier not supported Jan 7 19:13:17 blubee kernel: ahcich1: at channel 1 on ahci0 Jan 7 19:13:17 blubee kernel: ahcich2: at channel 2 on ahci0 Jan 7 19:13:17 blubee kernel: ahcich3: at channel 3 on ahci0 Jan 7 19:13:17 blubee kernel: ahciem0: on ahci0 Jan 7 19:13:17 blubee kernel: ahciem0: EM timeout Jan 7 19:13:17 blubee kernel: device_attach: ahciem0 attach returned 6 Jan 7 19:13:17 blubee kernel: pcib2: at device 28.0 on pci0 Jan 7 19:13:17 blubee kernel: pcib2: [GIANT-LOCKED] Jan 7 19:13:17 blubee kernel: pcib3: at device 28.4 on pci0 Jan 7 19:13:17 blubee kernel: pci2: on pcib3 Jan 7 19:13:17 blubee kernel: pci2: at device 0.0 (no driver attached) Jan 7 19:13:17 blubee kernel: re0: port 0xd000-0xd0ff mem 0xdc304000-0xdc304fff,0xdc300000-0xdc303fff at device 0.1 on pci2 Jan 7 19:13:17 blubee kernel: re0: Using 1 MSI-X message Jan 7 19:13:17 blubee kernel: re0: turning off MSI enable bit. Jan 7 19:13:17 blubee kernel: re0: ASPM disabled Jan 7 19:13:17 blubee kernel: re0: Chip rev. 0x5c800000 Jan 7 19:13:17 blubee kernel: re0: MAC rev. 0x00000000 Jan 7 19:13:17 blubee kernel: miibus0: on re0 Jan 7 19:13:17 blubee kernel: rgephy0: PHY 1 on miibus0 Jan 7 19:13:17 blubee kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Jan 7 19:13:17 blubee kernel: re0: Using defaults for TSO: 65518/35/2048 Jan 7 19:13:17 blubee kernel: re0: Ethernet address: 80:fa:5b:3a:2f:8b Jan 7 19:13:17 blubee kernel: re0: netmap queues/slots: TX 1/256, RX 1/256 Jan 7 19:13:17 blubee kernel: pcib4: at device 28.6 on pci0 Jan 7 19:13:17 blubee kernel: pci3: on pcib4 Jan 7 19:13:17 blubee kernel: iwm0: mem 0xdc200000-0xdc201fff at device 0.0 on pci3 Jan 7 19:13:17 blubee kernel: pcib5: at device 29.0 on pci0 Jan 7 19:13:17 blubee kernel: pci4: on pcib5 Jan 7 19:13:17 blubee kernel: nvme0: mem 0xdc100000-0xdc103fff at device 0.0 on pci4 Jan 7 19:13:17 blubee kernel: isab0: at device 31.0 on pci0 Jan 7 19:13:17 blubee kernel: isa0: on isab0 Jan 7 19:13:17 blubee kernel: pci0: at device 31.2 (no driver attached) Jan 7 19:13:17 blubee kernel: hdac0: mem 0x2ffff20000-0x2ffff23fff,0x2ffff00000-0x2ffff0ffff at device 31.3 on pci0 Jan 7 19:13:17 blubee kernel: acpi_button0: on acpi0 Jan 7 19:13:17 blubee kernel: acpi_button1: on acpi0 Jan 7 19:13:17 blubee kernel: acpi_lid0: on acpi0 Jan 7 19:13:17 blubee kernel: acpi_acad0: on acpi0 Jan 7 19:13:17 blubee kernel: battery0: on acpi0 Jan 7 19:13:17 blubee kernel: acpi_tz0: on acpi0 Jan 7 19:13:17 blubee kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 7 19:13:17 blubee kernel: atkbd0: irq 1 on atkbdc0 Jan 7 19:13:17 blubee kernel: kbd0 at atkbd0 Jan 7 19:13:17 blubee kernel: atkbd0: [GIANT-LOCKED] Jan 7 19:13:17 blubee kernel: psm0: irq 12 on atkbdc0 Jan 7 19:13:17 blubee kernel: psm0: [GIANT-LOCKED] Jan 7 19:13:17 blubee kernel: psm0: model Generic PS/2 mouse, device ID 0 Jan 7 19:13:17 blubee kernel: est0: on cpu0 Jan 7 19:13:17 blubee kernel: est1: on cpu1 Jan 7 19:13:17 blubee kernel: est2: on cpu2 Jan 7 19:13:17 blubee kernel: est3: on cpu3 Jan 7 19:13:17 blubee kernel: est4: on cpu4 Jan 7 19:13:17 blubee kernel: est5: on cpu5 Jan 7 19:13:17 blubee kernel: est6: on cpu6 Jan 7 19:13:17 blubee kernel: est7: on cpu7 Jan 7 19:13:17 blubee kernel: ZFS filesystem version: 5 Jan 7 19:13:17 blubee kernel: ZFS storage pool version: features support (5000) Jan 7 19:13:17 blubee kernel: Timecounters tick every 1.000 msec Jan 7 19:13:17 blubee kernel: ugen0.1: <0x8086 XHCI root HUB> at usbus0 Jan 7 19:13:17 blubee kernel: iwm0: hw rev 0x180, fw ver 17.352738.0, address 60:57:18:94:c6:4a Jan 7 19:13:17 blubee kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Jan 7 19:13:17 blubee kernel: nvd0: NVMe namespace Jan 7 19:13:17 blubee kernel: nvd0: 244198MB (500118192 512 byte sectors) Jan 7 19:13:17 blubee kernel: hdacc0: at cad 0 on hdac0 Jan 7 19:13:17 blubee kernel: hdaa0: at nid 1 on hdacc0 Jan 7 19:13:17 blubee kernel: pcm0: at nid 20 and 24 on hdaa0 Jan 7 19:13:17 blubee kernel: pcm1: at nid 23 on hdaa0 Jan 7 19:13:17 blubee kernel: pcm2: at nid 30 on hdaa0 Jan 7 19:13:17 blubee kernel: WARNING: WITNESS option enabled, expect reduced performance. Jan 7 19:13:17 blubee kernel: Trying to mount root from zfs:zroot/ROOT/default []... Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0 Jan 7 19:13:17 blubee kernel: uhub0: 24 ports with 24 removable, self powered Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0 Jan 7 19:13:17 blubee kernel: ugen0.2: at usbus0 Jan 7 19:13:17 blubee kernel: ukbd0 on uhub0 Jan 7 19:13:17 blubee kernel: ukbd0: on usbus0 Jan 7 19:13:17 blubee kernel: kbd2 at ukbd0 Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0 Jan 7 19:13:17 blubee kernel: ugen0.3: at usbus0 Jan 7 19:13:17 blubee kernel: ugen0.4: at usbus0 Jan 7 19:13:17 blubee kernel: Root mount waiting for: usbus0 Jan 7 19:13:17 blubee kernel: ugen0.5: at usbus0 Jan 7 19:13:17 blubee kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 384.90 Tue Sep 19 17:29:32 PDT 2017 Jan 7 19:13:17 blubee kernel: acquiring duplicate lock of same type: "os.lock_sx" Jan 7 19:13:17 blubee kernel: 1st os.lock_sx @ nvidia_os.c:638 Jan 7 19:13:17 blubee kernel: 2nd os.lock_sx @ nvidia_os.c:638 Jan 7 19:13:17 blubee kernel: stack backtrace: Jan 7 19:13:17 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 19:13:17 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 19:13:17 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 Jan 7 19:13:17 blubee kernel: #3 0xffffffff82dc9112 at os_acquire_mutex+0x32 Jan 7 19:13:17 blubee kernel: #4 0xffffffff82ccff06 at _nv031368rm+0x16 Jan 7 19:13:17 blubee kernel: wlan0: Ethernet address: 60:57:18:94:c6:4a Jan 7 19:13:17 blubee kernel: wlan0: link state changed to UP Jan 7 19:13:17 blubee kernel: re0: link state changed to DOWN Jan 7 19:13:17 blubee kernel: ums0 on uhub0 Jan 7 19:13:17 blubee kernel: ums0: on usbus0 Jan 7 19:13:17 blubee kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 Jan 7 19:13:17 blubee kernel: ubt0 on uhub0 Jan 7 19:13:17 blubee kernel: ubt0: on usbus0 Jan 7 19:13:17 blubee kernel: WARNING: attempt to domain_add(bluetooth) after domainfinalize() Jan 7 19:13:17 blubee kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() Jan 7 19:13:17 blubee kernel: ubt0: ubt_ctrl_write_callback:780: control transfer failed: USB_ERR_TIMEOUT Jan 7 19:13:17 blubee kernel: ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout Jan 7 19:13:17 blubee ntpd[876]: ntpd 4.2.8p10-a (1): Starting Jan 7 19:13:17 blubee ntpd[877]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature Jan 7 19:13:17 blubee ntpd[877]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2018-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 Jan 7 19:13:17 blubee kernel: . Jan 7 19:13:17 blubee kernel: g_handleattr: md99 bio_length 24 len 31 -> EFAULT Jan 7 19:13:18 blubee dbus[931]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper) Jan 7 19:13:18 blubee dbus[931]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) Jan 7 19:13:18 blubee dbus[931]: [system] Successfully activated service 'org.freedesktop.ConsoleKit' Jan 7 19:13:18 blubee dbus[931]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' Jan 7 19:13:31 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20171110/nsarguments-210) Jan 7 19:13:32 blubee kernel: acquiring duplicate lock of same type: "os.lock_mtx" Jan 7 19:13:32 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:873 Jan 7 19:13:32 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:873 Jan 7 19:13:32 blubee kernel: stack backtrace: Jan 7 19:13:32 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 19:13:32 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 19:13:32 blubee kernel: #2 0xffffffff80a4b8dc at __mtx_lock_flags+0x9c Jan 7 19:13:32 blubee kernel: #3 0xffffffff82dc958b at os_acquire_spinlock+0x1b Jan 7 19:13:32 blubee kernel: #4 0xffffffff82ccc0ec at _nv030732rm+0xc Jan 7 19:13:32 blubee kernel: nvidia-modeset: Allocated GPU:0 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI:0000:01:00.0 Jan 7 19:13:49 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1 Jan 7 19:13:50 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2 Jan 7 19:13:51 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3 Jan 7 19:13:52 blubee adb: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:6 Err:-1 Errno:2 No such file or directory Jan 7 19:14:07 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 19:14:12 blubee kernel: ugen0.3: at usbus0 Jan 7 19:14:12 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 19:14:12 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 19:14:48 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 19:14:49 blubee kernel: ugen0.3: at usbus0 Jan 7 19:14:49 blubee root: Unknown USB device: vendor 0x1004 product 0x633e bus uhub0 Jan 7 19:14:49 blubee root: Unknown USB device: vendor 0x1004 product 0x633e bus uhub0 Jan 7 19:15:02 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1 Jan 7 19:15:03 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2 Jan 7 19:15:04 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3 Jan 7 19:15:05 blubee adb: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory Jan 7 19:15:06 blubee root: Unknown USB device: vendor 0x1004 product 0x633e bus uhub0 Jan 7 22:29:01 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 22:40:12 blubee kernel: ugen0.3: at usbus0 Jan 7 22:40:12 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 22:40:12 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 22:43:22 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 22:43:25 blubee kernel: ugen0.3: at usbus0 Jan 7 22:43:25 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 22:43:25 blubee kernel: lock order reversal: Jan 7 22:43:25 blubee kernel: 1st 0xfffff807d194b9a0 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:568 Jan 7 22:43:25 blubee kernel: 2nd 0xfffffe07c2632680 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:374 Jan 7 22:43:25 blubee kernel: stack backtrace: Jan 7 22:43:25 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 22:43:25 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 22:43:25 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883 Jan 7 22:43:25 blubee kernel: #3 0xffffffff80da0f19 at initpbuf+0xb9 Jan 7 22:43:25 blubee kernel: #4 0xffffffff80da0e34 at getpbuf+0x124 Jan 7 22:43:25 blubee kernel: #5 0xffffffff80d785b6 at sw Jan 7 22:43:25 blubee kernel: ap_pager_getpages+0x46 Jan 7 22:43:25 blubee kernel: #6 0xffffffff80da0a3a at vm_pager_get_p Jan 7 22:43:25 blubee kernel: ages+0x4a Jan 7 22:43:25 blubee kernel: #7 0xffffffff80d84762 at vm_fault_hold+0xf12 Jan 7 22:43:25 blubee kernel: #8 0xffffffff80d86389 at vm_fault_quick_hold_pages+0x139 Jan 7 22:43:25 blubee kernel: #9 0xffffffff80b4b41f at vn_io_fault1+0x2cf Jan 7 22:43:25 blubee kernel: Jan 7 22:43:25 blubee kernel: #10 0xffffffff80b4b045 at vn_rdwr+0x1b5 Jan 7 22:43:25 blubee kernel: #11 0xffffffff80b4b5e2 at vn_rdwr_inchunks+0x92 Jan 7 22:43:25 blubee kernel: #12 0xffffffff809fd18c at elf64_cor Jan 7 22:43:25 blubee kernel: edump+0xcec Jan 7 22:43:25 blubee kernel: #13 0xffffffff80a70 Jan 7 22:43:25 blubee kernel: 13c at sigexit+0x81c Jan 7 22:43:25 blubee kernel: #14 0xffffffff80a70970 at postsig+0x1c0 Jan 7 22:43:25 blubee kernel: #15 0xffffffff80ac5557 at ast+0x2e7 Jan 7 22:43:25 blubee kernel: #16 0xffffffff80ef6f69 at doreti_ast+0x1f Jan 7 22:43:25 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 22:43:25 blubee kernel: pid 1216 (adb), uid 0: exited on signal 10 (core dumped) Jan 7 22:43:29 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1 Jan 7 22:43:30 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2 Jan 7 22:43:31 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3 Jan 7 22:43:32 blubee adb: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:9 Err:-1 Errno:2 No such file or directory Jan 7 22:43:50 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1 Jan 7 22:43:51 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2 Jan 7 22:43:52 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3 Jan 7 22:43:53 blubee adb: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory Jan 7 22:43:54 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 22:55:09 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 23:00:37 blubee kernel: ugen0.3: at usbus0 Jan 7 23:00:37 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 23:00:37 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 23:01:40 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1 Jan 7 23:01:41 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2 Jan 7 23:01:42 blubee adb: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3 Jan 7 23:01:43 blubee adb: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory Jan 7 23:01:44 blubee root: Unknown USB device: vendor 0x1004 product 0x61f9 bus uhub0 Jan 7 23:04:12 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 7 23:04:33 blubee kernel: ugen0.3: at usbus0 Jan 7 23:04:33 blubee kernel: umass0 on uhub0 Jan 7 23:04:33 blubee kernel: umass0: on usbus0 Jan 7 23:04:33 blubee kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Jan 7 23:04:33 blubee kernel: umass0:3:0: Attached to scbus3 Jan 7 23:04:33 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Jan 7 23:04:33 blubee kernel: da0: Fixed Direct Access SPC-4 SCSI device Jan 7 23:04:33 blubee kernel: da0: Serial Number NZY8239W Jan 7 23:04:33 blubee kernel: da0: 400.000MB/s transfers Jan 7 23:04:33 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) Jan 7 23:04:33 blubee kernel: da0: quirks=0x2 Jan 7 23:06:02 blubee kernel: lock order reversal: Jan 7 23:06:02 blubee kernel: 1st 0xfffff803eba695f0 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3965 Jan 7 23:06:02 blubee kernel: 2nd 0xfffffe07c2636440 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3562 Jan 7 23:06:02 blubee kernel: stack backtrace: Jan 7 23:06:02 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 23:06:02 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 23:06:02 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883 Jan 7 23:06:02 blubee kernel: #3 0xffffffff80b17f8e at getblk+0x4fe Jan 7 23:06:02 blubee kernel: #4 0xffffffff80b17884 at breadn_flags+0x34 Jan 7 23:06:02 blubee kernel: #5 0xffffffff80d5fb36 at ffs_blkatoff+0x86 Jan 7 23:06:02 blubee kernel: #6 0xffffffff80d71c4e at ufs_readdir+0x17e Jan 7 23:06:02 blubee kernel: #7 0xffffffff81093d09 at VOP_READDIR_APV+0xd9 Jan 7 23:06:02 blubee kernel: #8 0xffffffff80b483cf at kern_getdirentries+0x24f Jan 7 23:06:02 blubee kernel: #9 0xffffffff80b485d9 at sys_getdirentries+0x29 Jan 7 23:06:02 blubee kernel: #10 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 7 23:06:02 blubee kernel: #11 0xffffffff80ef5b7b at Xfast_syscall+0xfb Jan 7 23:07:26 blubee kernel: lock order reversal: Jan 7 23:07:26 blubee kernel: 1st 0xfffff8017ae98a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:214 Jan 7 23:07:26 blubee kernel: 2nd 0xfffffe07c263f340 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3562 Jan 7 23:07:26 blubee kernel: stack backtrace: Jan 7 23:07:26 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 7 23:07:26 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 7 23:07:26 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883 Jan 7 23:07:26 blubee kernel: #3 0xffffffff80b17f8e at getblk+0x4fe Jan 7 23:07:26 blubee kernel: #4 0xffffffff80b17884 at breadn_flags+0x34 Jan 7 23:07:26 blubee kernel: #5 0xffffffff80d5fb36 at ffs_blkatoff+0x86 Jan 7 23:07:26 blubee kernel: #6 0xffffffff80d69419 at ufsdirhash_build+0x959 Jan 7 23:07:26 blubee kernel: #7 0xffffffff80d6bcca at ufs_lookup_ino+0x1aa Jan 7 23:07:26 blubee kernel: #8 0xffffffff81091873 at VOP_CACHEDLOOKUP_APV+0xd3 Jan 7 23:07:26 blubee kernel: #9 0xffffffff80b24166 at vfs_cache_lookup+0xd6 Jan 7 23:07:26 blubee kernel: #10 0xffffffff81091703 at VOP_LOOKUP_APV+0xd3 Jan 7 23:07:26 blubee kernel: #11 0xffffffff80b2d542 at lookup+0x682 Jan 7 23:07:26 blubee kernel: #12 0xffffffff80b2caca at namei+0x51a Jan 7 23:07:26 blubee kernel: #13 0xffffffff80b44240 at kern_unlinkat+0x80 Jan 7 23:07:26 blubee kernel: #14 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 7 23:07:26 blubee kernel: #15 0xffffffff80ef5b7b at Xfast_syscall+0xfb Jan 8 00:07:55 blubee kernel: lock order reversal: Jan 8 00:07:55 blubee kernel: 1st 0xfffff80877d6e418 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1276 Jan 8 00:07:55 blubee kernel: 2nd 0xfffff8000a3609a0 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2770 Jan 8 00:07:55 blubee kernel: stack backtrace: Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a41b8e at lockmgr_lock_fast_path+0x1ae Jan 8 00:07:55 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 Jan 8 00:07:55 blubee kernel: #5 0xffffffff80b39dd6 at vputx+0x156 Jan 8 00:07:55 blubee kernel: #6 0xffffffff80b31888 at dounmount+0x4d8 Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b3132f at sys_unmount+0x30f Jan 8 00:07:55 blubee kernel: #8 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 8 00:07:55 blubee kernel: #9 0xffffffff80ef5b7b at Xfast_syscall+0xfb Jan 8 00:07:55 blubee kernel: lock order reversal: Jan 8 00:07:55 blubee kernel: 1st 0xfffff80877d6e418 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1276 Jan 8 00:07:55 blubee kernel: 2nd 0xfffff8014af929a0 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1416 Jan 8 00:07:55 blubee kernel: stack backtrace: Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a41b8e at lockmgr_lock_fast_path+0x1ae Jan 8 00:07:55 blubee kernel: #3 0xffffffff81094309 at VOP_LOCK1_APV+0xd9 Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 Jan 8 00:07:55 blubee kernel: #5 0xffffffff80d60b43 at ffs_flushfiles+0x93 Jan 8 00:07:55 blubee kernel: #6 0xffffffff80d6311e at ffs_unmount+0x7e Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b318c8 at dounmount+0x518 Jan 8 00:07:55 blubee kernel: #8 0xffffffff80b3132f at sys_unmount+0x30f Jan 8 00:07:55 blubee kernel: #9 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 8 00:07:55 blubee kernel: #10 0xffffffff80ef5b7b at Xfast_syscall+0xfb Jan 8 00:07:55 blubee kernel: lock order reversal: Jan 8 00:07:55 blubee kernel: 1st 0xffffffff81eab970 GEOM topology (GEOM topology) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1303 Jan 8 00:07:55 blubee kernel: 2nd 0xfffffe07c3f55680 bufwait (bufwait) @ /usr/src/sys/kern/vfs_subr.c:1758 Jan 8 00:07:55 blubee kernel: stack backtrace: Jan 8 00:07:55 blubee kernel: #0 0xffffffff80acfa03 at witness_debugger+0x73 Jan 8 00:07:55 blubee kernel: #1 0xffffffff80acf882 at witness_checkorder+0xe02 Jan 8 00:07:55 blubee kernel: #2 0xffffffff80a424c3 at __lockmgr_args+0x883 Jan 8 00:07:55 blubee kernel: #3 0xffffffff80b37783 at flushbuflist+0x103 Jan 8 00:07:55 blubee kernel: #4 0xffffffff80b37411 at bufobj_invalbuf+0x81 Jan 8 00:07:55 blubee kernel: #5 0xffffffff809bf426 at g_vfs_close+0x46 Jan 8 00:07:55 blubee kernel: #6 0xffffffff80d632d0 at ffs_unmount+0x230 Jan 8 00:07:55 blubee kernel: #7 0xffffffff80b318c8 at dounmount+0x518 Jan 8 00:07:55 blubee kernel: #8 0xffffffff80b3132f at sys_unmount+0x30f Jan 8 00:07:55 blubee kernel: #9 0xffffffff80f16d2b at amd64_syscall+0x79b Jan 8 00:07:55 blubee kernel: #10 0xffffffff80ef5b7b at Xfast_syscall+0xfb Jan 8 00:07:59 blubee kernel: ugen0.3: at usbus0 (disconnected) Jan 8 00:07:59 blubee kernel: umass0: at uhub0, port 17, addr 10 (disconnected) Jan 8 00:07:59 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Jan 8 00:07:59 blubee kernel: da0: s/n NZY8239W detached Jan 8 00:07:59 blubee kernel: (da0:umass-sim0:0:0:0): Periph destroyed Jan 8 00:07:59 blubee kernel: umass0: detached ---------------------------------- I don't know why gstat isn't showing the info u are looking for. You said earlier that something was getting deleted, I don't know what could be causing that. I've provided tons of debug out, logs, pciconf, dmesg, etc... Even say forget the mobile device and go from zpool Are you saying that there's something misconfigured on my end? What other info do you need me to provide to try to figure out what's going on or why I'm getting these transfer rates? From owner-freebsd-current@freebsd.org Sun Jan 7 19:02:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A999DE7B4A8 for ; Sun, 7 Jan 2018 19:02:43 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72CE273A75 for ; Sun, 7 Jan 2018 19:02:43 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id d137so6995882itc.2 for ; Sun, 07 Jan 2018 11:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gYOxKCDB/qdIUNNoyNSug5W7UV07P2H9mMGTOpLXcuU=; b=IVqIwwyP8nfcns+5eWAd/NRVgdTarcKuAsDKjxvhJycL8VTWVnM+JetZ4Urzgc3JaV uBcvivFvuwOBpYOGMth9R+zTBQB5q9udbyzYFH549Ya/sm9CncKwRRwmcK2IVws1rGAd Q7p9Dh/Azmyk2DE5s0DYhKU/Gkt6eZ/KP1uW/hgM5f5DmpMfNW9cUSQ7bkK96fUXZqtr ZEWDriFXMTMJ3rSyEGiuVE7YnrEA/Go72wAGCkWh6S0pKcdr2ZE2Q9C5FuTQ5lJGVk9O Wtv0HzIt3MajhNJI471im8TNI+1BFSRfQX8LqCPZC4Lu4kx4M13mU64zO2e5cGiiXAj7 MyOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gYOxKCDB/qdIUNNoyNSug5W7UV07P2H9mMGTOpLXcuU=; b=ZBKqStqSIvzkGQ5uKCc2QHC/h+Lst9HXvYMGuVZ8GuJEYHPPyncMT27dTZfGRvSBKw jww1uVGPOSHkyxgTVyLZsuvhVShmVRd0v0I/zSx3dXsI9yQNBgTxc9tWe77nDI3B/+Sc kW12JBIDMxvQGCNDDZUOBKNvKSPYy5oT5Ay0nJgUv66rPavE44j1WO7TTIHwSpXOq1DY o3uEDLj/pVWlqvSBhd8nfaP9xsYnryF+HbHyBZf6PFAWdvz1ARCenmphKm+0xYBrOtrw dvrL37XoW7CM423F80Z26bboQZy/BxdZ6XyXdI6eKIzaMv7sTfqS/Jd4FxRLfxtrouIk NwyQ== X-Gm-Message-State: AKwxytcYo0i7oD50saWcwj0HOzwwGEj4WEggQ1GB8iAATFsgriTykPGQ yoM55ogJ1ThjBfKbbci4lWQJipcFL98hezE+PJV81qv7 X-Google-Smtp-Source: ACJfBov0SKsEBPxpLK/OTnXt//s/5o6IETfNX5OeIHAyje9p9CdYnZscuJGuJu5JvS/foUhAakB8NALLWAf3AYRqv8Q= X-Received: by 10.36.185.18 with SMTP id w18mr2151433ite.140.1515351762054; Sun, 07 Jan 2018 11:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 11:02:41 -0800 (PST) From: blubee blubeeme Date: Mon, 8 Jan 2018 03:02:41 +0800 Message-ID: Subject: newcons vs syscons To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 19:02:43 -0000 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? From owner-freebsd-current@freebsd.org Sun Jan 7 19:53:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7EB6E7DADF for ; Sun, 7 Jan 2018 19:53:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78C1875D64 for ; Sun, 7 Jan 2018 19:53:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28383 invoked from network); 7 Jan 2018 19:46:54 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Jan 2018 19:46:54 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sun, 07 Jan 2018 14:46:54 -0500 (EST) Received: (qmail 19980 invoked from network); 7 Jan 2018 19:46:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jan 2018 19:46:53 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 32405EC7E56; Sun, 7 Jan 2018 11:46:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: Date: Sun, 7 Jan 2018 11:46:52 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 19:53:41 -0000 On 2018-Jan-7, at 10:23 AM, blubee blubeeme = wrote: > On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard = wrote: >=20 >> On 2018-Jan-7, at 7:50 AM, blubee blubeeme = wrote: >>=20 >> > 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. >>=20 >> 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.) >>=20 >> The only other device that your pictures show is your >> NVMe device nvd0. >>=20 >> 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? >>=20 >> 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? >>=20 >> Without a device displayed for the LG-v30/SSD there is nothing >> displayed for its reads or writes. This makes the gstat -pd >> useless. >>=20 >> May be the p needs to be omitted for some reason? gstat -d >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > 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. >=20 > Those tests earlier was a huge time sink. > Here's the dmesg output from earlier: > . . . > ---------------------------------- >=20 > I don't know why gstat isn't showing the info u are looking for. >=20 > You said earlier that something was getting deleted,=20 > 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 =46rom 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? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jan 7 20:10:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2AF3E597DD for ; Sun, 7 Jan 2018 20:10:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 6BC04764E3 for ; Sun, 7 Jan 2018 20:10:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 66847 invoked by uid 89); 7 Jan 2018 20:03:57 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 7 Jan 2018 20:03:57 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Running FreeBSD on the Lenovo Thinkpad T470s (success) From: Michael Gmelin X-Mailer: iPhone Mail (14G60) In-Reply-To: <1515354236.1383.6.camel@zoho.com> Date: Sun, 7 Jan 2018 21:03:56 +0100 Cc: "freebsd-current@freebsd.org" , "freebsd-x11@freebsd.org" , "freebsd-mobile@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2DE656BF-161A-4A06-98CA-3B024B2263B4@grem.de> References: <20171230155857.3ba51994@bsd64.grem.de> <1515354236.1383.6.camel@zoho.com> To: clutton X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 20:10:41 -0000 > On 7. Jan 2018, at 20:43, clutton wrote: >=20 >> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >> Hi, >=20 > 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? >=20 > 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. >=20 > 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. >=20 > Here is the device being seen (a lot of pcib*): > pcib5@pci0:6:0:0: class=3D0x060400 card=3D0x11112222 chip=3D0x15d38086 > rev=3D0x02 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge > 4C 2016]' > class =3D bridge > subclass =3D PCI-PCI >=20 >=20 > 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 (us= ually I'm not using a dock though). This means: Mouse, Keyboard can be plugg= ed/unplugged as many time as I want at any point, while displays connected o= ver display port only work when connected before starting X (and they don't d= isappear 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 U= ltra Dock Pro or something - the one that connects at the bottom of the lapt= op). Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned i= nterfaces (which isn't something I wouldn't expect I have to do, but in this= case I had to). -m From owner-freebsd-current@freebsd.org Sun Jan 7 21:28:40 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FB1BE5EBB9 for ; Sun, 7 Jan 2018 21:28:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id ADEC279AE1 for ; Sun, 7 Jan 2018 21:28:38 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 67724 invoked by uid 89); 7 Jan 2018 21:28:38 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 7 Jan 2018 21:28:38 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Running FreeBSD on the Lenovo Thinkpad T470s (success) From: Michael Gmelin X-Mailer: iPhone Mail (14G60) In-Reply-To: <201801072032.w07KWD2V018387@pdx.rh.CN85.dnsmgr.net> Date: Sun, 7 Jan 2018 22:28:37 +0100 Cc: clutton , "freebsd-current@freebsd.org" , "freebsd-x11@freebsd.org" , "freebsd-mobile@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <813101D7-3A67-4C4E-8F3C-301B0AE7A550@grem.de> References: <201801072032.w07KWD2V018387@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 21:28:40 -0000 On 7. Jan 2018, at 21:32, Rodney W. Grimes wrote: >>=20 >>=20 >>>> On 7. Jan 2018, at 20:43, clutton wrote: >>>>=20 >>>> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >>>> Hi, >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Here is the device being seen (a lot of pcib*): >>> pcib5@pci0:6:0:0: class=3D0x060400 card=3D0x11112222 chip=3D0x15d3808= 6 >>> rev=3D0x02 hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge >>> 4C 2016]' >>> class =3D bridge >>> subclass =3D PCI-PCI >>>=20 >>>=20 >>> 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. >>=20 >> 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 plu= gged/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 t= he Ultra Dock Pro or something - the one that connects at the bottom of the l= aptop). >>=20 >> Also, in my setup wifi didn't work without adding iwm0 explicitly to clon= ed interfaces (which isn't something I wouldn't expect I have to do, but in t= his case I had to). >=20 > Did you have a > wlans_iwm0=3D"wlan0" > in /etc/rc.conf? =20 > I do not know or see why putting iwm0 in cloned would do much of anything > for a wlan device. >=20 > Also note that is wlans as in plural, not wlan_iwm0. A mistake I > often make from finger memory. >=20 I have wlans_iwm0=3D"wlan0" ifconfig_wlan0=3D"WPA DHCP country de" in rc.conf. Without adding cloned_interfaces=3D"iwm0" wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's cur= rent r326912, setup like described in my blog post). I just double checked to confirm the behavior. Best, Michael From owner-freebsd-current@freebsd.org Sun Jan 7 22:14:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DB1AE61D75 for ; Sun, 7 Jan 2018 22:14:10 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 4323C7B86C for ; Sun, 7 Jan 2018 22:14:08 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 68189 invoked by uid 89); 7 Jan 2018 22:14:07 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 7 Jan 2018 22:14:07 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Running FreeBSD on the Lenovo Thinkpad T470s (success) From: Michael Gmelin X-Mailer: iPhone Mail (14G60) In-Reply-To: <201801072140.w07Le9xS018601@pdx.rh.CN85.dnsmgr.net> Date: Sun, 7 Jan 2018 23:14:07 +0100 Cc: clutton , "freebsd-current@freebsd.org" , "freebsd-x11@freebsd.org" , "freebsd-mobile@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201801072140.w07Le9xS018601@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 22:14:10 -0000 On 7. Jan 2018, at 22:40, Rodney W. Grimes wrote: >>=20 >>=20 >> On 7. Jan 2018, at 21:32, Rodney W. Grimes wrote: >>=20 >>>>=20 >>>>=20 >>>>>> On 7. Jan 2018, at 20:43, clutton wrote: >>>>>>=20 >>>>>> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >>>>>> Hi, >>>>>=20 >>>>> 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 muc= h >>>>> slower then on my old machines. I'm going to replace the wifi card in >>>>> mean time, any suggestions which one to buy? >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Here is the device being seen (a lot of pcib*): >>>>> pcib5@pci0:6:0:0: class=3D0x060400 card=3D0x11112222 chip=3D0x15d38= 086 >>>>> rev=3D0x02 hdr=3D0x01 >>>>> vendor =3D 'Intel Corporation' >>>>> device =3D 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge >>>>> 4C 2016]' >>>>> class =3D bridge >>>>> subclass =3D PCI-PCI >>>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>> In my setup, plug/unplug events for display port don't work when dockin= g (usually I'm not using a dock though). This means: Mouse, Keyboard can be p= lugged/unplugged as many time as I want at any point, while displays connect= ed over display port only work when connected before starting X (and they do= n'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 th= e laptop). >>>>=20 >>>> Also, in my setup wifi didn't work without adding iwm0 explicitly to cl= oned interfaces (which isn't something I wouldn't expect I have to do, but i= n this case I had to). >>>=20 >>> Did you have a >>> wlans_iwm0=3D"wlan0" >>> in /etc/rc.conf? =20 >>> I do not know or see why putting iwm0 in cloned would do much of anythin= g >>> for a wlan device. >>>=20 >>> Also note that is wlans as in plural, not wlan_iwm0. A mistake I >>> often make from finger memory. >>>=20 >>=20 >> I have >>=20 >> wlans_iwm0=3D"wlan0" >> ifconfig_wlan0=3D"WPA DHCP country de" > I use just simply: > ifconfig_wlan0=3D"WPA SYNCDHCP" >=20 > 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 sen= se, yes. > I do not know of the /etc/rc.d/* stuff is prepared to deal with > your "country de" either. >=20 It is, as country DE shows up in ifconfig after boot and it can actually ass= ociate (which it couldn't before adding the country, probably the channel wa= s out of range with default settings). >>=20 >> in rc.conf. Without adding >>=20 >> cloned_interfaces=3D"iwm0" >>=20 >> wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's c= urrent r326912, setup like described in my blog post). >>=20 >> I just double checked to confirm the behavior. >=20 > Something is broken some place. >=20 Well, if I actually add if_iwm_load=3D"YES" if_iwm3160fw_load=3D"YES" if_iwm7260fw_load=3D"YES" if_iwm7265Dfw_load=3D"YES" if_iwm7265fw_load=3D"YES" if_iwm8000Cfw_load=3D"YES" if_iwm8265fw_load=3D"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 clo= ned_interfaces just did the right thing by loading the correct modules. Sorr= y for creating confusion. -m >> Best, >> Michael >=20 > --=20 > Rod Grimes rgrimes@freebsd= .org From owner-freebsd-current@freebsd.org Sun Jan 7 23:45:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC130E66A4D for ; Sun, 7 Jan 2018 23:45:05 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9973B7ECD9 for ; Sun, 7 Jan 2018 23:45:05 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HkbPOGvh09+vIbmZvnzAjiWJZevlrjX6pmZLAOQis88=; b=NN0pqIn4iR9bznckCqgx+QP1ri 4FC35ZViDyQC+peXDHWFRay+tjMLmcZs4rUZof8TJ0nSKjnsydzHHNbia/5vJwCujRk7f/Q6df+Lg BO95cQ090TATBo+vPEuayhxVk7Sn/K/vwQBBAkvd3arqcDB1WdM8l8zB0YaC1isbPpcWqphFMvZAr I2nnLBy5GjxLVUZ8rgQMqPsgT4AkHXjo6aFxxWLUltcZL01wP4U6KMV75b3YSBUhBZ7TWQCMQCxF9 PBVHE3tRzvs9cuAMTiksUobilV/mkLxAp6dPm5hKkULvyGWGEpldC+D29AOFtP6QO0DyU6f5iSiis zdWDpoIw==; Received: from [136.62.171.86] (port=50146 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eYKcZ-003mXA-M3; Sun, 07 Jan 2018 18:44:55 -0500 From: Jon Brawn Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5C96476C-DBF3-4C3F-87A5-3F62CF4D1C66"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: USB stack Date: Sun, 7 Jan 2018 17:44:53 -0600 In-Reply-To: Cc: Warner Losh , "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current To: blubee blubeeme References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 23:45:05 -0000 --Apple-Mail=_5C96476C-DBF3-4C3F-87A5-3F62CF4D1C66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 6, 2018, at 10:18 PM, blubee blubeeme = wrote: >=20 > On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: >=20 >>=20 >>=20 >> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme >> wrote: >>=20 >>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or = greater >>> and the topic gets derailed...? >>>=20 >>=20 >> Yes, it does. >>=20 >>=20 >>> Are you guys saying that 7-8MB/s is USB speeds? >>>=20 >>=20 >> 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.... >>=20 >> Warner >>=20 >>=20 >>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel = >>> wrote: >>>=20 >>>>=20 >>>>=20 >>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn = wrote: >>>>>> What is an "LG v30"? >>>>>>=20 >>>>> It's a smartphone from LG and only supports USB2 speed. The = reported >>>>> transfer rate is no big surprise. >>>>=20 >>>> OK thanks. >>>>=20 >>>> -- >>>> 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 >>>>=20 >>>>=20 >>> _______________________________________________ >>> 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 >>> " >>>=20 >>=20 >> 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 =3D = 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=3D0x2 > Jan 7 12:06:08 blubee kernel: lock order reversal: > Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait = (bufwait) @ > /usr/src/sys/vm/vm_pager.c:374 > Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > /usr/src/sys/dev/md/md.c:952 > Jan 7 12:06:08 blubee kernel: stack backtrace: > Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > witness_debugger+0x73 > Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > witness_checkorder+0xe02 > Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > lockmgr_lock_fast_path+0x1ae > Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at = VOP_LOCK1_APV+0xd9 > Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at = mdstart_vnode+0x442 > Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at = md_kthread+0x1fe > Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at = fork_trampoline+0xe > Jan 7 12:06:15 blubee kernel: lock order reversal: > Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait = (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3562 > Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash = (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > Jan 7 12:06:15 blubee kernel: stack backtrace: > Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > witness_debugger+0x73 > Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > witness_checkorder+0xe02 > Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at = ufsdirhash_add+0x3d > Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at = ufs_direnter+0x459 > Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at = ufs_makeinode+0x613 > Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at = ufs_create+0x34 > Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at = VOP_CREATE_APV+0xd3 > Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at = vn_open_cred+0x2ad > Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at = kern_openat+0x212 > Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at = amd64_syscall+0x79b > Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at = Xfast_syscall+0xfb >=20 >=20 > Is the slow transfers user error? Wotcha! I don=E2=80=99t see any read or write performance figures anywhere? = Also, is this CURRENT? If so, aren=E2=80=99t all the debug / warning = features that are turned on by default in CURRENT at the moment going to = have an effect on throughput? Especially if you=E2=80=99re writing = through a filesystem where directory and file accesses will each require = a lock to be taken, if only for a short while? If you want to get closer = to the true USB speed of the device, stop mounting it and copying files = to the filesystem, but instead just dd data onto and off of the device = directly, and measure how fast that goes. Remember to backup your data = from the card first=E2=80=A6 Jon. --Apple-Mail=_5C96476C-DBF3-4C3F-87A5-3F62CF4D1C66 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAx MDcyMzQ0NTRaMCMGCSqGSIb3DQEJBDEWBBQJvko3gjzi9UU6RFczsEn2nlWo6zCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBAK5ZMOjD isYsiSZjWexFlXAsfr+xqAX1d9kt0v44D8/5I+RouUTwsw9CtA4lTh6+yR3oIgZq9DlqNqEptS6P ysvZrG4SX9ps7r+1VTbf1FoT575+93M01Hj74B6iURR+1mdaSXcS1DJI0+aydU/FRaCP9DgBneMK Y1FhHcokULkpkBmpN76SRnlCnvfvgh9HgTzdk5a7/bAB7w0k1bMSVUIhVgxjBNw+K8GabzVW0FaG sRUfzw/WdZJ3DFsJjdH59w+/a0SrTOZaT63C8KJVQQwV5zrUeZg4lGW/0/2A9uWl+AWtJ3EdVjF2 yr/dXKHIvzOUYx3kBki4mRGolt6JMnAAAAAAAAA= --Apple-Mail=_5C96476C-DBF3-4C3F-87A5-3F62CF4D1C66-- From owner-freebsd-current@freebsd.org Mon Jan 8 00:03:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCC19E67DC7 for ; Mon, 8 Jan 2018 00:03:33 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86C497F600 for ; Mon, 8 Jan 2018 00:03:33 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=X4Ap952c+Q0wm9wNr4uO4j0q2y+oF2tVBbb0NL8LQFk=; b=bGB8WQcT7Io8T9USlMEQfJsEDi ++AyLoduzNdVXqP+ZdfKxB0TO5dXxSqPPC0arb1+ACeuxWAOv5jx0VsFafdqTgavvzV4kO5GkSIi6 XFK5kf3sWdKt25pAl4y422Wff73WtyvYuGohOKD9AuZDqAhjb+2ElYHMLyQRmkZ3qf5vOnPOKQgca XrzHmYk+/T5bbW/TYAUxk/5S6sv9l7VyBAWsBlICoTYznGFLZdidqJFu04vQqZ0i99e5X4rpSSzyL tamC/m0PcFxQ4xHyncG02sqdmnTbOUCg7QwNFGw95rttdN896SNM0I1jwKCgHerT3ITzBUX6u/9GW IQEED38w==; Received: from [136.62.171.86] (port=50196 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eYKuZ-003pR4-T6; Sun, 07 Jan 2018 19:03:32 -0500 From: Jon Brawn Message-Id: <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1A958660-2232-437F-B619-349CEB870BAF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: USB stack Date: Sun, 7 Jan 2018 18:03:28 -0600 In-Reply-To: Cc: Warner Losh , "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current To: blubee blubeeme References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 00:03:33 -0000 --Apple-Mail=_1A958660-2232-437F-B619-349CEB870BAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 7, 2018, at 5:44 PM, Jon Brawn wrote: >=20 >=20 >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme = wrote: >>=20 >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: >>=20 >>>=20 >>>=20 >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme = >>> wrote: >>>=20 >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or = greater >>>> and the topic gets derailed...? >>>>=20 >>>=20 >>> Yes, it does. >>>=20 >>>=20 >>>> Are you guys saying that 7-8MB/s is USB speeds? >>>>=20 >>>=20 >>> 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.... >>>=20 >>> Warner >>>=20 >>>=20 >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel = >>>> wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn = wrote: >>>>>>> What is an "LG v30"? >>>>>>>=20 >>>>>> It's a smartphone from LG and only supports USB2 speed. The = reported >>>>>> transfer rate is no big surprise. >>>>>=20 >>>>> OK thanks. >>>>>=20 >>>>> -- >>>>> 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 >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> 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 >>>> " >>>>=20 >>>=20 >>> 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 =3D= 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=3D0x2 >> Jan 7 12:06:08 blubee kernel: lock order reversal: >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait = (bufwait) @ >> /usr/src/sys/vm/vm_pager.c:374 >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ >> /usr/src/sys/dev/md/md.c:952 >> Jan 7 12:06:08 blubee kernel: stack backtrace: >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at >> witness_debugger+0x73 >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at >> witness_checkorder+0xe02 >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at >> lockmgr_lock_fast_path+0x1ae >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at = VOP_LOCK1_APV+0xd9 >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at = mdstart_vnode+0x442 >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at = md_kthread+0x1fe >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at = fork_exit+0x84 >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at = fork_trampoline+0xe >> Jan 7 12:06:15 blubee kernel: lock order reversal: >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait = (bufwait) @ >> /usr/src/sys/kern/vfs_bio.c:3562 >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash = (dirhash) @ >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 >> Jan 7 12:06:15 blubee kernel: stack backtrace: >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at >> witness_debugger+0x73 >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at >> witness_checkorder+0xe02 >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at = _sx_xlock+0x68 >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at = ufsdirhash_add+0x3d >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at = ufs_direnter+0x459 >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at = ufs_makeinode+0x613 >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at = ufs_create+0x34 >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at = VOP_CREATE_APV+0xd3 >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at = vn_open_cred+0x2ad >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at = kern_openat+0x212 >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at = amd64_syscall+0x79b >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at = Xfast_syscall+0xfb >>=20 >>=20 >> Is the slow transfers user error? >=20 > Wotcha! >=20 > I don=E2=80=99t see any read or write performance figures anywhere? = Also, is this CURRENT? If so, aren=E2=80=99t all the debug / warning = features that are turned on by default in CURRENT at the moment going to = have an effect on throughput? Especially if you=E2=80=99re writing = through a filesystem where directory and file accesses will each require = a lock to be taken, if only for a short while? If you want to get closer = to the true USB speed of the device, stop mounting it and copying files = to the filesystem, but instead just dd data onto and off of the device = directly, and measure how fast that goes. Remember to backup your data = from the card first=E2=80=A6 >=20 > Jon. >=20 >=20 Also, is the SD card physically inside the phone, and you are using a = USB cord to connect the phone to the FreeBSD computer by any chance? Jon --Apple-Mail=_1A958660-2232-437F-B619-349CEB870BAF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAx MDgwMDAzMjlaMCMGCSqGSIb3DQEJBDEWBBQdnmBV7WyET6lWwg/4xDulLW6P5zCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBAJF22fkk g5F3zPXg+d+u4O7kkyx2hicbOx2ZlRJJeYBPmxwHvPQo5K2SE8HZ2oqqfnp5UmirJBvqqjEk/D2G UMZWRty+Daui5XcYvox4iNqTgjwIP6IzN/zRbtx2xXFh3sObCE+Fnqa+poRIg8Kt9L6ip3cV7YpL T1aec+gH+RA2RyhHHaea0iqW6u27FFwIq7Atibu6/qIm4bLITd0q7yaa83ws9rT/8UlkqFbSJDPQ /J/FCPe4Ecokweq5bkzVikRHclOLrzkJf0Pb/0Qul7Kp+em/SD+oBfYBrljP7BmR+68QnXn8htDE 8DqhW1GumYc6X8wV/yVi0fTfvoZ5LxIAAAAAAAA= --Apple-Mail=_1A958660-2232-437F-B619-349CEB870BAF-- From owner-freebsd-current@freebsd.org Mon Jan 8 00:34:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E44AE69B2B for ; Mon, 8 Jan 2018 00:34:49 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 402DA80AE7; Mon, 8 Jan 2018 00:34:48 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w080OUDi064810; Sun, 7 Jan 2018 16:24:36 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "Michael Tuexen" , "Warner Losh" , "FreeBSD CURRENT" , "O. Hartmann" In-Reply-To: <20180107123201.19ea0fde@thor.intern.walstatt.dynvpn.de> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "O. Hartmann" Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Date: Sun, 07 Jan 2018 16:24:36 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 00:34:49 -0000 On Sun, 7 Jan 2018 12:31:34 +0100 "O=2E Hartmann" sa= id > Am Thu, 4 Jan 2018 12:14:47 +0100 > "O=2E Hartmann" schrieb: >=20 > > On Thu, 4 Jan 2018 09:10:37 +0100 > > Michael Tuexen wrote: > >=20 > > > > On 31=2E Dec 2017, at 02:45, Warner Losh wrote: > > > >=20 > > > > On Sat, Dec 30, 2017 at 4:41 PM, O=2E Hartmann > > wrote: > > > > =20 > > > >> On most recent CURRENT I face the error shwon below on /tmp filesy= stem > > > >> (UFS2) residing > > > >> on a Samsung 850 Pro SSD: > > > >>=20 > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > !=3D > > > >> bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >>=20 > > > >> I've already formatted the /tmp filesystem, but obviously without = any > > > >> success=2E > > > >>=20 > > > >> Since I face such strange errors also on NanoBSD images dd'ed to S= D > > cards, > > > >> I guess there > > > >> is something fishy =2E=2E=2E =20 > > > >=20 > > > >=20 > > > > It indicates a problem=2E We've seen these 'corruptions' on data in m= otion > > 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 fsc= k the > > > > filesystem=2E =20 > > > Not sure this helps: But we have seen this also after system panics > > > when having soft update journaling enabled=2E Having soft update journa= ling > > > disabled, we do not observed this after several panics=2E > > > Just to be clear: The panics are not related to this issue, > > > but to other network development we do=2E > > >=20 > > > You can check using tunefs -p devname if soft update journaling is en= abled > > or > > > not=2E =20 > >=20 > > 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)=2E >=20 >=20 > =2E=2E=2E and journalling as well! >=20 > In case of the SD, I produced the layout of the NanoBSD image via "dd" > including the /cfg > partition=2E The problem occured even when having overwritten the SD card w= ith > a new image=2E > The problem went away once I unmounted /cfg and reformatted via newfs=2E Af= ter > 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 th= e > procedure > restored something faulty=2E >=20 > 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=2E The > partition has > been created and formatted months ago under CURRENT=2E >=20 > In single user mode, I reformatted the partition again - with journaling = and > softupdates > enabled=2E As with the /cfg partition on NanoBSD with SD card, I didn't rea= lise > any faults > again since then=2E=20 FWIW I *also* experience this on gpart/FFS2 partitioned/formatted drives *with* journaling enabled=2E 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=2E This is on a SATA (ahci) driven disk=2E My experiences with this seem to suggest that journaling is the cause= =2E >=20 > >=20 > >=20 > > >=20 > > > Best regards > > > Michael =20 > > > >=20 > > > > Warner > --=20 > O=2E Hartmann >=20 > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3= =BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s=2E 4 BDSG)=2E --Chris From owner-freebsd-current@freebsd.org Mon Jan 8 00:51:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1B7FE6AAFD for ; Mon, 8 Jan 2018 00:51:54 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A38D0812DC for ; Mon, 8 Jan 2018 00:51:54 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w080pvA2066104; Sun, 7 Jan 2018 16:52:03 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Ronald Klop" Subject: Re: status-mail-rejects: appears to be broken Date: Sun, 07 Jan 2018 16:52:03 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 00:51:54 -0000 On Sun, 07 Jan 2018 14:13:01 +0100 "Ronald Klop" sai= d > On Sun, 17 Dec 2017 20:50:23 +0100, Chris H wrot= e: >=20 > > 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=3Dhost] > > [--ca-cert=3Dfile] [--ca-path=3Ddir] [--cert=3Dfile] [--crl=3Dfi= le] > > [-i file] [--key=3Dfile] [-N file] [--no-passive] [--no-proxy=3D= list] > > [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] =20 > > [--no-verify-peer] > > [-o file] [--referer=3DURL] [-S bytes] [-T seconds] > > [--user-agent=3Dagent-string] [-w seconds] URL =2E=2E=2E > > fetch [-146AadFlMmnPpqRrsUv] [-B bytes] [--bind-address=3Dhost] > > [--ca-cert=3Dfile] [--ca-path=3Ddir] [--cert=3Dfile] [--crl=3Dfi= le] > > [-i file] [--key=3Dfile] [-N file] [--no-passive] [--no-proxy=3D= list] > > [--no-sslv3] [--no-tlsv1] [--no-verify-hostname] =20 > > [--no-verify-peer] > > [-o file] [--referer=3DURL] [-S bytes] [-T seconds] > > [--user-agent=3Dagent-string] [-w seconds] -h host -f file [-c d= ir] > > > > Also, 520=2Epfdenied doesn't produce any output=2E In fact, it doesn't appe= ar > > to be run at all=2E > > > > Any thoughts, or advice on how to best proceed? > > > > Thanks! > > > > --Chris >=20 > This looks the same as what I experienced=2E It will be fixed by upgrading = =20 > until at least this commit: >=20 > http://www=2Esecnetix=2Ede/olli/FreeBSD/svnews/index=2Epy?r=3D326343 It appears that you indicate anything past, or including r326343 resolves t= his I'll look into it=2E But FWIW I was able to get etc/periodic/security/520=2Epfdenied output workin= g with the following diff(1): --- /etc/periodic/security/520=2Epfdenied=2Eorig=092017-11-21 06:57:04=2E00000000= 0 -0800 +++ /etc/periodic/security/520=2Epfdenied=092017-03-29 16:22:50=2E000000000 -07= 00 @@ -24,7 +24,7 @@ # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE=2E # -# $FreeBSD: head/etc/periodic/security/520=2Epfdenied 306696 2016-10-04 23:1= 2:35Z lidl $ +# $FreeBSD: head/etc/periodic/security/520=2Epfdenied 290405 2015-11-05 17:3= 7:14Z lidl $ # =20 # If there is a global system configuration file, suck it in=2E @@ -44,13 +44,8 @@ if check_yesno_period security_status_pfdenied_enable then =09TMP=3D`mktemp -t security` -=09for _a in "" $(pfctl -a "blacklistd" -sA 2>/dev/null) -=09do -=09=09pfctl -a ${_a} -sr -v -z 2>/dev/null | \ -=09=09nawk '{if (/^block/) {buf=3D$0; getline; gsub(" +"," ",$0); if ($5 >= 0) print buf$0;} }' >> ${TMP} -=09done -=09if [ -s ${TMP} ]; then -=09=09check_diff new_only pf ${TMP} "${host} pf denied packets:" +=09if pfctl -sr -v 2>/dev/null | nawk '{if (/^block/) {buf=3D$0; getline; = gsub(" +"," ",$0); print buf$0;} }' > ${TMP}; then +=09 check_diff new_only pf ${TMP} "${host} pf denied packets:" =09fi =09rc=3D$? =09rm -f ${TMP} Thanks for taking the time to reply, Ronald! >=20 > Ronald=2E >=20 >=20 --Chris From owner-freebsd-current@freebsd.org Mon Jan 8 04:07:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FA51E73ED2 for ; Mon, 8 Jan 2018 04:07:15 +0000 (UTC) (envelope-from mykel@mWare.ca) Received: from Vice.ServerNorth.net (vice.ServerNorth.net [209.44.123.194]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5B938F8 for ; Mon, 8 Jan 2018 04:07:15 +0000 (UTC) (envelope-from mykel@mWare.ca) Received: from mail.servernorth.net (localhost [127.0.0.1]) by Vice.ServerNorth.net (Postfix) with ESMTP id 7F20156860 for ; Sun, 7 Jan 2018 23:05:49 -0500 (EST) Received: from mykel@mWare.ca by mail.servernorth.net (Archiveopteryx 3.1.4) with esmtpsa id 1515384347-54584-54581/9/3; Sun, 7 Jan 2018 23:05:47 -0500 To: freebsd-current@freebsd.org From: mykel@mWare.ca Subject: Make periodic's output log to files if sendmail is disabled on install Message-Id: Date: Sun, 7 Jan 2018 23:05:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-CA X-Mailman-Approved-At: Mon, 08 Jan 2018 04:14:53 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 04:07:15 -0000 1) if sendmail is disabled during installation, have periodic's output=20 logged to files (per example in=20 https://www.freebsd.org/cgi/man.cgi?periodic(8) ) 2) make this the default anyway (logging to files), arguably the vast=20 majority of systems' reporting is ignored :) At least now it could be logrotated out! [22:54.53]=C2=A0 AllanJude: will you make the installer smart = that if=20 the user disables sendmail, that periodic's output will be sent to=20 logfiles instead? [22:55.17]=C2=A0 not sure how doable that is [22:57.20]=C2=A0 AllanJude:=20 https://www.freebsd.org/cgi/man.cgi?periodic(8) <-- see examples [22:57.55]=C2=A0 ohh [22:57.57]=C2=A0 ok then [22:58.04]=C2=A0 should be fairly easy to do then [23:00.02]=C2=A0 AllanJude: I'd argue logging periodic to files = should=20 become the default since I'm willing to bet 99% of fBSD machines' output=20 is ignored. [23:00.34]=C2=A0 Myke: that is a reasonable idea for freebsd = 12 [23:00.42]=C2=A0 :) [23:00.55]=C2=A0 want to email that to freebsd-current@freebs= d.org [23:00.57]=C2=A0 and then i'll do it ;) From owner-freebsd-current@freebsd.org Mon Jan 8 05:09:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3535BE77144 for ; Mon, 8 Jan 2018 05:09:39 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CAAE691A0; Mon, 8 Jan 2018 05:09:38 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w0859fWS078564; Sun, 7 Jan 2018 21:09:47 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "Michael Tuexen" , "Warner Losh" , "O. Hartmann" In-Reply-To: <20180107123201.19ea0fde@thor.intern.walstatt.dynvpn.de> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD CURRENT" Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Date: Sun, 07 Jan 2018 21:09:47 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 05:09:39 -0000 On Sun, 7 Jan 2018 12:31:34 +0100 "O=2E Hartmann" sa= id > Am Thu, 4 Jan 2018 12:14:47 +0100 > "O=2E Hartmann" schrieb: >=20 > > On Thu, 4 Jan 2018 09:10:37 +0100 > > Michael Tuexen wrote: > >=20 > > > > On 31=2E Dec 2017, at 02:45, Warner Losh wrote: > > > >=20 > > > > On Sat, Dec 30, 2017 at 4:41 PM, O=2E Hartmann > > wrote: > > > > =20 > > > >> On most recent CURRENT I face the error shwon below on /tmp filesy= stem > > > >> (UFS2) residing > > > >> on a Samsung 850 Pro SSD: > > > >>=20 > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > !=3D > > > >> bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451= 5d2a3 > > > >> !=3D bp: 0xd9fba319 > > > >> handle_workitem_freefile: got error 5 while accessing filesystem > > > >>=20 > > > >> I've already formatted the /tmp filesystem, but obviously without = any > > > >> success=2E > > > >>=20 > > > >> Since I face such strange errors also on NanoBSD images dd'ed to S= D > > cards, > > > >> I guess there > > > >> is something fishy =2E=2E=2E =20 > > > >=20 > > > >=20 > > > > It indicates a problem=2E We've seen these 'corruptions' on data in m= otion > > 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 fsc= k the > > > > filesystem=2E =20 > > > Not sure this helps: But we have seen this also after system panics > > > when having soft update journaling enabled=2E Having soft update journa= ling > > > disabled, we do not observed this after several panics=2E > > > Just to be clear: The panics are not related to this issue, > > > but to other network development we do=2E > > >=20 > > > You can check using tunefs -p devname if soft update journaling is en= abled > > or > > > not=2E =20 > >=20 > > 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)=2E >=20 >=20 > =2E=2E=2E and journalling as well! >=20 > In case of the SD, I produced the layout of the NanoBSD image via "dd" > including the /cfg > partition=2E The problem occured even when having overwritten the SD card w= ith > a new image=2E > The problem went away once I unmounted /cfg and reformatted via newfs=2E Af= ter > 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 th= e > procedure > restored something faulty=2E >=20 > 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=2E The > partition has > been created and formatted months ago under CURRENT=2E >=20 > In single user mode, I reformatted the partition again - with journaling = and > softupdates > enabled=2E As with the /cfg partition on NanoBSD with SD card, I didn't rea= lise > any faults > again since then=2E=20 >=20 FWIW I *also* experience this on gpart/FFS2 partitioned/formatted drives *with* journaling enabled=2E 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=2E This is on a SATA (ahci) driven disk=2E My experiences with this seem to suggest that journaling is the cause= =2E > >=20 > >=20 > > >=20 > > > Best regards > > > Michael =20 > > > >=20 > > > > Warner > --=20 > O=2E Hartmann >=20 > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3= =BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s=2E 4 BDSG)=2E --Chris From owner-freebsd-current@freebsd.org Mon Jan 8 05:17:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CB58E7761C for ; Mon, 8 Jan 2018 05:17:24 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2BC6962C for ; Mon, 8 Jan 2018 05:17:24 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id f143so7951474itb.0 for ; Sun, 07 Jan 2018 21:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BHQV0Kp1UyhkPFMg7NqeFxCy2juyaUswJpQumvY1vBM=; b=oLhox9Dswo4ZCusUVvqO3Pzo+4+9R6HhMFI2ZmlQH6OhzcGaRjCU6EjbGQ3YYTeczL /8Fz3pBd6TJc3vIu20GbCEVuQIG639X45EInImWYQC0U0xmrlU2Eb60t6GUpmqXAlC1N VXEVHe7+dJYtx4s47ACeiLlnqeBzgtRHWjtUC66gUp1HBbXenAKkugXQ6zvE5SsY3NHV CDeyPEUxUxNqwLcuNQeAMoliu5qRSH9gXare4YyqGcmlIUmMNa0D8dYn+ujGoyxXUo4r Cpxy/4gx8T0PSAAJOx3sskFXjGz81sStLMxVwQ1i4WFDC1bn4X0+v9F9cq2eFoXjxU1r Fyog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BHQV0Kp1UyhkPFMg7NqeFxCy2juyaUswJpQumvY1vBM=; b=EZQHHt176MNgD47XTz0Sh1GVPLluqPUTt63QNxNwokg0QvxyoVUchbhfuIDsicwNux 1nQ9lH9b6Grcu6X3rDs6+iIuzL1VRwHNSDqJLJCZjmAijAvUM87S1Wa1T5P2ifo12hIW 6djJ56iYxNnI7nFxHet4K+z2KUn8DG1G/tHCDbEEOlU7gd15CPiAoAEP22MVFtwBoX/9 zK56vGyUyQYVzAVE6efrGtEXkvA4QdMwvZ9QFRl+6tBNJ6wzsz6Di4UomxIxHcYyKBM0 2ZW41Uf0POBzgrWWeMKq3hOPP/s7QJuF4ayF9BHbPuKQqmUcHlowQ2gAm7xk/q2hQrvl TEbg== X-Gm-Message-State: AKGB3mLgjI5BFrZQL6oSNx3z3Mqkt6zMH+EHh/kpIsdrhO6Wwh73TeUi PzGJGn9nVfw6RDJAny2+56dp1Be2N2Q549fGcpU= X-Google-Smtp-Source: ACJfBotD3jHhwNzk5qFBaFZ3VdxONu8ghPLKxlvCiYocun0TDUnygkhlyYpZK93mJodPT4XU45jkAYTIO1l3JeiAiPg= X-Received: by 10.36.112.65 with SMTP id f62mr10394441itc.51.1515388643519; Sun, 07 Jan 2018 21:17:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Sun, 7 Jan 2018 21:17:22 -0800 (PST) In-Reply-To: <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org> From: blubee blubeeme Date: Mon, 8 Jan 2018 13:17:22 +0800 Message-ID: Subject: Re: USB stack To: Jon Brawn Cc: Warner Losh , "O'Connor, Daniel" , gljennjohn@gmail.com, FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 05:17:24 -0000 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 = =3D > 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 Direc= t > >> 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=3D0x2 > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait > (bufwait) @ > >> /usr/src/sys/vm/vm_pager.c:374 > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > >> /usr/src/sys/dev/md/md.c:952 > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > >> lockmgr_lock_fast_path+0x1ae > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at > VOP_LOCK1_APV+0xd9 > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > mdstart_vnode+0x442 > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1= fe > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > fork_trampoline+0xe > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait > (bufwait) @ > >> /usr/src/sys/kern/vfs_bio.c:3562 > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash > (dirhash) @ > >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > ufsdirhash_add+0x3d > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at > ufs_direnter+0x459 > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > ufs_makeinode+0x613 > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x3= 4 > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > VOP_CREATE_APV+0xd3 > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at > vn_open_cred+0x2ad > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at > kern_openat+0x212 > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > amd64_syscall+0x79b > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > Xfast_syscall+0xfb > >> > >> > >> Is the slow transfers user error? > > > > Wotcha! > > > > I don=E2=80=99t see any read or write performance figures anywhere? Als= o, is > this CURRENT? If so, aren=E2=80=99t all the debug / warning features that= are > turned on by default in CURRENT at the moment going to have an effect on > throughput? Especially if you=E2=80=99re writing through a filesystem whe= re > directory and file accesses will each require a lock to be taken, if only > for a short while? If you want to get closer to the true USB speed of the > device, stop mounting it and copying files to the filesystem, but instead > just dd data onto and off of the device directly, and measure how fast th= at > goes. Remember to backup your data from the card first=E2=80=A6 > > > > Jon. > > > > > > Also, is the SD card physically inside the phone, and you are using a USB > cord to connect the phone to the FreeBSD computer by any chance? > > Jon > > @Mark Millard I use sysutils/simple-mtpfs to mount the android device. when I mount the phone through USB this is the relevant section: /dev/fuse 356311 78912 277398 22% /mnt That's the most complicated mount process that I use, for the ssd it's just a simple mount /dev/device /mnt relevant output: /dev/da0 923913 121450 728550 14% /mnt Can you tell me what information you're looking for so that I can gather it all up and send it. @Jon Brawn I am running current because I handle admin a few other boxes that are on RELEASE so I have to run in current to make sure they don't have it. I do wonder about those locks as well but, they should only affect the multiple small files, not so much the larger files. The microsd card is physically inside the phone. From owner-freebsd-current@freebsd.org Mon Jan 8 05:33:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B336AE78778 for ; Mon, 8 Jan 2018 05:33:51 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EC226A1B0 for ; Mon, 8 Jan 2018 05:33:49 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w085Xt04079777; Sun, 7 Jan 2018 21:34:01 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: Subject: Re: Make periodic's output log to files if sendmail is disabled on install Date: Sun, 07 Jan 2018 21:34:01 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 05:33:51 -0000 On Sun, 7 Jan 2018 23:05:44 -0500 said > 1) if sendmail is disabled during installation, have periodic's output=20 > logged to files (per example in=20 > https://www=2Efreebsd=2Eorg/cgi/man=2Ecgi?periodic(8) ) >=20 > 2) make this the default anyway (logging to files), arguably the vast=20 > majority of systems' reporting is ignored :) > At least now it could be logrotated out! Hmm, if they are "arguably" already ignoring their system emails=2E 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=2E >=20 >=20 >=20 > [22:54=2E53]=C2=A0 AllanJude: will you make the installer smart that= if=20 > the user disables sendmail, that periodic's output will be sent to=20 > logfiles instead? > [22:55=2E17]=C2=A0 not sure how doable that is > [22:57=2E20]=C2=A0 AllanJude:=20 > https://www=2Efreebsd=2Eorg/cgi/man=2Ecgi?periodic(8) <-- see examples > [22:57=2E55]=C2=A0 ohh > [22:57=2E57]=C2=A0 ok then > [22:58=2E04]=C2=A0 should be fairly easy to do then > [23:00=2E02]=C2=A0 AllanJude: I'd argue logging periodic to files sh= ould=20 > become the default since I'm willing to bet 99% of fBSD machines' output= =20 > is ignored=2E > [23:00=2E34]=C2=A0 Myke: that is a reasonable idea for freebsd = 12 > [23:00=2E42]=C2=A0 :) > [23:00=2E55]=C2=A0 want to email that to freebsd-current@freebs= d=2Eorg > [23:00=2E57]=C2=A0 and then i'll do it ;) >=20 --Chris From owner-freebsd-current@freebsd.org Mon Jan 8 05:40:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AD4EE78B57 for ; Mon, 8 Jan 2018 05:40:33 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 079B46A43A for ; Mon, 8 Jan 2018 05:40:32 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w085eI7k080096; Sun, 7 Jan 2018 21:40:24 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "Warner Losh" , "OConnor, Daniel" , , "FreeBSD current" , "Jon Brawn" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "blubee blubeeme" Subject: Re: USB stack Date: Sun, 07 Jan 2018 21:40:24 -0800 Message-Id: <91e0e215f2568bc8f9d00988b7eaeae7@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 05:40:33 -0000 On Mon, 8 Jan 2018 13:17:22 +0800 "blubee blubeeme" s= aid > On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn wrote: >=20 > > > > > > > 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=2E0 or > > greater > > >>>> and the topic gets derailed=2E=2E=2E? > > >>>> > > >>> > > >>> Yes, it does=2E > > >>> > > >>> > > >>>> Are you guys saying that 7-8MB/s is USB speeds? > > >>>> > > >>> > > >>> I've gotten up to 24MB/s for maybe a decade=2E That's not possible wi= th > > USB > > >>> 1=2Ex=2E More recently, I've maxed out the writes on a USB stick at abo= ut > > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2=2E0=2E= =2E=2E > > I've > > >>> not tried USB3 with an SSD that can do more=2E=2E=2E=2E > > >>> > > >>> 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=2E The > > reported > > >>>>>> transfer rate is no big surprise=2E > > >>>>> > > >>>>> OK thanks=2E > > >>>>> > > >>>>> -- > > >>>>> Daniel O'Connor > > >>>>> "The nice thing about standards is that there > > >>>>> are so many of them to choose from=2E" > > >>>>> -- Andrew Tanenbaum > > >>>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE= 8C > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> freebsd-current@freebsd=2Eorg mailing list > > >>>> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd=2Eorg > > >>>> " > > >>>> > > >>> > > >>> 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=2E00/80=2E00, addr 4> on usbus0 > > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = =3D > > 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 Dir= ect > > >> 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=2E000MB/s transfers > > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > > sectors) > > >> Jan 7 11:56:56 blubee kernel: da0: quirks=3D0x2 > > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait > > (bufwait) @ > > >> /usr/src/sys/vm/vm_pager=2Ec:374 > > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > > >> /usr/src/sys/dev/md/md=2Ec:952 > > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > > >> lockmgr_lock_fast_path+0x1ae > > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at > > VOP_LOCK1_APV+0xd9 > > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x6= 6 > > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > > mdstart_vnode+0x442 > > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0= x1fe > > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x= 84 > > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > > fork_trampoline+0xe > > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait > > (bufwait) @ > > >> /usr/src/sys/kern/vfs_bio=2Ec:3562 > > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash > > (dirhash) @ > > >> /usr/src/sys/ufs/ufs/ufs_dirhash=2Ec:281 > > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x= 68 > > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > > ufsdirhash_add+0x3d > > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at > > ufs_direnter+0x459 > > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > > ufs_makeinode+0x613 > > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0= x34 > > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > > VOP_CREATE_APV+0xd3 > > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at > > vn_open_cred+0x2ad > > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at > > kern_openat+0x212 > > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > > amd64_syscall+0x79b > > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > > Xfast_syscall+0xfb > > >> > > >> > > >> Is the slow transfers user error? > > > > > > Wotcha! > > > > > > I don=E2=80=99t see any read or write performance figures anywhere? A= lso, is > > this CURRENT? If so, aren=E2=80=99t all the debug / warning features th= at are > > turned on by default in CURRENT at the moment going to have an effect o= n > > throughput? Especially if you=E2=80=99re writing through a filesystem w= here > > directory and file accesses will each require a lock to be taken, if on= ly > > for a short while? If you want to get closer to the true USB speed of t= he > > device, stop mounting it and copying files to the filesystem, but inste= ad > > just dd data onto and off of the device directly, and measure how fast = that > > goes=2E Remember to backup your data from the card first=E2=80=A6 > > > > > > Jon=2E > > > > > > > > > > Also, is the SD card physically inside the phone, and you are using a U= SB > > cord to connect the phone to the FreeBSD computer by any chance? > > > > Jon > > > > @Mark Millard > I use sysutils/simple-mtpfs to mount the android device=2E > when I mount the phone through USB this is the relevant section: > /dev/fuse 356311 78912 277398 22% > /mnt >=20 > That's the most complicated mount process that I use, > for the ssd it's just a simple mount /dev/device /mnt > relevant output: > /dev/da0 923913 121450 728550 14% > /mnt >=20 > Can you tell me what information you're looking for so that I can gather = it > all up and send it=2E >=20 > @Jon Brawn > I am running current because I handle admin a few other boxes that are on > RELEASE so I have > to run in current to make sure they don't have it=2E It's not CURRENT that's the problem, but GENERIC (WITNESS et al; that cause= s contention) -- see; performance loss=2E :-) > I do wonder about those locks as well but, they should only affect the > multiple small files, > not so much the larger files=2E >=20 > The microsd card is physically inside the phone=2E --Chris From owner-freebsd-current@freebsd.org Mon Jan 8 06:58:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02FD5E7BB76 for ; Mon, 8 Jan 2018 06:58:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65ED86CB11 for ; Mon, 8 Jan 2018 06:58:27 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Me8di-1eFFJN28kg-00PtyX for ; Mon, 08 Jan 2018 07:58:19 +0100 Date: Mon, 8 Jan 2018 07:58:13 +0100 From: "O. Hartmann" To: freebsd-current Subject: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 Message-ID: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:263d2egKAS2KiJ2KxT+u1jsVuzePbT4MZ9Ze9ghMxt1Ine2t7LW wjg4bo3qM7Ykh+Oeu8MWayczT1ALtkrW5hWrR+dFYWI8zN5D5z1L7B7RLAxSqjXHC6KlCX9 WwmOtkNVWFFg2PXPqlarM6PcGBxH93gNNgWL49n3lETIk5aLt4itGk0+jiX8WK1F2tah79i 3lgP7NXEHEPTr63VqbxVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Yxxl8+rOTxc=:OEN8kk4JYEOJR8nddH9iGC KxuR2dZasF0WbOz0quP1SaIr1b1OVUCOxuU+HV1Zzcds/XatD3OaOjX8EVFFUwWDMKbbZh8gN avi/IRpVWiffmb1q0ero6Bh4RfFIPHqsmVdx+rRA2e95a53/LTAlUNFcjqonRWkNfoVTEQ80e NEyFZnV2ujSDgPW+yr14a5CQDxfSKmFBdIf5xtUoNmogTM6Fwo7G9ajhqI34klNwZHEeEQYpW 4LDv06aStJC/rcLgjMrqO7EpoIsuVC1U0QrfznzOcbG3UdaOOpzfZ3p/p2YuZWu7YS5g55htZ b48FinVN7+PcmXHMey2UlrnKx5M7O1N9SgfMFKvd/cTdiXSiO7BKwRG+psrCDE7lRGSihCAq0 sFfj8sZZu+cN8MDTc2ZS9WrAiwLRUwkwgnLWRKfA7oLMfZAbXXLEoBJvh1XT7VFtl3/mPbwst bwhTd+jtdORGBeW6Mix+8Ps3KvVOhdopTCcjsIreM6sxsIbwc0KfTTW9xWvYQrJ9agDvXPav2 qxj/CLl6JyOoXNn/HhHvTyERcvm0pjcHyTd9MM/elkwEgkj029+i/aMTOir15oPSaGLKO+yxc CzvLIIkDP3Ph/TE7mMtz3STk8dUuz2lY1XwLFyKip1GGNC5TBA0vXG00ylb/t90FULcd8fXOx XBDQNaFvpGLRMoh5fp06gokcIzr3hJC+IgARJ0DVRajUmAwQ2jWkrnbGaLjao8udfL3BG6ORA CgXOBNSPKfYHlNz6gkshfHWoyuDzlIq7xJovgYFexeGY9V3ARRlfTodDmnsuA7bVwOkqGvjgc 3KeAt8nR61sj5TvKgJmmxFgpn16NulqLHi2uirM+IkGo9zZbNg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 06:58:29 -0000 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 From owner-freebsd-current@freebsd.org Mon Jan 8 07:07:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6478DE7C242 for ; Mon, 8 Jan 2018 07:07:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28A746D06B for ; Mon, 8 Jan 2018 07:07:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id n14so11887968iob.4 for ; Sun, 07 Jan 2018 23:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BkDUKa5ODjEfHxh6WIg4/VMN/wJ9wPgP4vGl9t9SAnM=; b=rYtetXsVWi1zkG5eZsXLEUXN2qUMqgOPnuovmK/trZcCSIeXkoReXRknlq07GuLI56 G11PmNDl59QL49EFr/hwMIfPydMhd8rjRbRt7T6qM+YcvYFvSmOb8zsa4kRm6PQe7AaY W3nC4NMO8ig5LgNLWWgooluB5Qom00xpq6hyX9Yagc9QQ1i1HMNNX7ThFspANZYTqGys dCkE2SUMg010K23atipsKaFwmBN5maGTuZIXouX6JqLhc+mOgoHmvxclYAoqPwrSxv7h ckFgY8XAgT4YZ2ccrSOzPNOq9SbURhv9Lkf+nwdmGt0ik+7UxPMXhzkm79T21Sy4aNjy hjyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BkDUKa5ODjEfHxh6WIg4/VMN/wJ9wPgP4vGl9t9SAnM=; b=oyQkp5vQYKqFnNVS4KXpxofhlKILFR+YhMJw8MCrWoeZszpiIYR//qWawkpZ1mwFNz W31XrAP1ziUB0BovnpxaePw4gRVWeJuctDJ8zNp8blQyTpuBx5FsEQhdguK4RjJpGAHL oDzo+BhfWTYDDr2koKMvPFl7QoYj7Y7zofDm2Qh15DTkx3rMNllAwZ76PDWlR1EM/9Z3 7AUVyartzcGOridxyK4T8EEhKxhlMUj6qODXGSojEkUTneId66zxlu7q70ESCoo6GBUT v8ac5Gn6Bwk5bIQL9pmxfdTrB1z0Q0dAbkBxzSnCzML5/3t1Ry7erB8xhnJ+uCsSI1+O xrjg== X-Gm-Message-State: AKGB3mLRKfzQvuju6jMH/MJQ58bZVdO89XhoDA+bPU86D1rjhTHS/82J xlbELVCDyCi35AYPJR7bsXx4S8wHcs7/tJKm/BGzYQ== X-Google-Smtp-Source: ACJfBougC5aSNcxL9Xknn103qssJ5/mKJWIDGae0+en4f55wNejQCT+gGKvkbcP1wiKe+NuKuDvxd/D8axx4o+bM33w= X-Received: by 10.107.142.143 with SMTP id q137mr10691922iod.301.1515395274190; Sun, 07 Jan 2018 23:07:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Sun, 7 Jan 2018 23:07:53 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:a84a:1e5c:a3af:9943] Received: by 10.79.160.217 with HTTP; Sun, 7 Jan 2018 23:07:53 -0800 (PST) In-Reply-To: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> From: Warner Losh Date: Mon, 8 Jan 2018 00:07:53 -0700 X-Google-Sender-Auth: D0hORHjtYrBSZscSAO8tXrT_dC4 Message-ID: Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 To: "O. Hartmann" Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:07:55 -0000 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-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Jan 8 07:20:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1865E7CBD6 for ; Mon, 8 Jan 2018 07:20:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-134.reflexion.net [208.70.210.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6686D6E4 for ; Mon, 8 Jan 2018 07:20:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3560 invoked from network); 8 Jan 2018 07:20:21 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Jan 2018 07:20:21 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Mon, 08 Jan 2018 02:20:21 -0500 (EST) Received: (qmail 14705 invoked from network); 8 Jan 2018 07:20:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jan 2018 07:20:20 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 48D28EC8BF3; Sun, 7 Jan 2018 23:20:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> Date: Sun, 7 Jan 2018 23:20:19 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <899567F7-0C02-4A60-ADA0-5F43A6CF594B@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:20:28 -0000 [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: >=20 >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme = wrote: >>=20 >>=20 >>=20 >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard wrote: >>>=20 >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme = wrote: >>>>=20 >>>>> I ran this test and here's some results. >>>>> gstat -pd images: >>>>>=20 >>>>> 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 >>>>>=20 >>>>> 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 >>>>>=20 >>>>> as far as why there's such high deletions? I can't say I'm only = using cp. >>>>=20 >>>> 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.) >>>>=20 >>>> The only other device that your pictures show is your >>>> NVMe device nvd0. >>>>=20 >>>> 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? >>>>=20 >>>> 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? >>>>=20 >>>> Without a device displayed for the LG-v30/SSD there is nothing >>>> displayed for its reads or writes. This makes the gstat -pd >>>> useless. >>>>=20 >>>> May be the p needs to be omitted for some reason? gstat -d >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>=20 >>> 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. >>>=20 >>> Those tests earlier was a huge time sink. >>> Here's the dmesg output from earlier: >>> . . . >>> ---------------------------------- >>>=20 >>> I don't know why gstat isn't showing the info u are looking for. >>>=20 >>> You said earlier that something was getting deleted,=20 >>> I don't know what could be causing that. >>=20 >> Those "deletes" are more commonly called TRIM on SSD's. >> FreeBSD called them, BIO_DELETE as I remember. >>=20 >> Those deletes have nothing to do with umounting, deleteing >> devices, etc. >>=20 >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... >>> Even say forget the mobile device and go from >>> zpool >>=20 >> =46rom which I've not been able to figure out the kind of >> information that I'm looking for. >>=20 >> 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. >>=20 >>> 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? >>=20 >> 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. >>=20 >> If you wish to keep trying to help me help you, . . . >>=20 >> 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.) >>=20 >> 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.) >>=20 >> (I would expect these are mount commands, or at least >> involve mount commands/calls. Some of the following makes >> that presumption.) >>=20 >> For each of those: with the device available show the >> output of: >>=20 >> mount >>=20 >> and of: >>=20 >> df -m >>=20 >> 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. >>=20 >> (You can for now stop the commands early or just >> not start any that would take a long time.) >>=20 >> 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? >=20 [Extracted from a reply to a Jon Brawn post.] > @Mark Millard > I use sysutils/simple-mtpfs to mount the android device. > when I mount the phone through USB this is the relevant section: > /dev/fuse 356311 78912 277398 22% > /mnt >=20 > That's the most complicated mount process that I use, > for the ssd it's just a simple mount /dev/device /mnt > relevant output: > /dev/da0 923913 121450 728550 = 14% > /mnt >=20 > Can you tell me what information you're looking for so that I can = gather it > all up and send it. I do not find a /usr/ports/sysutils/simple-mtpfs . But I do find: # ls -lTd /usr/ports/sysutils/*simple* drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 = /usr/ports/sysutils/fusefs-simple-mtpfs And that was very important to know. I had to look it up but this means that you are using the Media Transfer Protocol (MTP) to transfer files from the LG v30. It also means that part of that involves use of the Filesystem in USErspace (FUSE). The two would be likely to add overheads that slow things down (extra stages/steps in getting the bytes copied). [Apparently MTP is an extension to the Picture Transfer Protocol (PTP) communications protocol. MTP has been standardized as a full-fledged USB device class but originated with Microsoft.] [MTP use involves putting the Android device into MTP mode, frequently referenced in the Android UI via a selection of "USB for file transfer" someplace in the user interface (according to what I read).] One example of why FreeBSD and sysutils/fusefs-simple-mtpfs and sysutils/fusefs-libs and multimedia/libmtp might be slower than some linux software is: It appears that some Linux software has implemented "USB 'Zerocopy' support found in recent Linux kernel" (and, so, avoid user-space vs. kernel space data copying and some context switching). I doubt that FreeBSD and its sysutils/fusefs-simple-mtpfs and sysutils/fusefs-libs and multimedia/libmtp combination happen to do that. This difference likely would make a notable speed difference for the transfer and save to local file system (if my doubt is correct). It is not surprising that the speeds would be far less than the experiments that I reported. I do not have a context to experiment with the consequences of using sysutils/fusefs-simple-mtpfs and what it requires (fusefs-libs and libmtp). I'm afraid I'll not be able to be much help relative to the LG v30 MTP-based transfer performance investigations. That leaves the SSD context. Is there anything that you still want to investigate relative to the SSD usage? Or is there no point because of the LG v30 status? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Jan 8 07:46:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18852E7E28A for ; Mon, 8 Jan 2018 07:46:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EDA8D6E912 for ; Mon, 8 Jan 2018 07:46:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w087l2Wr035646 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2018 07:47:03 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w087kblk034312 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2018 23:46:38 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 7 Jan 2018 23:46:32 -0800 (PST) From: Don Lewis Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 To: "O. Hartmann" cc: freebsd-current In-Reply-To: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> Message-ID: References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:46:47 -0000 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-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jan 8 07:49:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F782E7E62B for ; Mon, 8 Jan 2018 07:49:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D93246ECD4 for ; Mon, 8 Jan 2018 07:49:45 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w087o0GO035649 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2018 07:50:01 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w087kbln034312 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2018 23:49:37 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 7 Jan 2018 23:49:36 -0800 (PST) From: Don Lewis Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 To: Warner Losh cc: "O. Hartmann" , FreeBSD Current In-Reply-To: Message-ID: References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:49:46 -0000 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-unsubscribe@freebsd.org" >> > _______________________________________________ > 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" From owner-freebsd-current@freebsd.org Mon Jan 8 09:15:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0BE7E5D73A for ; Mon, 8 Jan 2018 09:15:44 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71F8471D66 for ; Mon, 8 Jan 2018 09:15:44 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id z130so12215088ioe.13 for ; Mon, 08 Jan 2018 01:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0uhFUfNaMLDnocl9QFbYmL5Wvt9QqobpzwSBYs2kZHk=; b=orfnv1CRCsm7Eg8zRIJ24ALh0yvzYN/E9k2jNYz5yj1nAn2f4VI5DJcc9ni3RXXWoL GyiZQqxU69elHmAqaow7BAlv4TlFTQgxeWXEG/dKHmY79+lCXk7uxw0rwxu6CeIHAoD5 id9JUmLeE5SxqpiTKAXt98kSdUAzYEnZAQoiKUQEMf2fM5EM7EHouoVPwPPZntMzG4RK tArZ/hl8lxxZYlDXtLmZMR2p04ZF6x9o3EUSM1P8/UKXuORzMYqDoztPz1frRhoKcFrr +VjuzY9N1jxlILw2Vt+KS0k/BLSbkgzJbtae98QVO6rgKfmGAOAkjayq43Px8XXdn9SD VaRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0uhFUfNaMLDnocl9QFbYmL5Wvt9QqobpzwSBYs2kZHk=; b=XEk609rSXC66SH+Hwqtu4aUKJ7Yw34TAuc7B77eQWirdYv8NSCdvprhZCo2ftjqq3L gezfHbUI6pqlahq7DIdKYIAWgIXWka5cnSKSihkDYEiLFU6CQvQiS49nfMY2izvB7Uiz r6B3XdQ8+e1PrdXUDuc6ucIT0u8nOiXShV8dOxCFTRNNqdLs8hAR6/LepPUaywGyEQrE 0Zv4595K/OdBpwdiUIG9btU0aq6PkKIdPs2tITwH6QL0rAwGQWI6ZpfRxFb65qRzD00J WNd1v8R4pRkJyLXduFOTCmD72V95uhMjjZ30R+EHrdcdsGcmRPlZEp3kmf04qg1ZjfUI NTog== X-Gm-Message-State: AKwxytfr8GfVMGAEl972C1Zrap1g1MTCtu8tUn3to6uDI0OO2h/ZRoHz MvisyvA3ldYTlQOCEpsfgbkl0IaLv8mZJ57vDUzIQg== X-Google-Smtp-Source: ACJfBosMyE2Aej0IAx+MVEx2nZ7J1z1qs8XKRQGYTX5hpk/S7cB1qIpFmKxjB/MfHYW2rRbVVVKkZYjU9jUifrLIVAw= X-Received: by 10.107.7.67 with SMTP id 64mr10458181ioh.296.1515402943582; Mon, 08 Jan 2018 01:15:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Mon, 8 Jan 2018 01:15:42 -0800 (PST) In-Reply-To: <899567F7-0C02-4A60-ADA0-5F43A6CF594B@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> <899567F7-0C02-4A60-ADA0-5F43A6CF594B@dsl-only.net> From: blubee blubeeme Date: Mon, 8 Jan 2018 17:15:42 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 09:15:44 -0000 On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard wrote: > [The involvement of sysutils/fusefs-simple-mtpfs > and sysutils/fusefs-libs and multimedia/libmtp > in order to use the Media Transfer Protocol (MTP) > against the LG v30 likely explains much of the > performance difference vs. local UFS file > systems. I provide some related notes.] > > blubee blubeeme gurenchan at gmail.com wrote on > Mon Jan 8 05:17:24 UTC 2018 : > > [Note: the original was in a reply to a Jon Brawn > post. I've merged it back with my post.] > > > On 2018-Jan-7, at 11:46 AM, Mark Millard wrote: > > > >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme > wrote: > >> > >> > >> > >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard > wrote: > >>> > >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme > wrote: > >>>> > >>>>> I ran this test and here's some results. > >>>>> gstat -pd images: > >>>>> > >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >>>>> multiple small files from laptop to phone: https://imgur.com/a/B4v4y > >>>>> multiple small files from laptop to ssd: https://imgur.com/a/mDiMu > >>>>> > >>>>> The files are missing timestamps but the originals were taken with > scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >>>>> > >>>>> as far as why there's such high deletions? I can't say I'm only > using cp. > >>>> > >>>> I assume that md99 is for a file-based swap-space, such as > >>>> via /var/swap0 file. (As a side note I warn about bugzilla > >>>> 206048 for such contexts.) Otherwise please describe how > >>>> md99 is created. (Below I assume the swap-space usage of > >>>> md99.) > >>>> > >>>> The only other device that your pictures show is your > >>>> NVMe device nvd0. > >>>> > >>>> No picture shows a device for the LG v30 when it is mentioned > >>>> above as being copied to or from. How is it that there is no > >>>> mounted device shown for the LG v30? > >>>> > >>>> No picture shows a device for the SSD when it is mentioned > >>>> above as being copied to or from. How is it that there > >>>> is no mounted device shown for the SSD? > >>>> > >>>> Without a device displayed for the LG-v30/SSD there is nothing > >>>> displayed for its reads or writes. This makes the gstat -pd > >>>> useless. > >>>> > >>>> May be the p needs to be omitted for some reason? gstat -d > >>>> > >>>> === > >>>> Mark Millard > >>>> markmi at dsl-only.net > >>> > >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >>> > >>> Those tests earlier was a huge time sink. > >>> Here's the dmesg output from earlier: > >>> . . . > >>> ---------------------------------- > >>> > >>> I don't know why gstat isn't showing the info u are looking for. > >>> > >>> You said earlier that something was getting deleted, > >>> I don't know what could be causing that. > >> > >> Those "deletes" are more commonly called TRIM on SSD's. > >> FreeBSD called them, BIO_DELETE as I remember. > >> > >> Those deletes have nothing to do with umounting, deleteing > >> devices, etc. > >> > >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... > >>> Even say forget the mobile device and go from > >>> zpool > >> > >> From which I've not been able to figure out the kind of > >> information that I'm looking for. > >> > >> Just because a device is present, does not mean that it > >> is available as a file system. I'm more interested in > >> how the file systems are made available --or if some > >> non-file system way of working is involved. > >> > >>> Are you saying that there's something misconfigured on my end? > >>> What other info do you need me to provide to try to figure out > >>> what's going on or why I'm getting these transfer rates? > >> > >> I'm saying I still can not tell how you make the SSD or the > >> LGv 30 available to FreeBSD (mount?). Or why no matching > >> mounted device shows up in gstat's display. > >> > >> If you wish to keep trying to help me help you, . . . > >> > >> Please show how you make the file system on the > >> SSD available to FreeBSD: what FreeBSD commands make > >> the device available for use. (I'd guess that mount > >> is used or that something like /etc/fstab is used > >> to do mounts more implicitly.) > >> > >> Please show how you make the LG v30 available to FreeBSD: > >> what FreeBSD commands make the device available for > >> use. (I'd guess that mount is used or that something like > >> /etc/fstab is used to do mounts more implicitly.) > >> > >> (I would expect these are mount commands, or at least > >> involve mount commands/calls. Some of the following makes > >> that presumption.) > >> > >> For each of those: with the device available show the > >> output of: > >> > >> mount > >> > >> and of: > >> > >> df -m > >> > >> Similarly, show the exact commands used to make the > >> copies to and from the SSD. Show the exact commands > >> used to make the copies to and from the LG v30. > >> > >> (You can for now stop the commands early or just > >> not start any that would take a long time.) > >> > >> I'm looking for a way to get information similar to > >> what I expected gstat to show. I'd expect a mounted > >> file system but may be something else is involved? > > > [Extracted from a reply to a Jon Brawn post.] > > @Mark Millard > > I use sysutils/simple-mtpfs to mount the android device. > > when I mount the phone through USB this is the relevant section: > > /dev/fuse 356311 78912 277398 22% > > /mnt > > > > That's the most complicated mount process that I use, > > for the ssd it's just a simple mount /dev/device /mnt > > relevant output: > > /dev/da0 923913 121450 728550 14% > > /mnt > > > > Can you tell me what information you're looking for so that I can gather > it > > all up and send it. > > > I do not find a /usr/ports/sysutils/simple-mtpfs . But I > do find: > > # ls -lTd /usr/ports/sysutils/*simple* > drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 > /usr/ports/sysutils/fusefs-simple-mtpfs > > And that was very important to know. > > I had to look it up but this means that you are using > the Media Transfer Protocol (MTP) to transfer files from > the LG v30. It also means that part of that involves use > of the Filesystem in USErspace (FUSE). The two would be > likely to add overheads that slow things down (extra > stages/steps in getting the bytes copied). > > [Apparently MTP is an extension to the Picture Transfer > Protocol (PTP) communications protocol. MTP has been > standardized as a full-fledged USB device class but > originated with Microsoft.] > > [MTP use involves putting the Android device into MTP mode, > frequently referenced in the Android UI via a selection > of "USB for file transfer" someplace in the user > interface (according to what I read).] > > One example of why FreeBSD and sysutils/fusefs-simple-mtpfs > and sysutils/fusefs-libs and multimedia/libmtp might be > slower than some linux software is: > > It appears that some Linux software has implemented "USB > 'Zerocopy' support found in recent Linux kernel" (and, > so, avoid user-space vs. kernel space data copying and > some context switching). > > I doubt that FreeBSD and its sysutils/fusefs-simple-mtpfs > and sysutils/fusefs-libs and multimedia/libmtp combination > happen to do that. This difference likely would make a > notable speed difference for the transfer and save to local > file system (if my doubt is correct). > > It is not surprising that the speeds would be far less > than the experiments that I reported. > > > I do not have a context to experiment with the > consequences of using sysutils/fusefs-simple-mtpfs > and what it requires (fusefs-libs and libmtp). I'm > afraid I'll not be able to be much help relative to > the LG v30 MTP-based transfer performance > investigations. > > > That leaves the SSD context. Is there anything that > you still want to investigate relative to the SSD > usage? Or is there no point because of the LG v30 > status? > > === > Mark Millard > markmi at dsl-only.net > > > OK, forget the android specific usb issues for now; there is quite a few layers of crud between the laptop and the android device. I have this SSD. What are some tests that you'd like to run to test the speeds on my end? From owner-freebsd-current@freebsd.org Mon Jan 8 15:34:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB040E72CE0 for ; Mon, 8 Jan 2018 15:34:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 713FE805C6; Mon, 8 Jan 2018 15:34:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id d202so14582741qkc.9; Mon, 08 Jan 2018 07:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5b5V6cFgy6ZWoPf+4544dBDTC02mL32l+3WCWbDFCJQ=; b=c4XnT0agqaS9D6Ika+exDEWD5fp9Ox/XMljITGfZ6JTSkjlCNbxVo0qeDzSNp8bUKM dd4LykfADngkp/b/umtQuoU3FRj4h3uKD92We75FmPpYHXJLesRRYSWNieFgD38K+UQV UOlGlDAQcm3RjSEUmtth1S8kLG+0V3+Uhcdks7j/D8AuI/wsaJezs/mn7w9l6b3VQ62p /uTpPZjFs9z9lWZTZ3zxaVh7u87V7uMAjAnis40DFIMdPpETsp9SpXiuspqimNkcgxG/ LTW9qMKhdPNgRBITha758WJQp4R80BgCdcI9H2BLUFvC4GQeZO1XeUv+TVdbQZSy5o/D g6Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=5b5V6cFgy6ZWoPf+4544dBDTC02mL32l+3WCWbDFCJQ=; b=D3mGKJOaci37jVQqNc/zxFOpANZPytSS1poiKIkzuDhH1nHUGN48PvpfiKNHMHY0uh 8P+nAlimveU1wXPq1+dZBVnuu2MpT62XC4dDWF6kamDgwKxBSiDTlN3ksGNBbBHlM68b Lr3SR8C42pjNdOOGVdlH1C6DbXVtYSO7BJaZaijYiTrBBDQIvaaW9A3I5jGDDGPpjgLS 7oYce1maUwoCkMdqJ61KMs8SNA96GOZeltGr7e5Q1sgdyoGBmti+JDmT8tX9PNL5PJ0/ 1yM2K0EzJLoX2yxYRFVLBqKUR7Tq7hRB6QRfq6bsiHyWSr2OJ0dsnJ9j6DbZEZvycNH6 fJug== X-Gm-Message-State: AKwxytfslaNAlsesoqYSHfHD2q5VEkjnj2HvqyWUYLPZoVHVf9+7pEuQ X4eQrmdrET6pq7dCD5y4lrmw5Q== X-Google-Smtp-Source: ACJfBotP0EVR9A3O3tJx+lTmcUCq4MiPKvD1z4h3pGBIrpRPtaxj0focRttP+a19WEPXOIS3Wn4Itw== X-Received: by 10.55.15.2 with SMTP id z2mr16982253qkg.91.1515425642653; Mon, 08 Jan 2018 07:34:02 -0800 (PST) Received: from raichu (toroon0560w-lp140-02-70-49-169-112.dsl.bell.ca. [70.49.169.112]) by smtp.gmail.com with ESMTPSA id p8sm7757231qtj.70.2018.01.08.07.34.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 07:34:01 -0800 (PST) Sender: Mark Johnston Date: Mon, 8 Jan 2018 10:33:56 -0500 From: Mark Johnston To: Michael Tuexen Cc: Warner Losh , "O. Hartmann" , FreeBSD CURRENT Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Message-ID: <20180108153356.GA2412@raichu> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:34:04 -0000 On Thu, Jan 04, 2018 at 09:10:37AM +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. I saw the same issue this morning on a mirrored root filesystem after my workstation came up following a power failure. fsck recovered using the journal, and I subsequently saw a number of these checksum failures. Upon shutdown, I saw the same handle_workitem_freefile errors as above. I then ran a full fsck from single-user mode, which didn't turn up any inconsistencies, and after that the checksum failure errors disappeared, presumably because fsck fixed them. From owner-freebsd-current@freebsd.org Mon Jan 8 16:12:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1831E74D97 for ; Mon, 8 Jan 2018 16:12:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9351C829F3 for ; Mon, 8 Jan 2018 16:12:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id i143so14724404ioa.3 for ; Mon, 08 Jan 2018 08:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HSy7AChZvMPLJNWiVt+RhtFqESchy2CizKU+LaXuTts=; b=pdTTsI7+m3wEyRxfAk4BrSTsMXvbDQLM8u0ge1na0+sEcPj0tMv81s+DJH0GqY+Rlw U+B6U051PSvH0KwjStMY9+0rtnvzBSdcZsz1OBubzEDDbJBMBNgET2ZlgnpziAqfP34L bIEO4dbfFF1dFe5UxWXxXM5xuG2qBAW0vcvOR2rj+5umZRnut1xh9VyruEtEuDfF++Cb j9C24gYHV/uJ3C66kyzTPviHDIYO0pEYzRAaJtNOUzs+Mh3F0rrs2jI+b9Zg43vFI+H5 8ersNwYABpI5Pcsrds63Z/6tPQHjPHURCAxBzT7d3Dsqe7zLZlKmvprXr7f+mqGs/VcV I8JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HSy7AChZvMPLJNWiVt+RhtFqESchy2CizKU+LaXuTts=; b=VUY2IfIycGOY1MhZorO+Cw56aKogw8KMKXv2ZSDwjW64L76BQVAc5VyPHzrWP8YOll +hXKegKhXtH6IDtQOgsZBcFfccDaQkPoPsrIIa7z5w+q1eSfLfOMXFONpgk90zyxTsmB YLI+oNliK6Qf8yZ+KsF03Irdb0kVuXpngCNj78RSg75DaLX+np/sBqw3KGSwrm6iLLkf Ie7olWmEHUM0754liiPw89lOS3Ff6qrNAjqNpL3cqZ4G/ZBHSxm0Tg6HDtxzdAuujYvP JMAic8o2+9vkaNVhP5ltkPtAJxGYmb+aDwrtybud8F+Mr2Cz1qdHxlh7MI62r0p+94Ip ziMQ== X-Gm-Message-State: AKwxytd5QxXq7I/ML6EBOwKrzwaNhNam4OI0QwoMpOX3ja9FMv8fkxOV LCjXBwPQogTaeM+EYNG+tLZxAV+oL9OrhYAa/3ZhUw== X-Google-Smtp-Source: ACJfBosUNP7Acgsyy7khNF7BGkPCgLbGf9TP9J2M2OSx0i6WEcC6PvzORVk2ywYT/7N3mvwBwFFHV8RaWiG2lbYbpPs= X-Received: by 10.36.91.210 with SMTP id g201mr8749400itb.50.1515427937771; Mon, 08 Jan 2018 08:12:17 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Mon, 8 Jan 2018 08:12:16 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:a84a:1e5c:a3af:9943] Received: by 10.79.160.217 with HTTP; Mon, 8 Jan 2018 08:12:16 -0800 (PST) In-Reply-To: <20180108153356.GA2412@raichu> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> <20180108153356.GA2412@raichu> From: Warner Losh Date: Mon, 8 Jan 2018 09:12:16 -0700 X-Google-Sender-Auth: wekoV_blZXkB73xBxiT2sPzAhsg Message-ID: Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> To: Mark Johnston Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:12:18 -0000 On Jan 8, 2018 8:34 AM, "Mark Johnston" wrote: On Thu, Jan 04, 2018 at 09:10:37AM +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. I saw the same issue this morning on a mirrored root filesystem after my workstation came up following a power failure. fsck recovered using the journal, and I subsequently saw a number of these checksum failures. Upon shutdown, I saw the same handle_workitem_freefile errors as above. I then ran a full fsck from single-user mode, which didn't turn up any inconsistencies, and after that the checksum failure errors disappeared, presumably because fsck fixed them. Yes. Fsck automatically fixes issues like that. It does it silently. I have patched to make it noisy, and the dozen cases I saw the errors, fsck was silent with my whiny patches. I can put them up for review if people want... Warner From owner-freebsd-current@freebsd.org Mon Jan 8 15:26:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD2A7E72680 for ; Mon, 8 Jan 2018 15:26:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3C65800BA for ; Mon, 8 Jan 2018 15:26:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w08FQiZG022159; Mon, 8 Jan 2018 07:26:44 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w08FQhA8022158; Mon, 8 Jan 2018 07:26:43 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801081526.w08FQhA8022158@pdx.rh.CN85.dnsmgr.net> Subject: Re: Make periodic's output log to files if sendmail is disabled on install In-Reply-To: To: mykel@mWare.ca Date: Mon, 8 Jan 2018 07:26:43 -0800 (PST) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 08 Jan 2018 17:32:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:26:53 -0000 > 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) ) I would not make this option dependent on sendmail, it should just be a stand alone set of options "Do you want logs" #Completely turn off periodic in crontab "Do you want logs mailed or stored in files" #dtrt > 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! You can argue that when you provide a statistical data set, until then this is speculation at best and should not be used in an argument for or against a change like this. If I do nothing different in the installer please make sure the systems end up as they have been configured for a very long time to minimize POLA. And to minimize any changes to all the post install configuration that people have been doing up until now. Changing how things work out of the box undoes or adds to changes people already have in place, and for larger instances, probably have fully automated. If your adding fine grained configuraton like this to the installer Allan, I'll make a request for the dma users, add an option to have: Which mail agent would you like, none, dma or sendmail?" IMHO, this list of "feature tweeaks" goes on forever and really should just be the user configuring there system post install, maintaining this in bsdinstall is ad hoc, and would be better served by a page of "things you may want to set up after the install is finished" > > > > [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-unsubscribe@freebsd.org" > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Jan 8 19:14:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 302E4E5A81A for ; Mon, 8 Jan 2018 19:14:25 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE7B46E9A2 for ; Mon, 8 Jan 2018 19:14:24 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id w50so2641062wrc.11 for ; Mon, 08 Jan 2018 11:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=O6lZu0j7n+K8qUgd4WVBV3Fsv0d3zrJ+sFRu9ecp05U=; b=sXDiiuHsH2ItZiiHra+Y+eM8mzr/grWIsTIRretNkoxNdPF/27uQbes7/t+Xzh8+Y7 cWE9+bdFmn52T1i0HjkGoc37Oczp52nDrTFBXqSzG4QOTbVM7NaXEqe8s1DIvAVrAyIv 3t+5VLoDZSj6DqmBPHqsI8ARtZtqxRu+6rdwItnHxxb1aZy7VmlFqApJWkbH8X2eKkHO pPQj6ndpF48RXXW3uMqWJY5T4hZUXEeAFzSjQUC++DZNdx1EnskJ1eKj7R9WU2nuRoKi z8rINdjrxmauq9eV6B2gwzf9LZ1hms66+3D88p4Agbk9JwKI2zHnhBGIaDdNYzw6GYxk k9LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=O6lZu0j7n+K8qUgd4WVBV3Fsv0d3zrJ+sFRu9ecp05U=; b=s+CEwC/d1TsZ7nqVGCjnpS8xBzfIKgGh6FF77ZvjE7D+5Kph/bK+j+aonbM3UXfMu3 kYgrB0Yge5eOtFaMfq06y5zty10520rPOp2Fs3lo/WJXm7sSARLLCrWUKWT2t/QyjaZR kE2haqnslIG4bvjuDvW1P+i+Wt1ZgEVs7CKFpCL1mplqDMU2wm7Mj1tQZNISJwM8ys3+ yWJto8WP6jnb8jJplNEUrB1EMb+qgXJSt1IJGwXpiKOmVSCqRM97sXJ/Wmcck8axxHNg F3Bhe/catAQOvX6/RmmPDgZmrwxWuI47rr9VTTKx9e43BMarjiJcUVJEB/nsT/Viq2IX DYaA== X-Gm-Message-State: AKGB3mK2oldO0mbYfwe2zP8O+jkkioWBW1R4kIZW0WroxiN9cfWSRZx6 ous17bHajLGnhx/d05/Hxfo= X-Google-Smtp-Source: ACJfBou907XuojuQo0BxmXVyHKQ77X7YxrNSrlOnMlWvWpuN6E1rh4aD8mRp4Vw58xmkDgqTW0R6oA== X-Received: by 10.223.184.195 with SMTP id c3mr12281866wrg.9.1515438863040; Mon, 08 Jan 2018 11:14:23 -0800 (PST) Received: from ernst.home (p5B023419.dip0.t-ipconnect.de. [91.2.52.25]) by smtp.gmail.com with ESMTPSA id v23sm10535828wmh.30.2018.01.08.11.14.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jan 2018 11:14:21 -0800 (PST) Date: Mon, 8 Jan 2018 20:14:20 +0100 From: Gary Jennejohn To: blubee blubeeme Cc: Jon Brawn , Warner Losh , "O'Connor, Daniel" , FreeBSD current Subject: Re: USB stack Message-ID: <20180108201420.4ee17dfb@ernst.home> In-Reply-To: References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> <6ADAB19C-3EC6-476D-9B89-3B29EF9EC087@brawn.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:14:25 -0000 On Mon, 8 Jan 2018 13:17:22 +0800 blubee blubeeme wrote: > On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn wrote: > > > > > > > > On Jan 7, 2018, at 5:44 PM, Jon Brawn wrote: > > > > > > > > >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme > > wrote: > > >> > > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > > >> > > >>> > > >>> > > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > > >>> wrote: > > >>> > > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or > > greater > > >>>> and the topic gets derailed...? > > >>>> > > >>> > > >>> Yes, it does. > > >>> > > >>> > > >>>> Are you guys saying that 7-8MB/s is USB speeds? > > >>>> > > >>> > > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > > USB > > >>> 1.x. More recently, I've maxed out the writes on a USB stick at about > > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... > > I've > > >>> not tried USB3 with an SSD that can do more.... > > >>> > > >>> Warner > > >>> > > >>> > > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > > >>>> wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn > > wrote: > > >>>>>>> What is an "LG v30"? > > >>>>>>> > > >>>>>> It's a smartphone from LG and only supports USB2 speed. The > > reported > > >>>>>> transfer rate is no big surprise. > > >>>>> > > >>>>> OK thanks. > > >>>>> > > >>>>> -- > > >>>>> Daniel O'Connor > > >>>>> "The nice thing about standards is that there > > >>>>> are so many of them to choose from." > > >>>>> -- Andrew Tanenbaum > > >>>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> freebsd-current@freebsd.org mailing list > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd.org > > >>>> " > > >>>> > > >>> > > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > > >> ------------------------------------------------------------------- > > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > > >> Jan 7 11:56:56 blubee kernel: umass0: > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > > 0x0100 > > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > > lun 0 > > >> Jan 7 11:56:56 blubee kernel: da0: Fixed Direct > > >> Access SPC-4 SCSI device > > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > > sectors) > > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > > >> Jan 7 12:06:08 blubee kernel: 1st 0xfffffe07c26336c0 bufwait > > (bufwait) @ > > >> /usr/src/sys/vm/vm_pager.c:374 > > >> Jan 7 12:06:08 blubee kernel: 2nd 0xfffff80148c425f0 zfs (zfs) @ > > >> /usr/src/sys/dev/md/md.c:952 > > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > > >> Jan 7 12:06:08 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:08 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:08 blubee kernel: #2 0xffffffff80a41b8e at > > >> lockmgr_lock_fast_path+0x1ae > > >> Jan 7 12:06:08 blubee kernel: #3 0xffffffff81094309 at > > VOP_LOCK1_APV+0xd9 > > >> Jan 7 12:06:08 blubee kernel: #4 0xffffffff80b4ac36 at _vn_lock+0x66 > > >> Jan 7 12:06:08 blubee kernel: #5 0xffffffff80611d32 at > > mdstart_vnode+0x442 > > >> Jan 7 12:06:08 blubee kernel: #6 0xffffffff806102ce at md_kthread+0x1fe > > >> Jan 7 12:06:08 blubee kernel: #7 0xffffffff80a2d654 at fork_exit+0x84 > > >> Jan 7 12:06:08 blubee kernel: #8 0xffffffff80ef5e0e at > > fork_trampoline+0xe > > >> Jan 7 12:06:15 blubee kernel: lock order reversal: > > >> Jan 7 12:06:15 blubee kernel: 1st 0xfffffe07c41d5dc0 bufwait > > (bufwait) @ > > >> /usr/src/sys/kern/vfs_bio.c:3562 > > >> Jan 7 12:06:15 blubee kernel: 2nd 0xfffff8002bb31a00 dirhash > > (dirhash) @ > > >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > > >> Jan 7 12:06:15 blubee kernel: stack backtrace: > > >> Jan 7 12:06:15 blubee kernel: #0 0xffffffff80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:15 blubee kernel: #1 0xffffffff80acf882 at > > >> witness_checkorder+0xe02 > > >> Jan 7 12:06:15 blubee kernel: #2 0xffffffff80a748a8 at _sx_xlock+0x68 > > >> Jan 7 12:06:15 blubee kernel: #3 0xffffffff80d6a28d at > > ufsdirhash_add+0x3d > > >> Jan 7 12:06:15 blubee kernel: #4 0xffffffff80d6d119 at > > ufs_direnter+0x459 > > >> Jan 7 12:06:15 blubee kernel: #5 0xffffffff80d76313 at > > ufs_makeinode+0x613 > > >> Jan 7 12:06:15 blubee kernel: #6 0xffffffff80d71ff4 at ufs_create+0x34 > > >> Jan 7 12:06:15 blubee kernel: #7 0xffffffff810919e3 at > > VOP_CREATE_APV+0xd3 > > >> Jan 7 12:06:15 blubee kernel: #8 0xffffffff80b4a53d at > > vn_open_cred+0x2ad > > >> Jan 7 12:06:15 blubee kernel: #9 0xffffffff80b42e92 at > > kern_openat+0x212 > > >> Jan 7 12:06:15 blubee kernel: #10 0xffffffff80f16d2b at > > amd64_syscall+0x79b > > >> Jan 7 12:06:15 blubee kernel: #11 0xffffffff80ef5b7b at > > Xfast_syscall+0xfb > > >> > > >> > > >> Is the slow transfers user error? > > > > > > Wotcha! > > > > > > I don___t see any read or write performance figures anywhere? Also, is > > this CURRENT? If so, aren___t all the debug / warning features that are > > turned on by default in CURRENT at the moment going to have an effect on > > throughput? Especially if you___re writing through a filesystem where > > directory and file accesses will each require a lock to be taken, if only > > for a short while? If you want to get closer to the true USB speed of the > > device, stop mounting it and copying files to the filesystem, but instead > > just dd data onto and off of the device directly, and measure how fast that > > goes. Remember to backup your data from the card first___ > > > > > > Jon. > > > > > > > > > > Also, is the SD card physically inside the phone, and you are using a USB > > cord to connect the phone to the FreeBSD computer by any chance? > > > > Jon > > > > @Mark Millard > I use sysutils/simple-mtpfs to mount the android device. > when I mount the phone through USB this is the relevant section: > /dev/fuse 356311 78912 277398 22% > /mnt > FUSE = Filesystem in Userspace and is inherently slow. You can't expect good performance from it. For example, when I mount NTFS with FUSE I get only about 30MBps. Windows manages about 100MBps. I mounted the SD card in my smart phone under Windows and got a transfer rate of about 23MBps. Given how slow fuse is I'd say that the aprroximately 7MBps you're seeing is to be expected. [snip] -- Gary Jennejohn From owner-freebsd-current@freebsd.org Mon Jan 8 19:35:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDF77E5BE5E for ; Mon, 8 Jan 2018 19:35:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFB596FACB for ; Mon, 8 Jan 2018 19:35:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 041903e0-f4ab-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 041903e0-f4ab-11e7-93a5-cd02e7dc7692; Mon, 08 Jan 2018 19:35:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w08JZXDp003038; Mon, 8 Jan 2018 12:35:33 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515440133.44630.16.camel@freebsd.org> Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 From: Ian Lepore To: Don Lewis , Warner Losh Cc: "O. Hartmann" , FreeBSD Current Date: Mon, 08 Jan 2018 12:35:33 -0700 In-Reply-To: References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:35:43 -0000 On Sun, 2018-01-07 at 23:49 -0800, Don Lewis wrote: > 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. > Disabling the build of lint on 11-stable by default, but allowing users to enable it, seems to me like the most sensible option, given how little lint is used these days.  (The alternative would be to build it as a bootstrap tool I guess.)  I've created a patchset to do that and put it up for review... https://reviews.freebsd.org/D13799 If this is an okay solution for everyone, I think it could be used with 10-stable too. -- Ian > 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-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > 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" > _______________________________________________ > 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" From owner-freebsd-current@freebsd.org Mon Jan 8 19:43:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7BEDE5C68E for ; Mon, 8 Jan 2018 19:43:50 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B97C70019 for ; Mon, 8 Jan 2018 19:43:50 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eYdKq-000NDE-Qd for freebsd-current@freebsd.org; Mon, 08 Jan 2018 20:43:52 +0100 Date: Mon, 8 Jan 2018 20:43:52 +0100 From: Kurt Jaeger To: freebsd-current@freebsd.org Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 Message-ID: <20180108194352.GQ2827@home.opsec.eu> References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> <1515440133.44630.16.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515440133.44630.16.camel@freebsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:43:50 -0000 Hi! If I understand correctly, in the past we decommissioned stuff from the base system in a few steps: - announce intent - analyse/remove from use - disconnect from build - remove from tree It seems dropping lint was done a bit hasty ? -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Mon Jan 8 19:49:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D898E5CC35 for ; Mon, 8 Jan 2018 19:49:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 707B47052A for ; Mon, 8 Jan 2018 19:49:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f0a41168-f4ac-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id f0a41168-f4ac-11e7-93a5-cd02e7dc7692; Mon, 08 Jan 2018 19:48:47 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w08JnK3U003075; Mon, 8 Jan 2018 12:49:20 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515440960.44630.19.camel@freebsd.org> Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 From: Ian Lepore To: Kurt Jaeger , freebsd-current@freebsd.org Date: Mon, 08 Jan 2018 12:49:20 -0700 In-Reply-To: <20180108194352.GQ2827@home.opsec.eu> References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> <1515440133.44630.16.camel@freebsd.org> <20180108194352.GQ2827@home.opsec.eu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:49:22 -0000 On Mon, 2018-01-08 at 20:43 +0100, Kurt Jaeger wrote: > Hi! > > If I understand correctly, in the past we decommissioned stuff from > the base system in a few steps: > > - announce intent > - analyse/remove from use > - disconnect from build > - remove from tree > > It seems dropping lint was done a bit hasty ? > It was discovered that it had not been working for about 3 years and nobody complained, so hasty removal seemed innocuous at the time.  I don't think these subsequent build problems were anticipated, but they should be fixable. https://lists.freebsd.org/pipermail/freebsd-arch/2016-February/017658.html -- Ian From owner-freebsd-current@freebsd.org Mon Jan 8 19:53:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5277E5D279 for ; Mon, 8 Jan 2018 19:53:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8116E709E3 for ; Mon, 8 Jan 2018 19:53:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id e20so15882884iof.12 for ; Mon, 08 Jan 2018 11:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CX3KADIx8jZRY/TQ9GcygxnQKS8aKD5fSo6/myeNNHw=; b=kIF4xuzw+uk5og+RpSKAqbjKW/R/fdrA06jiYTXeT41l6Liu2myyAw6+GatzO2HaXF tqjzC7FVb/d46lKs/yLPhP69Vk7in2ThtP/nwyIR1eSy2pNdX2nEgSZDofD2Q7RK71J1 TO1G99lb4a4SuwcfEbRGeMS2FNRJLCjEcon8Ccharsa7e8mnHJTGHuALr0VKlovXO/Nt AvYgWV8OrOerr9uh5/Xu2xgEucFI3j8cbQbKs//DSYMcE827BrC3zPD16ibnAA7G26Z3 SQ81V7LZnyUqVuMolH8QJNVhTkQqYREdjTEI8hkpBPFaToVVgEfV5PKiBAdpP3tnklQv ZDTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CX3KADIx8jZRY/TQ9GcygxnQKS8aKD5fSo6/myeNNHw=; b=JzJDKnCh0Gq2ukY7lDqQ3ptxUnqPw8RKXXrEX+3i90kfZ22e0rpqGyr9XbYd1KLnnz blSIE75EhEq+0EL9MjL4WlPd25VPBk4k7s8X1qF6jjzwSDLL6pd0YLFCP6TPKpliWtqz g6+zOMjkWgQ+gbnOmtoScDylfzPMBgUx1DppPCk0I9cwP6eWu5hko3ZXh9a7CXKcNFgc yaJxRCB9d6vpX2ko7HnUkNoNMl2FPO5FRdPVuig4K5UGoBGs7yLFO6IGLcL3OIfU7G6+ 4F+bJEPReDQLT/HWkKKcNYByw6y9gP3ROUhJeycdvvBdVC7FNQuGa3Oevq/l7J7kTPON DN/w== X-Gm-Message-State: AKwxytf0Iawqh+VjvAU9f+F8jAhVO3ZD1g7kFX97lkF3DKSqDmBmICGh 2LuwmSvn5+69E1cznzobi6S0iDuJiLo3HDC+kAIN5g== X-Google-Smtp-Source: ACJfBotAWP6zhgESQD8eNkAz/xM1AmOOwIIUA91CL6NSVM6kjfwN9Je2VBQkdjpKBD14RkGGvoUKGRRv2zoG3Jwc2AU= X-Received: by 10.107.12.36 with SMTP id w36mr13429872ioi.291.1515441226634; Mon, 08 Jan 2018 11:53:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Mon, 8 Jan 2018 11:53:45 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:a84a:1e5c:a3af:9943] Received: by 10.79.160.217 with HTTP; Mon, 8 Jan 2018 11:53:45 -0800 (PST) In-Reply-To: <20180108194352.GQ2827@home.opsec.eu> References: <20180108075813.3e181697@freyja.zeit4.iv.bundesimmobilien.de> <1515440133.44630.16.camel@freebsd.org> <20180108194352.GQ2827@home.opsec.eu> From: Warner Losh Date: Mon, 8 Jan 2018 12:53:45 -0700 X-Google-Sender-Auth: vNOsktW4oMJetN_GcPAq1TScu3E Message-ID: Subject: Re: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127 To: Kurt Jaeger Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:53:47 -0000 On Jan 8, 2018 12:44 PM, "Kurt Jaeger" wrote: Hi! If I understand correctly, in the past we decommissioned stuff from the base system in a few steps: - announce intent - analyse/remove from use - disconnect from build - remove from tree It seems dropping lint was done a bit hasty We did all that, but this was an unanticipated issue. I like Ian's idea. Warner From owner-freebsd-current@freebsd.org Mon Jan 8 21:26:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8504E638CE for ; Mon, 8 Jan 2018 21:26:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96CA875D50 for ; Mon, 8 Jan 2018 21:26:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (astound-66-234-199-215.ca.astound.net [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id D024910A8BE; Mon, 8 Jan 2018 16:26:47 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Michael Jung Subject: Re: witness_lock_list_get: witness exhausted Date: Mon, 08 Jan 2018 10:39:47 -0800 Message-ID: <1684681.MCyL5Ev91y@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> References: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 08 Jan 2018 16:26:47 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:26:55 -0000 On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: > Hi! > > I've recently up'd my processor count on our poudriere box and have > started noticing the error > "witness_lock_list_get: witness exhausted" on the console. The kernel > *DOES NOT* crash but I > thought the report may be useful to someone. > > $ uname -a > FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov > 19 18:41:20 EST 2017 > mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > The machine is pretty busy running four poudriere build instances. > > last pid: 76584; load averages: 115.07, 115.96, 98.30 > > up 6+07:32:59 14:44:03 > 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock > CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle > Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free > ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other > 25G Compressed, 32G Uncompressed, 1.24:1 Ratio > > Let me know what additional information I might supply. This just means that WITNESS stopped working because it ran out of pre-allocated objects. In particular the objects used to track how many locks are held by how many threads: /* * XXX: This is somewhat bogus, as we assume here that at most 2048 threads * will hold LOCK_NCHILDREN locks. We handle failure ok, and we should * probably be safe for the most part, but it's still a SWAG. */ #define LOCK_NCHILDREN 5 #define LOCK_CHILDCOUNT 2048 Probably the '2048' (max number of concurrent threads) needs to scale with MAXCPU. 2048 threads is probably a bit low on big x86 boxes. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Jan 8 22:16:23 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 783A8E66740 for ; Mon, 8 Jan 2018 22:16:23 +0000 (UTC) (envelope-from clutton@zoho.com) Received: from sender-pp-091.zoho.com (sender-pp-091.zoho.com [135.84.80.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46E8E77F7E for ; Mon, 8 Jan 2018 22:16:22 +0000 (UTC) (envelope-from clutton@zoho.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:subject:from:to:date:content-type:mime-version; b=fKa5CZgOKS2d6+iV2EcWNgooPpdqzdkDqe9cHGAVf3ijy6kVzUo0Jw3TBMnRDDgrDFyEIlDlFbx7 AV1nmWSMQmHeVC1ENlTNHCs+uB5bUT5r5l84IL+v4L3cmjUez5AQ Received: from [10.1.2.6] (mktechs.net [46.229.54.117]) by mx.zohomail.com with SMTPS id 1515449773969121.69872994383775; Mon, 8 Jan 2018 14:16:13 -0800 (PST) Message-ID: <1515449761.3483.14.camel@zoho.com> Subject: thinkpad carbon 5thgen + thunderbolt 3 dock From: clutton To: FreeBSD Current Date: Tue, 09 Jan 2018 00:16:01 +0200 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-sSkUEYI7d0fgSwJYWPw0" X-Mailer: Evolution 3.24.2 FreeBSD GNOME Team Mime-Version: 1.0 X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-ZohoMail: Z_30320720 SPT_1 SLF_E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 22:16:23 -0000 --=-sSkUEYI7d0fgSwJYWPw0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list. I have a thinkpad carbon 5th gen with ThinkPad Thunderbolt 3 Dock. The notebook doesn't work well with dock station, and I'm looking forward for some suggestions. Here it goes: 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=3D0x060400 card=3D0x11112222 chip=3D0x15d3808= 6 rev=3D0x02 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016]' class =3D bridge subclass =3D 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. --=-sSkUEYI7d0fgSwJYWPw0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEJS/zE0mE1p2+tYanfbA/jbLI/pAFAlpT7aIACgkQfbA/jbLI /pCIqg/8Cw5cdh7Kd63EMwzJ0VsxrETBj0Tt/gJbmkxg/qyCn8gSJBrin3+zGZ6m zdS8UsuC5vRvBVSiu8aFqQyaqpIq5Rj6i1L/mC1NFhhJ6ouvfTYBbTOXFDAggdSt XeYCibj/bAkTZh6Y/76bvYaU5GACje77Y51dNXb6Pk8CgGV3av+k9bYMtB0WJmnI z/kJnqrWOxncRNXSvGwloRhSZSF4XdugwHkxSeAOlrjinu7MfVBcesg0QZEFaBfa WPjfGz2xFt5MyTBfa8iMeZA3z76/W0pLkQGG9x+8csVQ9/c25DijeK0N/9xA1DVm EgSKWU1aKx4mxROUyw+XbIYfPYCgp6fhOk9DISe+e/hfe3mwEAOUytOknEu3wn4C we7Wyc96QkcTEm8Y2FJgpZqOU4trL48MP/jFelYpXnLpruExwI2GLecDja75KGtk elKJEYriukOC8VLqswjkrkaSikWzefaTjnrP1M58A6e4OGCktblK3Gp1SCbSsAxb hdzKHx2xf2TWstUAk6jpp/KhanSdIn/zZPGosAZR3wFnDRucWN5mCM8E5yWqTBFI 8txqcgXk0ZH8f3N86HUnRLfa+Jxnr7yhT/MEKMLrP0LifajL9O5d4TZB5inVHBp+ aTNREimi1DKEAEKP3MnLkYDlSwTxgx48mkpvyRKw5bXqGbfifYg= =ozyl -----END PGP SIGNATURE----- --=-sSkUEYI7d0fgSwJYWPw0-- From owner-freebsd-current@freebsd.org Mon Jan 8 23:41:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97F59E6BB4A for ; Mon, 8 Jan 2018 23:41:01 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 085507B5A1 for ; Mon, 8 Jan 2018 23:41:00 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 87563 invoked by uid 89); 8 Jan 2018 23:40:59 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 8 Jan 2018 23:40:59 -0000 Date: Tue, 9 Jan 2018 00:40:58 +0100 From: Michael Gmelin To: clutton Cc: FreeBSD Current Subject: Re: thinkpad carbon 5thgen + thunderbolt 3 dock Message-ID: <20180109004058.2f6c096d@bsd64.grem.de> In-Reply-To: <1515449761.3483.14.camel@zoho.com> References: <1515449761.3483.14.camel@zoho.com> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 23:41:01 -0000 On Tue, 09 Jan 2018 00:16:01 +0200 clutton wrote: > Hi list. > > I have a thinkpad carbon 5th gen with ThinkPad Thunderbolt 3 Dock. The > notebook doesn't work well with dock station, and I'm looking forward > for some suggestions. Here it goes: > > > 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? ath usually works well, but Lenovo uses a BIOS whitelist of supported devices, so you're probably out of luck. > > 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. Is this similar to anything described in those bugs? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713#c9 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224064 -m > > 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=0x11112222 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. -- Michael Gmelin From owner-freebsd-current@freebsd.org Tue Jan 9 00:02:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5DCCE6CF1C; Tue, 9 Jan 2018 00:02:31 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CAA57C30D; Tue, 9 Jan 2018 00:02:31 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.2/8.15.2) with ESMTPS id w08NfLDi035577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Jan 2018 18:41:22 -0500 (EST) (envelope-from mikej@mikej.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 mx2.paymentallianceintl.com w08NfLDi035577 Authentication-Results: mx2.paymentallianceintl.com; sender-id=pass header.from=mikej@mikej.com; spf=pass smtp.mfrom=mikej@mikej.com X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id w08NfKAh043314; Mon, 8 Jan 2018 18:41:20 -0500 (EST) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewall.mikej.com: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 Jan 2018 18:41:20 -0500 From: Michael Jung To: John Baldwin Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: witness_lock_list_get: witness exhausted In-Reply-To: <1684681.MCyL5Ev91y@ralph.baldwin.cx> References: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> <1684681.MCyL5Ev91y@ralph.baldwin.cx> Message-ID: <54018b1b2feaab3b05d7ed406eb8273c@mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 00:02:31 -0000 On 2018-01-08 13:39, John Baldwin wrote: > On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: >> Hi! >> >> I've recently up'd my processor count on our poudriere box and have >> started noticing the error >> "witness_lock_list_get: witness exhausted" on the console. The kernel >> *DOES NOT* crash but I >> thought the report may be useful to someone. >> >> $ uname -a >> FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun >> Nov >> 19 18:41:20 EST 2017 >> mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >> >> The machine is pretty busy running four poudriere build instances. >> >> last pid: 76584; load averages: 115.07, 115.96, 98.30 >> >> up 6+07:32:59 14:44:03 >> 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock >> CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle >> Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free >> ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other >> 25G Compressed, 32G Uncompressed, 1.24:1 Ratio >> >> Let me know what additional information I might supply. > > This just means that WITNESS stopped working because it ran out of > pre-allocated objects. In particular the objects used to track how > many locks are held by how many threads: > > /* > * XXX: This is somewhat bogus, as we assume here that at most 2048 > threads > * will hold LOCK_NCHILDREN locks. We handle failure ok, and we should > * probably be safe for the most part, but it's still a SWAG. > */ > #define LOCK_NCHILDREN 5 > #define LOCK_CHILDCOUNT 2048 > > Probably the '2048' (max number of concurrent threads) needs to scale > with > MAXCPU. 2048 threads is probably a bit low on big x86 boxes. Thank you for you explanation. We are expanding our ESXi cluster and even though with standard edition I can only assign 64 vCPU's to a guest and as much RAM as I want, I do like to help with edge cases if I can make them occur pushing boundaries as I can towards additianional improvements in FreeBSD. --mikej From owner-freebsd-current@freebsd.org Tue Jan 9 00:31:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19480E6ED54; Tue, 9 Jan 2018 00:31:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C61E47D72C; Tue, 9 Jan 2018 00:31:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id l12so16176598qke.13; Mon, 08 Jan 2018 16:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2w12l/GDWqBbOo10dS2vyeicOdCwT4Tf2uo+svmOcUo=; b=nd5sLI3EXbIRf6jEwrnsZJT+PTVX4rxTFGh5FcmJejLdz4e+iurSBJsl+4EkfgtSJF rozYIh8pIFEEiAS+T1Dlq7uTKTuJNdzlMZNOPepcdhM1hdTRt4wq+/4R/tVpAGYBVwnQ TG2Vgsy79xu1RE6HMD75EyPm7C0il/ikntgBvG0s7DXjTOTTZBDsn5MLAnOIe2ir+J+X kEkjeLfDC+SiPmxQxary66G11KX4wJ4wi5goJXjPDk1vewNq5fp2rJ80Khd1Z7fHX01Q nR+UxYq7zLHG348I9hTTV4K34AhYs825/fswLaeNm8U34e2mWl6EFaOvTWd/PeF95+x6 /N2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2w12l/GDWqBbOo10dS2vyeicOdCwT4Tf2uo+svmOcUo=; b=NOQMuruuQMJVYg2Ys+vhjwKiwzd0cj3m2uE0h4LK8jKES0ljAB/HOeYWOH8Mf9/p4v aL/AGc37a/6JXHi6tnhO7OCJtqf7Qm0dEdxDRWdxwgKVw/a/0W9c23kiU4uAhl3QRYmK 4YmSIV+kMY6emWNs16VXh8nmbSIC8PXaf3tPWn4VJyrZn1x+WXvZixqID2InXg0JXBDS Aj6WhXTMiQ4a5Tfl5EOTZPVUxKQW1muR9ai5wfsbo/gXWYMfbq/smG9bpAMNLe6lppZv hz0Fuvk8HTCrxDu0bLRlYlAgL7fz6/56ZX31LnTbkvneEdofFE2PC8ej5vGua/FCk3Hx 58tw== X-Gm-Message-State: AKwxytcIyqeGhLsh/sU2H/DhLOlTUWbM2IDbGFDKavFt5BOEC7uk50pI i7XcAdnCKsieQk9TiDtN8IssgxdVxKLP7saWOsQPsA== X-Google-Smtp-Source: ACJfBosnb1Xw3FRlgbnjhibLbb3r8gsmyTsBKE2J4mm6UZMzy/T1W5L46Vx8PgfACMLnX7NTY0aZQrPxGOr7+oxGdTE= X-Received: by 10.55.147.199 with SMTP id v190mr19112757qkd.119.1515457880986; Mon, 08 Jan 2018 16:31:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.44.214 with HTTP; Mon, 8 Jan 2018 16:31:19 -0800 (PST) In-Reply-To: <54018b1b2feaab3b05d7ed406eb8273c@mikej.com> References: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> <1684681.MCyL5Ev91y@ralph.baldwin.cx> <54018b1b2feaab3b05d7ed406eb8273c@mikej.com> From: Mateusz Guzik Date: Tue, 9 Jan 2018 01:31:19 +0100 Message-ID: Subject: Re: witness_lock_list_get: witness exhausted To: Michael Jung Cc: John Baldwin , FreeBSD Current , owner-freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 00:31:22 -0000 On Tue, Jan 9, 2018 at 12:41 AM, Michael Jung wrote: > On 2018-01-08 13:39, John Baldwin wrote: > >> On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: >> >>> Hi! >>> >>> I've recently up'd my processor count on our poudriere box and have >>> started noticing the error >>> "witness_lock_list_get: witness exhausted" on the console. The kernel >>> *DOES NOT* crash but I >>> thought the report may be useful to someone. >>> >>> $ uname -a >>> FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov >>> 19 18:41:20 EST 2017 >>> mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >>> >>> The machine is pretty busy running four poudriere build instances. >>> >>> last pid: 76584; load averages: 115.07, 115.96, 98.30 >>> >>> up 6+07:32:59 14:44:03 >>> 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock >>> CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle >>> Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free >>> ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other >>> 25G Compressed, 32G Uncompressed, 1.24:1 Ratio >>> >>> Let me know what additional information I might supply. >>> >> >> This just means that WITNESS stopped working because it ran out of >> pre-allocated objects. In particular the objects used to track how >> many locks are held by how many threads: >> >> /* >> * XXX: This is somewhat bogus, as we assume here that at most 2048 >> threads >> * will hold LOCK_NCHILDREN locks. We handle failure ok, and we should >> * probably be safe for the most part, but it's still a SWAG. >> */ >> #define LOCK_NCHILDREN 5 >> #define LOCK_CHILDCOUNT 2048 >> >> Probably the '2048' (max number of concurrent threads) needs to scale with >> MAXCPU. 2048 threads is probably a bit low on big x86 boxes. >> > > > Thank you for you explanation. We are expanding our ESXi cluster and even > though with standard edition I can only assign 64 vCPU's to a guest and as > much > RAM as I want, I do like to help with edge cases if I can make them occur > pushing > boundaries as I can towards additianional improvements in FreeBSD. > Can you apply this and re-run the test? https://people.freebsd.org/~mjg/witness.diff It bumps the counters to be "high enough" but also starts tracking usage. If you get the message again, bump the values even higher. Once you get a complete poudriere run which did not result in the problem, do: $ sysctl debug.witness.list_used debug.witness.list_max_used to dump the actual usage. -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Jan 9 02:10:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FDBEE778D3 for ; Tue, 9 Jan 2018 02:10:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDFD82AEB for ; Tue, 9 Jan 2018 02:10:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12989 invoked from network); 9 Jan 2018 02:09:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Jan 2018 02:09:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Mon, 08 Jan 2018 21:09:55 -0500 (EST) Received: (qmail 30082 invoked from network); 9 Jan 2018 02:09:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Jan 2018 02:09:54 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2512EEC7E56; Mon, 8 Jan 2018 18:09:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: USB stack From: Mark Millard In-Reply-To: Date: Mon, 8 Jan 2018 18:09:53 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <90803456-FCAE-4F2D-9CC8-18C395E2C952@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> <899567F7-0C02-4A60-ADA0-5F43A6CF594B@dsl-only.net> To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 02:10:02 -0000 On 2018-Jan-8, at 1:15 AM, blubee blubeeme = wrote: > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard = wrote: >> [The involvement of sysutils/fusefs-simple-mtpfs >> and sysutils/fusefs-libs and multimedia/libmtp >> in order to use the Media Transfer Protocol (MTP) >> against the LG v30 likely explains much of the >> performance difference vs. local UFS file >> systems. I provide some related notes.] >>=20 >> blubee blubeeme gurenchan at gmail.com wrote on >> Mon Jan 8 05:17:24 UTC 2018 : >>=20 >> [Note: the original was in a reply to a Jon Brawn >> post. I've merged it back with my post.] >>=20 >> > 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 >> >>>> >> >>>> =3D=3D=3D >> >>>> 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 >> >> >> >> =46rom 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? >> > >> [Extracted from a reply to a Jon Brawn post.] >> > @Mark Millard >> > I use sysutils/simple-mtpfs to mount the android device. >> > when I mount the phone through USB this is the relevant section: >> > /dev/fuse 356311 78912 277398 = 22% >> > /mnt >> > >> > That's the most complicated mount process that I use, >> > for the ssd it's just a simple mount /dev/device /mnt >> > relevant output: >> > /dev/da0 923913 121450 728550 = 14% >> > /mnt >> > >> > Can you tell me what information you're looking for so that I can = gather it >> > all up and send it. >>=20 >>=20 >> I do not find a /usr/ports/sysutils/simple-mtpfs . But I >> do find: >>=20 >> # ls -lTd /usr/ports/sysutils/*simple* >> drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 = /usr/ports/sysutils/fusefs-simple-mtpfs >>=20 >> And that was very important to know. >>=20 >> . . . >=20 >=20 > OK, forget the android specific usb issues for now; > there is quite a few layers of crud between the laptop and the android = device. >=20 > I have this SSD. >=20 > What are some tests that you'd like to run to test the speeds > on my end? Returning to just the SSD context. . . Because your pictures were missing the SSD for some reason, we first need to figure out if and how to see the SSD activity levels, such as via gstat. For now I focus on just that. You provided as information about the SSD: /dev/da0 923913 121450 728550 14% /mnt which is from "df -m". But I'd also asked for "mount" output. As an example for one of my contexts: # mount /dev/gpt/FBSDFSSDroot on / (ufs, NFS exported, local, noatime, = soft-updates) devfs on /dev (devfs, local, multilabel) Note the types of information displayed, which is very different from what df -m reports. ( /dev/gpt/FBSDFSSDroot is a label reference instead of a physical device and partition/slice number notation.) After mounting the partition/slice from the SSD, can you show the mount command's description of the partition/slice that you mounted? (Actually, your "df -m" output does not show a partition/slice notation. I'm not sure what to make of that.) There is another view of things that can be handy. . . (output is from one of my example contexts) # gpart show -p da0 =3D> 40 937703008 da0 GPT (447G) 40 1024 da0p1 freebsd-boot (512K) 1064 746586112 da0p2 freebsd-ufs (356G) 746587176 31457280 da0p3 freebsd-swap (15G) 778044456 159383552 da0p4 freebsd-swap (76G) 937428008 275040 - free - (134M) Note: Normally da0 would not show up in a mount line, instead it would be /dev/da0p2 for the UFS partition being mounted in my example. Your da0 might not show GPT or any other partition or slice structure (given the "df -m" output that you listed). (If zfs is involved, there may be better commands for some types of information above, but I've minimal ZFS background knowledge. You may have to explain your configuration if ZFS is in use on the SSD.) With that much information (if non-ZFS), I know what I expect to be listed in gstat -pd and in gstat -d . It is possible to use just: gstat -d and the same device and its partitions will show up multiple times for different ways they can be accessed. For example: dT: 1.073s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| fd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| cd0 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0p1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0p2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0p3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da0p4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| label/FBSDx64Cboot 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSSDboot 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSSDroot 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSSDswap 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSSDswap2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da1p1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2p1 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2p2 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2p3 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| da2p4 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSSDbkp 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| ufsid/ 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSboot 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSroot 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| ufsid/ 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFBswap 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| gpt/FBSDFSswap The sorter list from gstat -pd can be nicer to look at when its content happens to be sufficient for ones purpose at the time. Otherwise the fuller list can be used, giving specific rates and such for individual partitions. The initial question for gstat seems to be: can we find the mounted SSD partition/slice and/or the overall SSD device in the gstat output. Can you check on that? If you find the partition and/or overall device, can you show those lines so that I know what they look like? (gstat might not be an appropriate tool if the SSD is a ZFS-only device.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jan 9 03:26:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9620E7D812 for ; Tue, 9 Jan 2018 03:26:16 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83A9A2D83 for ; Tue, 9 Jan 2018 03:26:16 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-oi0-x22b.google.com with SMTP id e144so4243221oib.4 for ; Mon, 08 Jan 2018 19:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfSVhlgUrozFB5PHmfKvsLQm9blg79lQuK3buNTuQJA=; b=PfcJk3/aINR2zE29ZTVPAskKxoZKtq0CHPkaYy5Lb+9vY/jXx0U/HMifWWjy4AAVmA X6xydYKNffCXSNzs5esSTAb78Ul49tRyOfyy6xWgR0n5vUWstHdGrl5QQqKu3Wz/UnrL g30vpQjin2sYRq577RmMdcxYSlvKcpqHPwzytn26XkYkH2ZfLrGq7zl1IaUkZb9G6vER 9DDeIWN4GL4XZ2z07N+ZlpBKOltH625aO2rUuVswSa42AVb3y9nxD1nLfPjqhONdXcqy Amf9cpmi24rIXO2Vqk3A2+DjUB3hl7SUhkltq66TgFiOOqGml+dp8x1mudYfZTh55fes DYiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfSVhlgUrozFB5PHmfKvsLQm9blg79lQuK3buNTuQJA=; b=DCyPlo7walZgYO1RxauEtJB8hZbZqyCh7tgML8O9NWSBdHBH8CJTScxsa0e75adGuM MQLpm4+ZJvL0JWe0sVz8pf1lukJT0/me4OWb3Q9HTqkhlzCJyz2RrdPr5HQr5Bny1RTo iuJnUjdTQa0OpBSJfAeqFHNkuYTLa0c0Hr+ROZQyyY1T85jiVGJQIUMf6WRguOXh9sNZ 86DCEAtYxfprMujOrqAlSu8ebVowewP13xowqZkGSXjbnxr/XSmJExVCueNALTwUb3Q0 ALJwhu1FA+jyCQX8klO2I29+n2LQ7WFuizJ+ga027/uteQ1d5pLk8zpWI9BJBxtjwYqO 4t0A== X-Gm-Message-State: AKGB3mJyO5yyQb8LFYyTiY50GKZ+pjwvQWQtEmqynVmIvt2+POjvOQKa AIgnePet0OOWVFFMCNiq+nQBY9Wn6sBcN+1yUuSArw== X-Google-Smtp-Source: ACJfBotp4aLB0pQQ5PLGhMNq/AS00BHD0IYbZYiZUmDM1wU/9QJrLIrJaHurfIH3XsVu0r4fB72qm9R6Mxs/QfY/HOA= X-Received: by 10.202.199.149 with SMTP id x143mr8024702oif.216.1515468375485; Mon, 08 Jan 2018 19:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.1 with HTTP; Mon, 8 Jan 2018 19:26:14 -0800 (PST) X-Originating-IP: [71.70.173.127] In-Reply-To: <201801081526.w08FQhA8022158@pdx.rh.CN85.dnsmgr.net> References: <201801081526.w08FQhA8022158@pdx.rh.CN85.dnsmgr.net> From: Mark Heily Date: Mon, 8 Jan 2018 22:26:14 -0500 Message-ID: Subject: Re: Make periodic's output log to files if sendmail is disabled on install To: "Rodney W. Grimes" Cc: mykel@mware.ca, freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 03:26:16 -0000 On Mon, Jan 8, 2018 at 10:26 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > 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) ) > > I would not make this option dependent on sendmail, it should just > be a stand alone set of options > "Do you want logs" > #Completely turn off periodic in crontab > "Do you want logs mailed or stored in files" > #dtrt > > > 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! > > You can argue that when you provide a statistical data set, > until then this is speculation at best and should not be used > in an argument for or against a change like this. > > If I do nothing different in the installer please make sure > the systems end up as they have been configured for a very > long time to minimize POLA. And to minimize any changes to > all the post install configuration that people have been > doing up until now. > > Do you have "statistical data" to back up your claim that the the current installer settings cause the least amount of astonishment to users? Why should your speculation about POLA be given special treatment, while other people's speculation requires hard evidence? > Changing how things work out of the box undoes or adds to > changes people already have in place, and for larger instances, > probably have fully automated. > > I'm in favor of the suggestion of leaving the periodic cronjobs turned off by default in the next release. Any existing automation is likely geared towards turning those jobs off, and it would be trivial to turn them back on again. As long as user-visible changes are documented in the release notes, and users have an easy way to override the default, I am all for providing a cleaner and simpler out of box experience. From owner-freebsd-current@freebsd.org Tue Jan 9 07:37:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 813DCE6A062 for ; Tue, 9 Jan 2018 07:37:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 437EA6E7FE for ; Tue, 9 Jan 2018 07:37:04 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w097b7wi061640; Mon, 8 Jan 2018 23:37:13 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: , "freebsd-current" , "Rodney W. Grimes" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Mark Heily" Subject: Re: Make periodic's output log to files if sendmail is disabled on install Date: Mon, 08 Jan 2018 23:37:13 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:37:05 -0000 On Mon, 8 Jan 2018 22:26:14 -0500 "Mark Heily" said > On Mon, Jan 8, 2018 at 10:26 AM, Rodney W=2E Grimes < > freebsd-rwg@pdx=2Erh=2Ecn85=2Ednsmgr=2Enet> wrote: >=20 > > > 1) if sendmail is disabled during installation, have periodic's outpu= t > > > logged to files (per example in > > > https://www=2Efreebsd=2Eorg/cgi/man=2Ecgi?periodic(8) ) > > > > I would not make this option dependent on sendmail, it should just > > be a stand alone set of options > > "Do you want logs" > > #Completely turn off periodic in crontab > > "Do you want logs mailed or stored in files" > > #dtrt > > > > > 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! > > > > You can argue that when you provide a statistical data set, > > until then this is speculation at best and should not be used > > in an argument for or against a change like this=2E > > > > > If I do nothing different in the installer please make sure > > the systems end up as they have been configured for a very > > long time to minimize POLA=2E And to minimize any changes to > > all the post install configuration that people have been > > doing up until now=2E > > > > > Do you have "statistical data" to back up your claim that the > the current installer settings cause the least amount > of astonishment to users? Why should your speculation about > POLA be given special treatment, while other people's speculation > requires hard evidence? >=20 >=20 > > Changing how things work out of the box undoes or adds to > > changes people already have in place, and for larger instances, > > probably have fully automated=2E > > > > > I'm in favor of the suggestion of leaving the periodic cronjobs turned > off by default in the next release=2E Any existing automation is likely > geared towards turning those jobs off, and it would be trivial to turn > them back on again=2E As long as user-visible changes are documented > in the release notes, and users have an easy way to override the default,= I > am all for providing a cleaner and simpler out of box experience=2E Nothing personal, Mark=2E But my personal opinion/choice on this change; is to leave it as-is=2E My justification is that after *years* of users expectin= g, things to be as they are, and adjusting as-needed=2E Changing this will more likely cause more interference, than joy=2E Given that in the 30 some yrs I've been riding some form of BSD, and this is the first I've heard a request/complaint about this specifically=2E I'd wager those stats to be fairly reasonable=2E --Chris From owner-freebsd-current@freebsd.org Tue Jan 9 08:42:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13AF0E6E3C0 for ; Tue, 9 Jan 2018 08:42:27 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 758AA7125B for ; Tue, 9 Jan 2018 08:42:25 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MOfcU-1eTu4l474Y-006Aef for ; Tue, 09 Jan 2018 09:42:18 +0100 Date: Tue, 9 Jan 2018 09:42:12 +0100 From: "O. Hartmann" To: freebsd-current Subject: CUURENT: Cross-build for 11.1-RELENG (base packages) fails: *** [create-kernel-packages] Error code 70 Message-ID: <20180109094212.5d064f94@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PpqiGOa8RkELJj8AtpjiWwfeuPbaQz/rcDoOH9A2VYBWaYtO1dz E9EozxQl1b2wKxtl15WvAnKuIPjBw2k5iRkssH0/2b9AWl08FW0wL6qP1QYVCS/fP59vXOX /CwLfFbtscwYN/EaIA/+CA5dEJxaO8DLECYp1nKhu3L5RxzXfYbsF1s5NDavnV3ban4U6Qz wxj3cFZbtblyOh9My52og== X-UI-Out-Filterresults: notjunk:1;V01:K0:FtxV3zgZHiQ=:F8749jLPf03OQ6HPAUoo8P B5S/tHN8JYaE224lcH3ktvw8t9Wg7XR7ZfSTxc9/4vYap1qTvobDGhLxewyx7nGq5x/o60CFr /8sjQ8kRaEugAO+4oYtRO+DcRrUkxxF2ik9OVkd3jHkDJTvhLjBWWQ0Q7mivznARm7elrfszo TD4uxnVQhdYzD807CSX7B48vq4JeWZGis69xRwb3XxFqf1Xg9KDOx5kQME1SeHteTlpHiL17c mro9AnRDq4jjy1eVQWovIz7bSg9m2gX2LXr4e4wVMRiEsbE4CXYiTlAw7UjfvsjDhSu7NHeFf 1jbxi6IhPsF5fNtmGp6gLChdTcd0OSWa0cxy2rV8WG3Nmv1OdOVeHFLrsZnnp2Pwzo+Cew2GH u/FiezOo5UM4HpT+sf3NxWhY+/L3QmtnhqblJcC27aBSw9A9hOUIgRcDQZCp8HKO6HOfzN6XH Vw1vXwnxIvduPrgqD9FbPHks2tb2fHM8tnCkQeJMnpoFhM3v6XWbEu7r3CxJL0haCVn/VHSg3 a/oImbt34RsKXzzmypSmXYkfc88nyhc1JFjjgSevHGcp8Lj3XlovfhxDCejEQ0CXSnSDoNZsj vjya+NELMTKag/cIc55tMPRKsk5M7EKVC3Hhk8/1YRr3fwXTGKz3kBO7H5bAa65HzNiVZkCUg A1Bqjk0Y1VQs/gpXL0sXN7h3rcUzpktJSO3JZ3yURISdX9KoJdrsUPYMoP27GIyVXrHbBZtHq IEghbXqinWbJ6uI/yl4ygDBRfaR8tfMOYgSJTIn/S7Uu4HB/rLPQ4u2zFXQrObz7HQYFw4DpI LZp+TvWFCnYnBO6Y8m27aLWXO98xGMYGBA3/R4R76HH2sZBgP8= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 08:42:27 -0000 Recently, building 11.1-RELENG soruces on CURRENT (most recent on amd64) start failing with an obscure error, shown below. Is this something I need to take care of in make.conf, src.conf or anywere elese? Thanks in advance, Oliver [...] ===> Creating FreeBSD-kernel-generic-11.1_6 pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended ===> Creating FreeBSD-kernel-generic-debug-11.1_6 pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg: Unable to open plist file: /pool/sources/11.1-RELENG/obj/pool/sources/11.1-RELENG/src/amd64.amd64/kernelstage/kernel/kernel.GENERIC-debug.plist *** [create-kernel-packages] Error code 70 make[5]: stopped in /pool/sources/11.1-RELENG/src 1 error make[5]: stopped in /pool/sources/11.1-RELENG/src *** [create-kernel-packages] Error code 2 From owner-freebsd-current@freebsd.org Tue Jan 9 09:28:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 774D2E71275; Tue, 9 Jan 2018 09:28:17 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D94C8731C8; Tue, 9 Jan 2018 09:28:16 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LoVja-1f6G513NYQ-00gXci; Tue, 09 Jan 2018 10:28:13 +0100 Date: Tue, 9 Jan 2018 10:28:13 +0100 From: "O. Hartmann" To: freebsd-current , freebsd-ipfw@freebsd.org Subject: ipfw: manpage: semantics of "receive" and "xmit" interfaces Message-ID: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mq+cuV3ySu8lxOX1qfEGF9txahhSP7odxonSBJxe6Wx59GjWzk3 W5rTKExpQi+FKZFjmh90KyPECjJir6csgBBfRetVOB0L+swxmvN53q+Rg/6hmUzj9gJNnL+ TuJotUSPd6MxHqH5Q7ZTrTjrpGpsisjHRYFDBZtNyNCPEOCn5Zx1sZO6zToJIT54V7tSYCJ lxnLfp3A+tZRaqNSxewFw== X-UI-Out-Filterresults: notjunk:1;V01:K0:NMgAgjFtdww=:k3CdCgLy/MAPqIwihC0Ssw e+pFrDlnC1uA77oriNBCE68xHJtrMRif4npqMglWX0Znsu6g8nQipfIrugizDPHDxz3EokjYB xm6cdGiCGM1eJkT9AWS1acNK9JaeCG3jXs45kOoWyjvdKQDY/pI06hqn6tygHqkRYEsnKNKz0 fAsWLjRBmAPEIZnZoVElQbkfM2wyE/yVwTkOaCGKdNfLifMsBF7K+dmEIWmOfgWYgHh/ZRlfe paRlMoUOl/BuyyPvpOJwGjPKLXaYIeg169xyCvPDgSAoraRg6tSPl15aOHXWONN6M5tVwVuzZ Q0WV0GataGO76R1D1VF2g3oXnp/TNbAj6oEWsBDBvhdWOe5GN9Vr2B/b5kFzf6/+F1SB9Jr9W M1iUScYkoTGo3CfKyYUxRiExt34LlainlgA5DNfdc+Dz9LH79Q80Nm3n6eJlVwNdNCjCagh7G 6waGyQQTQeHeUu1SGfPLXmi05SEck3HszQDRxKqx+wMGxLGcjMjohTJwoCsE8eaXmqOi3hL2u 1fVtUEhZsoUZkx+BChPQXDOKgWMv4HFlmCeusfbIs8CRxNLCris9bTK7+cuxzpULfuZ8UHFvZ I9ovRP19nT1E6eIr//iaiQs0XuCw4d0yojKSPtIfleEaEOgwvhuBZLPvBVPVxF8ap+cE2u/vG pVfjgh/aRDsE5HxuAVA6A8/SOeUf4c/ZZshsTh/SOEoIMNfuobZxx8lUycJtsy46CB4qZLYzO zIfyKyO5T7ziVj9sSJ9fbcVFXtcM/i+Ik4/ORjhkbqn6mgslsyKUTubY2j9+nH60KRWDWQGJl XgQ8oCT2P6ddlg8sZKlIfqYx6f3vfQnibu9BrhzKy5Zo4IfGvc= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 09:28:17 -0000 I feel confused by the ipfw manpage, while trying to setup a set of filtering rules on a small router project with in-kernel NAT. It is a kind of hard based on the ipfw man page to figure out, what the meaning is of the receive and xmit interface. Maybe it is only me that has problems, but I doubt it, since I tried to ask around my department and it broke loose a discussion - based upon what one can read in the manpage - not reading source codes. In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is also an example: ipfw add deny ip from any to any out recv ed0 xmit ed1 Can someone explain a bit more what the semantics of these is? I get especially confused by the subsequent blocks of text following the line I mentioned above. Since not everybody using FreeBSD is capable of studying the kernel sources, I have difficulties to put those statements in line with a visualization of the packet flow. A local host receiving a packets destined for the local host can not have xmit interface? If I imagine, that the recv interface might be the interface adjacent directly to the in/out port depicted in section PACKET FLOW it doesn't give me any idea why there is no xmit interface. If it's my dumb brain missing things, I'm sorry. Otherwise I'd be glad to have some more informations and maybe the manpage could be enriched with some notes helping other poor people like me. Thanks in advance, Oliver From owner-freebsd-current@freebsd.org Tue Jan 9 07:01:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64C31E67ED4 for ; Tue, 9 Jan 2018 07:01:41 +0000 (UTC) (envelope-from mykel@mware.ca) Received: from Vice.ServerNorth.net (vice.ServerNorth.net [209.44.123.194]) by mx1.freebsd.org (Postfix) with ESMTP id 43D906D58E for ; Tue, 9 Jan 2018 07:01:40 +0000 (UTC) (envelope-from mykel@mware.ca) Received: from mail.servernorth.net (localhost [127.0.0.1]) by Vice.ServerNorth.net (Postfix) with ESMTP id 882B056860 for ; Tue, 9 Jan 2018 02:01:33 -0500 (EST) Received: from mykel@mWare.ca by mail.servernorth.net (Archiveopteryx 3.1.4) with esmtpsa id 1515481291-19775-19773/9/1; Tue, 9 Jan 2018 02:01:31 -0500 Subject: Re: Make periodic's output log to files if sendmail is disabled on install To: freebsd-current@freebsd.org References: From: mykel@mware.ca Message-Id: Date: Tue, 9 Jan 2018 02:01:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA X-Mailman-Approved-At: Tue, 09 Jan 2018 11:50:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:01:41 -0000 On 2018/01/08 00:34, Chris H wrote: > On Sun, 7 Jan 2018 23:05:44 -0500 said > >> 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. But this way partitions don't get filled. Massive backlogs don't build, etc. Hence the logrotation benefit - the data's not permanently disposed of, but it's also not slowly killing a machine. You keep the benefit of the default periodic jobs. On 2018/01/08 10:26, Rodney W. Grimes wrote: >> 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! > You can argue that when you provide a statistical data set, > until then this is speculation at best and should not be used > in an argument for or against a change like this. Okay: In the ~300 machines I manage, 2 of them have their mailers set up to get those messages in front of an admin... and that's because those two machines are MTAs. The other 500+ FreeBSD installs I've done for clients are in the same boat... nobody wants more email, and no monitoring system is parsing the messages. (And who wants a passive monitoring system that only alerts daily?) Arguably having a machine years (or months!) down the road opaquely running out of disk is _not_ POLA. I'm not going to argue too hard for point #2, but I don't see how #1 is a bad idea: No MTA? Don't send emails. (Or create zillions of bounces.) On 2018/01/08 22:26, Mark Heily wrote: > I'm in favor of the suggestion of leaving the periodic cronjobs turned > off by default in the next release. Any existing automation is likely > geared towards turning those jobs off, and it would be trivial to turn > them back on again. As long as user-visible changes are documented > in the release notes, and users have an easy way to override the default, I > am all for providing a cleaner and simpler out of box experience. Arguably turning off periodic is far more disruptive than rendering it's output useful. I also think changing the output to logfiles (in absence of an MTA) is much better POLA than the 'new' offer of nuking /tmp on reboot; while it is an option, it's far more dangerous to delete data than not fill a disk with cruft. Myke From owner-freebsd-current@freebsd.org Tue Jan 9 17:19:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1892E64E2E for ; Tue, 9 Jan 2018 17:19:27 +0000 (UTC) (envelope-from clutton@zoho.com) Received: from sender-pp-091.zoho.com (sender-pp-091.zoho.com [135.84.80.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5845C35F0 for ; Tue, 9 Jan 2018 17:19:26 +0000 (UTC) (envelope-from clutton@zoho.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:subject:from:to:cc:date:in-reply-to:references:content-type:mime-version; b=UCC5AVioOdiAmQ1FlBefVLkiafAqyQBPKLXjPaH+xTMc91GZqHK8mcMZ6UP62P0GbNrszbQwFr8I vzs85UnVUv8bmiyILbTPKXOX9gtcj0q8gS0bbtc54k/Tf1hLolvA Received: from [10.118.46.204] (tegus-52.infomir.com.ua [79.142.196.52]) by mx.zohomail.com with SMTPS id 1515518359430308.48176736482276; Tue, 9 Jan 2018 09:19:19 -0800 (PST) Message-ID: <1515518348.9510.5.camel@zoho.com> Subject: Re: thinkpad carbon 5thgen + thunderbolt 3 dock From: clutton To: Michael Gmelin Cc: FreeBSD Current Date: Tue, 09 Jan 2018 19:19:08 +0200 In-Reply-To: <20180109004058.2f6c096d@bsd64.grem.de> References: <1515449761.3483.14.camel@zoho.com> <20180109004058.2f6c096d@bsd64.grem.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-9EbOk2OzGvLCH9b7aNRI" X-Mailer: Evolution 3.24.2 FreeBSD GNOME Team Mime-Version: 1.0 X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-ZohoMail: Z_30320720 SPT_1 SLF_E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 17:19:27 -0000 --=-9EbOk2OzGvLCH9b7aNRI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2018-01-09 at 00:40 +0100, Michael Gmelin wrote: >=20 > On Tue, 09 Jan 2018 00:16:01 +0200 > clutton wrote: >=20 > > Hi list. > >=20 > > I have a thinkpad carbon 5th gen with ThinkPad Thunderbolt 3 Dock. > > The > > notebook doesn't work well with dock station, and I'm looking > > forward > > for some suggestions. Here it goes: > >=20 > >=20 > > 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? >=20 > ath usually works well, but Lenovo uses a BIOS whitelist of supported > devices, so you're probably out of luck. >=20 > >=20 > > 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. >=20 > Is this similar to anything described in those bugs? >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211713#c9 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224064 >=20 Exactly what I have, thank you. Unfortunately it is not fixed yet. --=-9EbOk2OzGvLCH9b7aNRI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEJS/zE0mE1p2+tYanfbA/jbLI/pAFAlpU+YwACgkQfbA/jbLI /pAiag//fyyUDL1c7j3mzsqovj8Sc3IFuNoZbODW5Nk1GHN4kL0aOVBOqjxnS84s olZSmLkGrOCaAN9SioKD1WwYaaokwD35ja0VISXdvtK2NRJYhanU1OiwAb5M0W0q g1etbc8BZURQj/9SCJHBp1oEltKjWLDvZxvvEIpJYor3MghX46iz9MFAfBegG5Xt WW1KFO42bpnwCaGuT95aEVQDeLndvsgBJ5sNhnO1g3BBHleZIbCFI0Uycs5eKzx1 oScN8SNokZsQi52dADZxJE6HBnAsHpuL9cO9coheQQJtrocm3nMLNwlGOi85RMOO Fk0JtFhSUiPi51UFPtmZItQxFfUFOj1kYIkjx8YBK5sH8A5w1irXROM2ZPp0x9Sw wwTKx8Pujjq5O8MMYN3C3iB9pvXwxqWUCD/ClIIcpPCkxFGa02vWDpPD8+oOPtF6 vj1f8L5eHAsqoPevcvO+BZ4cN3bZ8erYfARZmKrUaWqYB3x9v3QMZ8VXVgAiMKYf aTHWv5p2T8Y9dNI+3IVdmINx2GdwvGEEpRqgoNPHTKk9L8lOQqXoTGHb6Si0s6ij FYXurl7zEteJ0+DKkO3MMZEJzNKLSk8qgEOAae1+7oY+PGDeG2bg6yjNGdtTn9/g 3CCss0m2BNrgDSHF6kduV8NqgQIp5Ee+QUL0stj9tfsQGgFRe0E= =a7/c -----END PGP SIGNATURE----- --=-9EbOk2OzGvLCH9b7aNRI-- From owner-freebsd-current@freebsd.org Tue Jan 9 18:26:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 927DBE68B55; Tue, 9 Jan 2018 18:26:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward104o.mail.yandex.net (forward104o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::607]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 301BE6998B; Tue, 9 Jan 2018 18:26:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback11g.mail.yandex.net (mxback11g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:90]) by forward104o.mail.yandex.net (Yandex) with ESMTP id 3CAD770320E; Tue, 9 Jan 2018 21:26:15 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback11g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dd0r9c8cYP-QFZqpPa0; Tue, 09 Jan 2018 21:26:15 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1515522375; bh=OigOFx3UUjm7RgaCoB6YHSAcHDn8yhjTXCIKCiwjfw0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=e+soMPQvgxsEu9+OP29m1Oa+LgjlQXsN8Lj8qUmAqBSpJ7sK+gS+93dE/xLEL71WZ hp929d9ako1vvjy/Bpc+pBTJgqkFQoq6EF04Nc5Wg4RJ/AmwQtA3s/krBWCVE70OS+ DBVKDxmP97weRkLOd7JDVI40YF1CflE2+3Qor86E= Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 0V4If2IlfM-QEsGoYf9; Tue, 09 Jan 2018 21:26:14 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1515522374; bh=OigOFx3UUjm7RgaCoB6YHSAcHDn8yhjTXCIKCiwjfw0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=A3lIpf2cJvcWRqgLLlPNDOsB++fxk0B5dsqboNBkHJc9gy7RyKYuCfjg0/PJ45Esn ZW4YsTudGgVWw4MSIWFOz2gFX8t1aR6PP9wHhzr3BHAUk1KmDoaCY1yTNr0+Vv8skT VTKlaoidh4I7S4TWbEls+XZ3bjp/ntJz3hh3nyTg= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces To: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org References: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <5e6811ff-70c6-ee74-bf04-1319e9002b29@yandex.ru> Date: Tue, 9 Jan 2018 21:23:54 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PKz3ZsVTGQoxL8RmsJ1SZVgP3UGYDFUeT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 18:26:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PKz3ZsVTGQoxL8RmsJ1SZVgP3UGYDFUeT Content-Type: multipart/mixed; boundary="B7DR8RluztSdH7yswzwe7UbEIGYyiAv1L"; protected-headers="v1" From: "Andrey V. Elsukov" To: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Message-ID: <5e6811ff-70c6-ee74-bf04-1319e9002b29@yandex.ru> Subject: Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces References: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> --B7DR8RluztSdH7yswzwe7UbEIGYyiAv1L Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 09.01.2018 12:28, O. Hartmann wrote: > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). Ther= e is > also an example: >=20 > ipfw add deny ip from any to any out recv ed0 xmit ed1 >=20 > Can someone explain a bit more what the semantics of these is? I get es= pecially > confused by the subsequent blocks of text following the line I mentione= d above. > Since not everybody using FreeBSD is capable of studying the kernel sou= rces, I > have difficulties to put those statements in line with a visualization = of the > packet flow. A local host receiving a packets destined for the local ho= st can > not have xmit interface? If I imagine, that the recv interface might be= the > interface adjacent directly to the in/out port depicted in section PACK= ET FLOW > it doesn't give me any idea why there is no xmit interface.=20 When your system has two interfaces ed0 and ed1, and it acts as router, a forwarded packet can be checked by firewall two times: 1. When a packet is received on ed0 interface, mbuf associated with this packet gets a property "receiving interface". This packet is checked for inbound direction and can be matched by "in" and "recv ed0" opcodes. If it was not dropped by rules, it will go through IP stack and can be forwarded according to routing table via interface ed1. 2. When the routing decision was made (i.e. outbound interface is determined) a packet checked by firewall again, now for outbound direction. And it can be matched by "out" and "xmit ed1" opcodes. The opcode "recv ed0" still can be matched too, but "in" opcode will not matched. A packet destined for local host is consumed by local IP stack and will not forwarded. It is checked by firewall only one time (usually). Thus it can not have xmit interface. --=20 WBR, Andrey V. Elsukov --B7DR8RluztSdH7yswzwe7UbEIGYyiAv1L-- --PKz3ZsVTGQoxL8RmsJ1SZVgP3UGYDFUeT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlpVCLoACgkQAcXqBBDI oXrg7Af/UtYkLPPXrtOpqbvB4vuAUtHygXAujjmDUcfqtbFfxp2H4hEUotXJuPIk xNp8Y8TQxb6bOWwwJiqJgvVAYPVT5ffob0Rb6iYZ0JDTL6qRGJ32vSorGaEF8kn+ MIV077lYAuTn+JUQE5Ecx8hw4UbBu820CvxY1hPhWsKCBfFpIgOsR59uKw1B5dmU NmQ6leTGfKIOPO1rsjnSIpxm4lBCSwXThsTIZDVaxF1DeF9MzZUOnEgXDZw7EYSL 5xoF6oMZcRtZ7KXW8yCg52iPNMoJudi9BjP/d8gE5YB/9vsM6zeDv1CC3bjS317b 3v0WsYurElm5lQABSR7tuJ2qubDTAg== =79yQ -----END PGP SIGNATURE----- --PKz3ZsVTGQoxL8RmsJ1SZVgP3UGYDFUeT-- From owner-freebsd-current@freebsd.org Tue Jan 9 19:51:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0656CE6DE76 for ; Tue, 9 Jan 2018 19:51:00 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D6BF76D48C for ; Tue, 9 Jan 2018 19:50:59 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mailman.ysv.freebsd.org (Postfix) id D6004E6DE74; Tue, 9 Jan 2018 19:50:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5A33E6DE73 for ; Tue, 9 Jan 2018 19:50:59 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEFEA6D48B for ; Tue, 9 Jan 2018 19:50:59 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mail-pf0-x235.google.com with SMTP id d23so9309676pfe.9 for ; Tue, 09 Jan 2018 11:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jroberson-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:user-agent:mime-version; bh=HFkDc53lcoFqrkAlwZW4Jb/CfGjE+U8FWPcYyrrlTUo=; b=ROPJA0u/rjNKwHdobhM5krVRpXIyryElT7LSDouVRURg9JBAGpz6m8YyYXCoWMniYD Ia0dxNFjmUatRF76UnvrX67Mgy4R1hFaPFY8Wif3CLo2cIRbDiDwfPtgyugJxAjDCv8G Lb6hM1HmTYZuM9fREfmvAWfZ6bmO5O0Bym/EmzyWfa+9kzzWs5p+BeEvQK3uZzhRKYde zpo2crTrWQwvPotTEXevGpRcLZQB7SrQRWhUyO3DJPQ5RgThqh/eZGXSAw3yQxMEC5Bo DRt0030fL8CIOLx4GW8ExXpgKsv5KmWaUihzdzJcjWxPPTp9CWPg29MYiO27lHEDig0B e8MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:user-agent :mime-version; bh=HFkDc53lcoFqrkAlwZW4Jb/CfGjE+U8FWPcYyrrlTUo=; b=TXEbQCs3vrxzdOqSkN053ynf4IKz6fqoOrrSvAOaBL4e8VM8fdReCKQE9BgO6JyafH UPcc9FIBTrIoxnzI15y4d8URWiCUnoWQ0XXZOsu2WlnQuyDqFYNqd7ra1bsqVsUhb+AB n/EARnPP5CK4diYdmDB2k6fQYn6fDd1JXTcaUfqRs5bBuKah92tA/ujzsZPg1Tktq/hq CQVgu8ReuAydW1wKRUXE7/kUNNH6cwXlNvRJeCn6DqRJDbxdku3t8OySSKrgacUHvOdU WKKorIzxdla4XrbZHRza6ZbEX2ExMQav24qD8lwgFvpze/hDJGQN86bn6PsJlzpQzUfd s+lA== X-Gm-Message-State: AKGB3mJ+FK48a8gkcMwEgMElgb0+km/TLVk20KsUL5G3dwtTr67SVsQz A3ckL99u85en2W8ps+byGhSXVygn X-Google-Smtp-Source: ACJfBos6hiCzZy+1b3RYR+rwrgDwBnC7JohfkJdVIskLiBppr/5YADy/fZI4j8XgJacxeL+AHk0mSQ== X-Received: by 10.84.140.133 with SMTP id 5mr16798724plt.207.1515527458801; Tue, 09 Jan 2018 11:50:58 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by smtp.gmail.com with ESMTPSA id k2sm28057599pff.150.2018.01.09.11.50.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 11:50:58 -0800 (PST) Date: Tue, 9 Jan 2018 09:46:54 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: current@freebsd.org Subject: New NUMA support coming to CURRENT Message-ID: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 19:51:00 -0000 Hello folks, I am working on merging improved NUMA support with policy implemented by cpuset(2) over the next week. This work has been supported by Dell/EMC's Isilon product division and Netflix. You can see some discussion of these changes here: https://reviews.freebsd.org/D13403 https://reviews.freebsd.org/D13289 https://reviews.freebsd.org/D13545 The work has been done in user/jeff/numa if you want to look at svn history or experiment with the branch. It has been tested by Peter Holm on i386 and amd64 and it has been verified to work on arm at various points. We are working towards compatibility with libnuma and linux mbind. These commits will bring in improved support for NUMA in the kernel. There are new domain specific allocation functions available to kernel for UMA, malloc, kmem_, and vm_page*. busdmamem consumers will automatically be placed in the correct domain, bringing automatic improvements to some device performance. cpuset will be able to constrains processes, groups of processes, jails, etc. to subsets of the system memory domains, just as it can with sets of cpus. It can set default policy for any of the above. Threads can use cpusets to set policy that specifies a subset of their visible domains. Available policies are first-touch (local in linux terms), round-robin (similar to linux interleave), and preferred. For now, the default is round-robin. You can achieve a fixed domain policy by using round-robin with a bitmask of a single domain. As the scheduler and VM become more sophisticated we may switch the default to first-touch as linux does. Currently these features are enabled with VM_NUMA_ALLOC and MAXMEMDOM. It will eventually be NUMA/MAXMEMDOM to match SMP/MAXCPU. The current NUMA syscalls and VM_NUMA_ALLOC code was 'experimental' and will be deprecated. numactl will continue to be supported although cpuset should be preferred going forward as it supports the full feature set of the new API. Thank you for your patience as I deal with the inevitable fallout of such sweeping changes. If you do have bugs, please file them in bugzilla, or reach out to me directly. I don't always have time to catch up on all of my mailing list mail and regretfully things slip through the cracks when they are not addressed directly to me. Thanks, Jeff From owner-freebsd-current@freebsd.org Tue Jan 9 23:00:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1304EE78730; Tue, 9 Jan 2018 23:00:16 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D374B75CF5; Tue, 9 Jan 2018 23:00:15 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w09N0BnV028969; Tue, 9 Jan 2018 15:00:11 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w09N0AAo028968; Tue, 9 Jan 2018 15:00:10 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801092300.w09N0AAo028968@pdx.rh.CN85.dnsmgr.net> Subject: Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces In-Reply-To: <5e6811ff-70c6-ee74-bf04-1319e9002b29@yandex.ru> To: "Andrey V. Elsukov" Date: Tue, 9 Jan 2018 15:00:10 -0800 (PST) CC: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 09 Jan 2018 23:10:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 23:00:16 -0000 > On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get especially > > confused by the subsequent blocks of text following the line I mentioned above. > > Since not everybody using FreeBSD is capable of studying the kernel sources, I > > have difficulties to put those statements in line with a visualization of the > > packet flow. A local host receiving a packets destined for the local host can > > not have xmit interface? If I imagine, that the recv interface might be the > > interface adjacent directly to the in/out port depicted in section PACKET FLOW > > it doesn't give me any idea why there is no xmit interface. > > When your system has two interfaces ed0 and ed1, and it acts as router, > a forwarded packet can be checked by firewall two times: > > 1. When a packet is received on ed0 interface, mbuf associated with this > packet gets a property "receiving interface". This packet is checked for > inbound direction and can be matched by "in" and "recv ed0" opcodes. in, recv and via options > If it was not dropped by rules, it will go through IP stack and can be > forwarded according to routing table via interface ed1. > > 2. When the routing decision was made (i.e. outbound interface is > determined) a packet checked by firewall again, now for outbound > direction. And it can be matched by "out" and "xmit ed1" opcodes. The in, recv and via options > opcode "recv ed0" still can be matched too, but "in" opcode will not > matched. > > A packet destined for local host is consumed by local IP stack and will > not forwarded. It is checked by firewall only one time (usually). Thus > it can not have xmit interface. And a packet generated localy would not have a recv interface. > -- > WBR, Andrey V. Elsukov > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Jan 10 01:39:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EF0DE9A8DE for ; Wed, 10 Jan 2018 01:39:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB86F7B4FE for ; Wed, 10 Jan 2018 01:39:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x230.google.com with SMTP id u62so13889183ita.2 for ; Tue, 09 Jan 2018 17:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zmUx5KicIidXTD0ivFHlkMbZzbxLt308ED+MrvCcgzE=; b=BVq859xKHFPiz9ZXOuMnT0zXsamz6m8GcLPaZZvq5mmW6Ia3mbIVWjzwYvQj1ROOs/ QSZGhUokCEBqhRoyesRDbqVt8aRaMEhV3PWzAts9Pf7Yo3a5citVEKXUP5iZrh2bQ4jH TN/0+UqMpssiY8unVSMYUE72tXGpzeIg4WuY8GRhd4hBb1l4ThCD4H701iaiNEcOZuhP KlJdCUL5dx/VEjYONRfmoSn89Z0yxsGF0FGt+8UlFrEfPvf8h+dVFq1etBqTJL/LvGym aD1zooybZ8rasqt95oli2vyQnX0Rpnqrg3jn3gWurR647cleHBomjqABYJWG3R84jYVp AYbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zmUx5KicIidXTD0ivFHlkMbZzbxLt308ED+MrvCcgzE=; b=HMmagSyr8qqP4zucE+qz6VtDCY3Jrz6DKwXPLBK5fdojHwGIesI0SgOgRUSbxTbxTV nH5eBLDlIbITH+QRTDkf5d9MzC9d2Y3QePsSHHuHei4JHlBZTAS7uBj72Yo30KzMFQq7 im6YPohZz6ev7lQ0uHc73gvCFI46WvRZXkTgE2Ok+6/uN4B7hRmKee6csi3WhZYLjV3E eF2EQ6nSXMQz/I8/J/goTIp09zfa5BTQ9nbgm3/mxl+eaqOs4i5aD18epNiQrl2yice3 7ymb6bn/VII2WygEKiWrbjq2K9Vhn3CfQTg22cobU3xvFTF7wPG1hn/Mabp2LAHU8nbG vQ8g== X-Gm-Message-State: AKGB3mInHq1iUKaauz+O8wSrMWLe1OWXw+bWcSug4qnp3ZIix8lvY9po A3RDekzWjjxyvP+BRrYbNs2yb4rnJnUjxS506M2vNmfJ X-Google-Smtp-Source: ACJfBovgo3U/Hlp958a62xnA+M2FIJCANCU22uC8nke0olmbV1DJBkYg/Hq8rMXLD/bJsHq711wFI9aVzQ3RfLZmJKM= X-Received: by 10.36.145.208 with SMTP id i199mr16436807ite.81.1515548359293; Tue, 09 Jan 2018 17:39:19 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.163 with HTTP; Tue, 9 Jan 2018 17:38:58 -0800 (PST) In-Reply-To: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> From: Ed Maste Date: Tue, 9 Jan 2018 20:38:58 -0500 X-Google-Sender-Auth: uPwTxfgcmEszjJbRUUlix8iDd5o Message-ID: Subject: Re: LLD: man pages missing? To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 01:39:20 -0000 On 25 December 2017 at 15:16, O. Hartmann wrote: > I have installed most recent CURRENT as of r327219 with LLD_IS_LD=YES set > via /etc/src.conf. > > I try to find some options and tried "man ld", "man lld" and "ld.lld". In the the latter > two cases there can nothing be found on the system and man ld always seems to refer to > the GNU linker - which is, I believe, the linker reached by /usr/bin/ld.bfd. There is > also a linker "ld" in /usr/local/bin/ld from binutils-2.28,1. > > Can someone help? krion@ started a man page, and Arshan Khanifar expanded it based on ld.lld --help output; I've added a brief introduction and have expanded the descriptions for some of the options. What we have so far is in review at https://reviews.freebsd.org/D13813. It's still rather bare-bones, but I would like to commit it soon so that we have something to start from, and continue fleshing it out in HEAD. Review and additional content most welcome. From owner-freebsd-current@freebsd.org Wed Jan 10 02:30:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70B94E5D0BE for ; Wed, 10 Jan 2018 02:30:31 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35CBF7D3FA for ; Wed, 10 Jan 2018 02:30:30 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w0A2UhU7029464 for ; Tue, 9 Jan 2018 18:30:49 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: libc.so.7: undefined reference to `rpc_call' Date: Tue, 09 Jan 2018 18:30:49 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 02:30:31 -0000 Apologies in advance, as this is on RELENG_11=2E But I'm not on the releng li= st=2E I get libc=2Eso=2E7: undefined reference to `rpc_call' building world on a jail I created to update some older boxes that are well past due=2E The jail(8) host is running a recent -CURRENT, and the jail is running 11=2E1 from the most recent install media for releng=2E Is this a known problem? If at all possible I'd like to stay as close to the version of 11 I'm currently attempting to build=2E Anyway, any informa= tion is greatly appreciated=2E Thanks! --Chris From owner-freebsd-current@freebsd.org Wed Jan 10 07:13:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7504FE6DF9B for ; Wed, 10 Jan 2018 07:13:28 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 525912C48 for ; Wed, 10 Jan 2018 07:13:27 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w0A7DfO9076987 for ; Tue, 9 Jan 2018 23:13:47 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: Re: libc.so.7: undefined reference to `rpc_call' Date: Tue, 09 Jan 2018 23:13:47 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 07:13:28 -0000 On Tue, 09 Jan 2018 18:30:49 -0800 said > Apologies in advance, as this is on RELENG_11=2E But I'm not on the releng > list=2E > I get > libc=2Eso=2E7: undefined reference to `rpc_call' > building world on a jail I created to update some older boxes that are we= ll > past due=2E The jail(8) host is running a recent -CURRENT, and the jail is > running 11=2E1 from the most recent install media for releng=2E >=20 > Is this a known problem? If at all possible I'd like to stay as close > to the version of 11 I'm currently attempting to build=2E Anyway, any > information > is greatly appreciated=2E >=20 Here's some better context: cc -target x86_64-unknown-freebsd11=2E1 --sysroot=3D/usr/obj/usr/src/tmp -B/u= sr/obj/usr/src/tmp/usr/bin -O2 -pipe -D_INCOMPLETE_XOPEN_C063 -I/usr/src/li= b/libnetbsd -I/usr/src/contrib/netbsd-tests -g -std=3Dgnu99 -fstack-protect= or-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized= -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-v= ariable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equali= ty -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno= -address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Qunused-arguments -L/usr/obj/usr/src/lib/libnetbsd -o faccessat_t= est=2Efull t_faccessat=2Eo -lprivateatf-c -L/usr/obj/usr/src/lib/libnetbsd -ln= etbsd /usr/obj/usr/src/tmp/lib/libc=2Eso=2E7: undefined reference to `rpc_call' cc: error: linker command failed with exit code 1 (use -v to see invocation= ) >=20 >=20 --Chris From owner-freebsd-current@freebsd.org Wed Jan 10 17:36:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAACCE6A298 for ; Wed, 10 Jan 2018 17:36:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1A7A80AE3 for ; Wed, 10 Jan 2018 17:36:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id v30so268181iov.7 for ; Wed, 10 Jan 2018 09:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kiUt7D3lUPxqG5IjE+nHVHjTLeT1NTzUDIJrXwts6iw=; b=n7BfEiooc0knvpV1Hn+L0tbjmHDmRixLtvOXi6Hn374SVGdos+NC7g+nckS7wvzKBK wQ3NT3aBZHSceCpRmaPCnD1JVZyPfLzaWmXnuxb0do9YuiT4HLWUq4B4crOIZKqXxEL9 mExlLMF4nstB+VLAcNHhB6blk+pIk86RT6v5D7MQdC6K8eh6sErLcEDB94WdpgCoHx/5 GPEE/yWMIYsZXB7NxpU6prHEmKLdxe9mUWRLwtItO4lwKWJarUhAu7r+kwynWAkzFWBW rIyXwT7AuVDAztA00oSPNGhEjRH4iD3Z42eQ2zTPqJDbhsNtH5K6U3FPcYvCEVYlwX0B xX6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kiUt7D3lUPxqG5IjE+nHVHjTLeT1NTzUDIJrXwts6iw=; b=lMSYzzN71XUDM28rm17eAoRrXxo9mj0MpNYppmm8FI/GH1dFTQ801Z6WaJZr0a9lhQ wYt5Mdsyn9OjLC0b5y27exNs55oKByaVyJifX0Iy7k+3R9SPrNoXP+Bwb/Z/fWGGKF2i ROsD0yuM7YFnr1x3geW9HInxpnkrGmMIWtZYHnOAiMpN6RlPA2CHGTuvqdixjbmfS1S6 k8QDYZ7kPh/+OSgoOeBSxr8lObO0wieEq1y/4dOr+IZ7w8nL86uOka8eiCR/1EpzfLbO 2iXUtWVoOOyA5WwK4v91KX0wxF8h+VcACNIHgR9d9RUIMIs8nBYpIaRP8P0+u3t5BUPD SdeA== X-Gm-Message-State: AKwxytd2DsAv0/g9V/Q62K8boPNjSeTNsDkv5uE0Bou4tcLqlMXTolKR Jrh8+n9T0gSa4QxjeW1RaUfwtfdA4aaRwl4q78mVKQ== X-Google-Smtp-Source: ACJfBosk4vWlgYd4PeP3LJTMgUce/IuKMGzkPQBMhf38N1wC2spO2c4oRz9/QTB5YlO9GGXUg0PtBpD5G7ikyQMIqp0= X-Received: by 10.107.78.12 with SMTP id c12mr18161151iob.63.1515605808968; Wed, 10 Jan 2018 09:36:48 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.163 with HTTP; Wed, 10 Jan 2018 09:36:28 -0800 (PST) In-Reply-To: References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> From: Ed Maste Date: Wed, 10 Jan 2018 12:36:28 -0500 X-Google-Sender-Auth: 5JH5c5LjZEV4qGuudzVFQtcPjmU Message-ID: Subject: Re: LLD: man pages missing? To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 17:36:50 -0000 On 9 January 2018 at 20:38, Ed Maste wrote: > > What we have so far is in review at > https://reviews.freebsd.org/D13813. It's still rather bare-bones, but > I would like to commit it soon so that we have something to start > from, and continue fleshing it out in HEAD. Review and additional > content most welcome. I've now committed this initial version as r327770 after incorporating feedback from bjk@. We'll iterate on expanding the documentation for the individual options, and submit this upstream to lld soon. I'm still very interested in additional review and content. From owner-freebsd-current@freebsd.org Wed Jan 10 18:10:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E431E6C11C for ; Wed, 10 Jan 2018 18:10:06 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA898297C for ; Wed, 10 Jan 2018 18:10:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w0AIAFEh024559 for ; Wed, 10 Jan 2018 10:10:21 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: Re: libc.so.7: undefined reference to `rpc_call' Date: Wed, 10 Jan 2018 10:10:21 -0800 Message-Id: <9df5bee07da61ea0c3a2bd1d0bcb8c28@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:10:06 -0000 On Tue, 09 Jan 2018 23:13:47 -0800 said > On Tue, 09 Jan 2018 18:30:49 -0800 said >=20 > > Apologies in advance, as this is on RELENG_11=2E But I'm not on the relen= g > > list=2E > > I get > > libc=2Eso=2E7: undefined reference to `rpc_call' > > building world on a jail I created to update some older boxes that are = well > > past due=2E The jail(8) host is running a recent -CURRENT, and the jail i= s > > running 11=2E1 from the most recent install media for releng=2E > >=20 > > Is this a known problem? If at all possible I'd like to stay as close > > to the version of 11 I'm currently attempting to build=2E Anyway, any > > information > > is greatly appreciated=2E > >=20 > Here's some better context: >=20 > cc -target x86_64-unknown-freebsd11=2E1 --sysroot=3D/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -D_INCOMPLETE_XOPEN_C063 > -I/usr/src/lib/libnetbsd -I/usr/src/contrib/netbsd-tests -g -std=3Dgnu99 > -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch > -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments=20 > -L/usr/obj/usr/src/lib/libnetbsd -o faccessat_test=2Efull t_faccessat=2Eo=20 > -lprivateatf-c -L/usr/obj/usr/src/lib/libnetbsd -lnetbsd > /usr/obj/usr/src/tmp/lib/libc=2Eso=2E7: undefined reference to `rpc_call' > cc: error: linker command failed with exit code 1 (use -v to see invocati= on) >=20 > >=20 > >=20 > --Chris Feel free to disregard=2E I'm under pressure to get this done=2E So I've svn up'ped the src to 11-STABLE, and ports to HEAD, and am making another attempt=2E I'll report back, should this also happen on these revisions=2E Thanks! --Chris >=20 >=20 > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Wed Jan 10 18:29:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E006E6D834 for ; Wed, 10 Jan 2018 18:29:29 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward101j.mail.yandex.net (forward101j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCF9C83B53 for ; Wed, 10 Jan 2018 18:29:28 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback5o.mail.yandex.net (mxback5o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1f]) by forward101j.mail.yandex.net (Yandex) with ESMTP id BC6CD1243BFE for ; Wed, 10 Jan 2018 21:29:11 +0300 (MSK) Received: from smtp2p.mail.yandex.net (smtp2p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:7]) by mxback5o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id EeXKaBR0t4-TBQ89uIq; Wed, 10 Jan 2018 21:29:11 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1515608951; bh=JYDBg9bKVw/Q/CWhIcAEkaS/xkWBp4HNPf/tLp8PNn8=; h=To:From:Subject:Message-ID:Date; b=P/OF4pCXROBd9pAimpYv9BWa0drF9xmHMfG/jznxTQiCSR/NzvydTi/0cKq6xzt3g WTjTDkZSZ1lt9r/ws2frgnfn0GLuM9IzmaDD1py7G+jSlN31/zPZPVIVXOp9As4rje bMSJuDRxxEVK8ehnqCDkF/nvAE4Em5q7p1t951oc= Received: by smtp2p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id rvGVKXX3rN-T5LqTnCD; Wed, 10 Jan 2018 21:29:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1515608945; bh=JYDBg9bKVw/Q/CWhIcAEkaS/xkWBp4HNPf/tLp8PNn8=; h=To:From:Subject:Message-ID:Date; b=KdAuHPPtp4fk8W3E+DTKE17qQjxaXIXm0NAl/pj96tHsGMQ85Hq+/bWXvL0OB76BX M5BG4KRtS3BSXzEa+SmziRUEXd9EURJu4U3sLUaJ/SJKo1RI8s9fH8AliLQVau8dGH l0p0PtADTAacnRWHF9SdDuusu66GSH7isrlNj48Y= Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@passap.ru To: freebsd-current@FreeBSD.org From: Boris Samorodov Subject: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 Message-ID: Date: Wed, 10 Jan 2018 21:29:04 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:29:29 -0000 Hi All, I use self built base packages. Seems that I have a problem with pkg. Today I've got this: === % sudo pkg update -f Updating FreeBSD-base repository catalogue... Fetching meta.txz: 100% 268 B 0.3kB/s 00:01 Fetching packagesite.txz: 100% 29 KiB 29.4kB/s 00:01 Processing entries: 0% pkg: Newer FreeBSD version for package FreeBSD-libulog: - package: 1200055 - running kernel: 1200054 pkg: repository FreeBSD-base contains packages for wrong OS version: FreeBSD:12:amd64 Processing entries: 100% Unable to update repository FreeBSD-base [...] % uname -aKU FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan 9 14:32:13 MSK 2018 bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X amd64 1200054 1200054 % pkg -v 1.10.4 === -- WBR, bsam From owner-freebsd-current@freebsd.org Wed Jan 10 18:53:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6952BE6F11B for ; Wed, 10 Jan 2018 18:53:38 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46DB41893; Wed, 10 Jan 2018 18:53:38 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 8E9E0EC5B; Wed, 10 Jan 2018 18:53:37 +0000 (UTC) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 264AE6920E; Wed, 10 Jan 2018 19:53:37 +0100 (CET) Date: Wed, 10 Jan 2018 19:53:37 +0100 From: Baptiste Daroussin To: Boris Samorodov Cc: freebsd-current@FreeBSD.org Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 Message-ID: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dgs7megkdwczt5ov" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:53:38 -0000 --dgs7megkdwczt5ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > Hi All, >=20 > I use self built base packages. Seems that I have a problem with pkg. > Today I've got this: > =3D=3D=3D > % sudo pkg update -f > Updating FreeBSD-base repository catalogue... > Fetching meta.txz: 100% 268 B 0.3kB/s 00:01 > Fetching packagesite.txz: 100% 29 KiB 29.4kB/s 00:01 > Processing entries: 0% > pkg: Newer FreeBSD version for package FreeBSD-libulog: > - package: 1200055 > - running kernel: 1200054 > pkg: repository FreeBSD-base contains packages for wrong OS version: > FreeBSD:12:amd64 > Processing entries: 100% > Unable to update repository FreeBSD-base > [...] >=20 > % uname -aKU > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan > 9 14:32:13 MSK 2018 > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X amd64 > 1200054 1200054 >=20 > % pkg -v > 1.10.4 >=20 hum pkg now has a mechanism to protect from installing too new package (aka pac= kages built on a more recent system than the system you are running on. While this is great for ports this is a bit painful for upgrading base pack= ages when building on current One has to specify pkg -o OSVERSION=3D1200055 to allow packages built on 12= 00055 to install on 1200054. I need to figure out a mechanism to make this simpler to handle to upgrade = of base system while keeping this safety belt for users. Any idea is welcome Best regards, Bapt --dgs7megkdwczt5ov Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlpWYS4ACgkQY4mL3PG3 Plojdw//ftBLcnhvksNOdhsR5vi8o0Dg8yuLwcFzSNJVBt19FpxbiHMdNsKa2zLx a3YkYoXItg57WGhZx+BE63YCQfVCdfgUThVtOXjXI7OX9ZWXsSBs/kRtaY0do+iJ dVizofUOTSTbozQ/Cl1JmRHehUP7Yfh3hEuNkatUsnh0yWqmx2J13JbU3lCFutVb P2Aplr+ia6bH0cPF3CheMyNqtPyM206lWvAcAhrX/F/r5NNexBLsAq6oYuIeAI6h JhBGdMlF8aPdkkqVJTcFoFY4yb6M4qXKapou3fphcDNYbgKU2w1GgpE14uI53pj5 KFSAevkVkOtPVqOygnXO5qrx4DaNEvXvs0UR74MUtGCDb93J6HdgoQkEuaVzy9ac L7gixTNJi1+9gwRRZLXyR8JQctuyGWDF/K1hXCDmqZ+FPCetEIxZiUZdeRHf09jC PDWNcADn4b8yTQUn1uW8isziPWz+86EDwvOkCR2P2dsBvd56zMzntRpIOnKo8Dx4 WZQVxWvnrhyhePdy746WZblYMGIle7qL0rLzVXuKSBHf/Y7+bPGXjssYt2SWXqmm E+j60PFnex+F+hJ+ZozirXO/hkbAnwXKbw5/f2OHiTZR65yst7WzCLLy9G046Gpz DbZaOCv/tVdPV7o2f/gV0sFQ2Kqp3gB7S+WXKZwkOwX0aMkxLfU= =fivW -----END PGP SIGNATURE----- --dgs7megkdwczt5ov-- From owner-freebsd-current@freebsd.org Wed Jan 10 19:12:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4419FE7030A for ; Wed, 10 Jan 2018 19:12:34 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward102p.mail.yandex.net (forward102p.mail.yandex.net [77.88.28.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B60E229E2; Wed, 10 Jan 2018 19:12:33 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback8g.mail.yandex.net (mxback8g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:169]) by forward102p.mail.yandex.net (Yandex) with ESMTP id E91904304101; Wed, 10 Jan 2018 22:12:24 +0300 (MSK) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback8g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id VwR55WDMhk-COtaWFl6; Wed, 10 Jan 2018 22:12:24 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1515611544; bh=2hevIdAeDZxvZ2P9khYb5zCVpWEgeEANDLHx3RWZpa0=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=Cf2vOnkHzziPzdBgUY1K+v53MdE4d2wUF0LTbbEFw+FxJ/jQ5oEETl4YFANjHYimp PLg0TCHkIcDcoZBkdHuU0QneepFeYxsFp7dXJ5Xq/kgZeUgo1FIBSl2USG5GPg9Xsf HmCgRLtA82pMu4k2o+8RwXaNFq/Gcr6CevNG6u+8= Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id wIUrBTVrRK-COkCp9Pr; Wed, 10 Jan 2018 22:12:24 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1515611544; bh=2hevIdAeDZxvZ2P9khYb5zCVpWEgeEANDLHx3RWZpa0=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=Cf2vOnkHzziPzdBgUY1K+v53MdE4d2wUF0LTbbEFw+FxJ/jQ5oEETl4YFANjHYimp PLg0TCHkIcDcoZBkdHuU0QneepFeYxsFp7dXJ5Xq/kgZeUgo1FIBSl2USG5GPg9Xsf HmCgRLtA82pMu4k2o+8RwXaNFq/Gcr6CevNG6u+8= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 To: Baptiste Daroussin Cc: freebsd-current@FreeBSD.org References: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> From: Boris Samorodov Message-ID: <143e913d-c0ac-aa72-50e4-5bc48e4d9a6f@passap.ru> Date: Wed, 10 Jan 2018 22:12:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IpJlyQBEc00ADqPJglIeFTKxGgDOtTMRK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:12:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IpJlyQBEc00ADqPJglIeFTKxGgDOtTMRK Content-Type: multipart/mixed; boundary="8cP8HfgROrzTu4sIjYUsuzKJs8XGrNSMz"; protected-headers="v1" From: Boris Samorodov To: Baptiste Daroussin Cc: freebsd-current@FreeBSD.org Message-ID: <143e913d-c0ac-aa72-50e4-5bc48e4d9a6f@passap.ru> Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 References: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> In-Reply-To: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> --8cP8HfgROrzTu4sIjYUsuzKJs8XGrNSMz Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 10.01.2018 21:53, Baptiste Daroussin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: >> Hi All, >> >> I use self built base packages. Seems that I have a problem with pkg. >> Today I've got this: >> =3D=3D=3D >> % sudo pkg update -f >> Updating FreeBSD-base repository catalogue... >> Fetching meta.txz: 100% 268 B 0.3kB/s 00:01 >> Fetching packagesite.txz: 100% 29 KiB 29.4kB/s 00:01 >> Processing entries: 0% >> pkg: Newer FreeBSD version for package FreeBSD-libulog: >> - package: 1200055 >> - running kernel: 1200054 >> pkg: repository FreeBSD-base contains packages for wrong OS version: >> FreeBSD:12:amd64 >> Processing entries: 100% >> Unable to update repository FreeBSD-base >> [...] >> >> % uname -aKU >> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue J= an >> 9 14:32:13 MSK 2018 >> bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X amd64 >> 1200054 1200054 >> >> % pkg -v >> 1.10.4 >> > hum >=20 > pkg now has a mechanism to protect from installing too new package (aka= packages > built on a more recent system than the system you are running on. >=20 > While this is great for ports this is a bit painful for upgrading base = packages > when building on current >=20 > One has to specify pkg -o OSVERSION=3D1200055 to allow packages built o= n 1200055 > to install on 1200054. Baptiste, thank you for the quick response! The problem has been solved by: % sudo pkg -o OSVERSION=3D1200055 update -r FreeBSD-base > I need to figure out a mechanism to make this simpler to handle to upgr= ade of > base system while keeping this safety belt for users. Well, as for me, the above mentioned workaround is just fine. > Any idea is welcome >=20 > Best regards, > Bapt >=20 --=20 WBR, bsam --8cP8HfgROrzTu4sIjYUsuzKJs8XGrNSMz-- --IpJlyQBEc00ADqPJglIeFTKxGgDOtTMRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEiEg2cjwbwCvqC1Z0lg4gsDo/bSgFAlpWZZcACgkQlg4gsDo/ bSifjQ/7BqbHUJni/arCWBRRNaFZzMzV5FPH1uVes+S5kR0N2o4m17fe8aEdaplj hmMjiLvADyWONrL7pDiVc8A46FAoB5zSV2yP7kqISsWl7VfuLWW4jPTfu6h1SFKt eN4U5Neh1W+FGrunwjFm028S1PG9rwW9p7+XXglrnNU7oj/XkkgNU5kXsUXjvcg9 wFdogSp83saQ8qsTDp978+2DztzQk/dyawkapLDt6F3cc3qPs6izfFyHC9IHMaxe NLJeD1nW2hBChoQschACUG17amX3faWzPpN+PCf1PhOMdRCykAkY7xuia1ZjgDzU N6YkM6j9DKnu5TfL9o/q48h1KOwilhtr+0xI8SwVzhNxxoHXZbacg+d97Ts85f/V ZdxiZf2MCD6UR6IB7T+2koT0lgeGr3SeMRoAD2SPadrksaSnJM8O/fQSA/F6X+3C 5cHOGvJlt6YKVoG+FpjQ6gGIct2nQsU679sPziomDfIqlGyiGr3GnopAoO6fDufd +ILt/jISZgnXnrr9FRiuGJyWONnxiz5q/UdNiw34eHscbNyk2kh5zERZ7a8ewnKn //tBLIRubm6YbzIaFfLzRJmUb8u5IZOywC/F8fpMlLB3OjkHiaEpP2/rByiKje67 QZmbXqkdgsJNIKxfNdXkAd9f+fNYzgvdzRaBQiWUxu5ZHsuwuq8= =mMff -----END PGP SIGNATURE----- --IpJlyQBEc00ADqPJglIeFTKxGgDOtTMRK-- From owner-freebsd-current@freebsd.org Wed Jan 10 19:17:58 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 364E1E707E5 for ; Wed, 10 Jan 2018 19:17:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 924C92F2D; Wed, 10 Jan 2018 19:17:57 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.170.235]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MLB89-1eZczz1ad7-000M2l; Wed, 10 Jan 2018 20:17:54 +0100 Date: Wed, 10 Jan 2018 20:17:20 +0100 From: "O. Hartmann" To: Ed Maste Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: LLD: man pages missing? Message-ID: <20180110201747.04b13547@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/+WAF0Az7D2vPqJwED95YLC3"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:1010uXC2ANfByETOhYMvLeXfrovqaOi+vk9jn6mXVtpj0GaX/i2 Y7L/ghsq1INyS2LsvsZYpLwONKJNza1Bkc/eJdUoPYJ4F4uOF0UzSyKKLnwjU4+wkSEydP4 A0MnWDcmPUt1QaOHP1Ed2/dkD8YFb0uI8Ju9zq0MpLGWpNfUOJlEvdS6Rqe+mzU3UQaEiSe uA30fmdip+3QxXWdgbPvA== X-UI-Out-Filterresults: notjunk:1;V01:K0:wu/yl/BqkK8=:BwdCpOE0MJJGovCKLOxu2e c4NTFkafyQTShbQQHUel+wvKagGdGCfC0qqK86hFBpyCuSfFjynZuCGPxoQ+592czvxSWP1OY 0/z7wWG4TOJ2JNRfAcG4Fc8S98CwMNHl4Zq0e6BUC/fUjk1rxUWfDrC9ndE94UA0Y9MToVhJX RSryLWy2QQ7WREy7cKEMWTn4Mv+xQbhU1juo0BrCT3qzhuwW+yjrLMsHkugyjJJcm5pHNTjoi faHoy+2tkplfwR4Ab9Vf5JHSuPWMQ6xFAuVOs3985lSSrovX4rH9LtsTyV1uCmrRQBAfAy7cJ Y3iX8Uj+BqbnKzqgDTiKCeU3cKyI+pF74Is0VNd+CcZmGSORZ9dz+wrIC36eAKXfr7Tn3+Yhn H/IOCafACR5CvVvnkdZmLwjEYmtuadVoVwo9fnEf1ls+EbBAUK0rojW32JLE9GomWmqZ/v/LK o4jgIkIcX2NlAXRWMh5es3Ic6bg627mdQEjgMvrWTiUNnPJL1BA55JGewOelxr47Ghs5lNCDT ZPRAIgH60swA6Y9/XWQFRfvWl6gMWQj/8OV/NMXqAZh39nQunYKhUZA5ohQa6LZ2oUVoOr6aZ nZMU+0h/DBMBPfFrzgeCRc0syYDsx7rcZG2v8QaBpJqrlnDf1CzZWF9Hei7fm1GSwf3b5ouOk fNz6IJ7Y77ioJUmcIxlEWA82srOumRmYrFfkzdXUEXjzYYqURFQsBQBkUoO6SjGkizVUhje5I IFuiLE2mj28/JHYXDxfWAko3lOAF3XvGz2S7UrVxS1QQVBazIGcvwfYbdSsiDh8ZujYYsr1Du hIzUATlsMVy+MN7RKbtcIq8UFWQVA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:17:58 -0000 --Sig_/+WAF0Az7D2vPqJwED95YLC3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 10 Jan 2018 12:36:28 -0500 Ed Maste schrieb: > On 9 January 2018 at 20:38, Ed Maste wrote: > > > > What we have so far is in review at > > https://reviews.freebsd.org/D13813. It's still rather bare-bones, but > > I would like to commit it soon so that we have something to start > > from, and continue fleshing it out in HEAD. Review and additional > > content most welcome. =20 >=20 > I've now committed this initial version as r327770 after incorporating > feedback from bjk@. We'll iterate on expanding the documentation for > the individual options, and submit this upstream to lld soon. I'm > still very interested in additional review and content. > _______________________________________________ > 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" Thank you very much! Great work. Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/+WAF0Az7D2vPqJwED95YLC3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWlZm2wAKCRDS528fyFhY lOZfAgCoIz72nKdkRzgRC8ZHgHEDvhrIO5L18eiSEU2UlEWmgxcW59xYTt3c55jn G3+C6PjScMMuKC0nbSCuQVnHlhJzAf9SVUgpdonsKn4kZxR6pebMV/NZcV1kgPt+ Gfe33j8KEnT/odkRl9YoaynedzmJpRAqWCw+jqKFnd4YgzadrU9n =FHv1 -----END PGP SIGNATURE----- --Sig_/+WAF0Az7D2vPqJwED95YLC3-- From owner-freebsd-current@freebsd.org Wed Jan 10 21:23:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EAFBE77C88 for ; Wed, 10 Jan 2018 21:23:02 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 680AE6D753 for ; Wed, 10 Jan 2018 21:23:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1eZNpj-0003D7-Uh; Wed, 10 Jan 2018 22:22:53 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Chris H" Cc: "FreeBSD Current" Subject: Re: status-mail-rejects: appears to be broken References: Date: Wed, 10 Jan 2018 22:22:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 10fb2eeb1e6a32429c7ce102d6ec6cdf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:23:02 -0000 On Mon, 08 Jan 2018 01:52:03 +0100, Chris H wrote: > 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 Indeed. That resolves the error about 'fetch'. Which came from the ntpd leaptime file update periodic script in my case. > I'll look into it. > But FWIW I was able to get etc/periodic/security/520.pfdenied output > working > with the following diff(1): I don't use pf, so I can't comment on this. I hope somebody else can, but I guess it will attract more eyes if you repost with a subject about 520.pfdenied or something similar. Regards, Ronald. > --- /etc/periodic/security/520.pfdenied.orig 2017-11-21 > 06:57:04.000000000 -0800 > +++ /etc/periodic/security/520.pfdenied 2017-03-29 16:22:50.000000000 > -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 > From owner-freebsd-current@freebsd.org Thu Jan 11 14:13:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1517E650A2 for ; Thu, 11 Jan 2018 14:13:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4454072BAB; Thu, 11 Jan 2018 14:13:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w0BEDdOU018961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jan 2018 14:13:40 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90] claimed to be [192.168.1.65] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 From: David Chisnall In-Reply-To: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> Date: Thu, 11 Jan 2018 14:13:34 +0000 Cc: Boris Samorodov , freebsd-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C046B68-0F45-432C-96A9-4A4B2AEAED24@FreeBSD.org> References: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:13:49 -0000 On 10 Jan 2018, at 18:53, Baptiste Daroussin wrote: >=20 > I need to figure out a mechanism to make this simpler to handle to = upgrade of > base system while keeping this safety belt for users. >=20 > Any idea is welcome I believe the apt approach to this is to have a different verb = (distupgrade vs upgrade) to perform complete version upgrades. Ideally, = the proper fix would probably be to depend on a base package version, = rather than OSVERSION, and if the base packages are not being used to = synthesise a phantom set of base package metadata based on OSVERSION. David From owner-freebsd-current@freebsd.org Thu Jan 11 15:57:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDA3BE6B5C3 for ; Thu, 11 Jan 2018 15:57:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0557777AD for ; Thu, 11 Jan 2018 15:57:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0db97ede-f6e8-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 0db97ede-f6e8-11e7-93a5-cd02e7dc7692; Thu, 11 Jan 2018 15:56:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w0BFvYBT003779; Thu, 11 Jan 2018 08:57:34 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515686254.44630.74.camel@freebsd.org> Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 From: Ian Lepore To: Baptiste Daroussin , Boris Samorodov Cc: freebsd-current@FreeBSD.org Date: Thu, 11 Jan 2018 08:57:34 -0700 In-Reply-To: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> References: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 15:57:43 -0000 On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > > > Hi All, > > > > I use self built base packages. Seems that I have a problem with pkg. > > Today I've got this: > > === > > % sudo pkg update -f > > Updating FreeBSD-base repository catalogue... > > Fetching meta.txz: 100%    268 B   0.3kB/s    00:01 > > Fetching packagesite.txz: 100%   29 KiB  29.4kB/s    00:01 > > Processing entries:   0% > > pkg: Newer FreeBSD version for package FreeBSD-libulog: > > - package: 1200055 > > - running kernel: 1200054 > > pkg: repository FreeBSD-base contains packages for wrong OS version: > > FreeBSD:12:amd64 > > Processing entries: 100% > > Unable to update repository FreeBSD-base > > [...] > > > > % uname -aKU > > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan > >  9 14:32:13 MSK 2018 > > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64 > > 1200054 1200054 > > > > % pkg -v > > 1.10.4 > > > hum > > pkg now has a mechanism to protect from installing too new package (aka packages > built on a more recent system than the system you are running on. > > While this is great for ports this is a bit painful for upgrading base packages > when building on current > > One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055 > to install on 1200054. > > I need to figure out a mechanism to make this simpler to handle to upgrade of > base system while keeping this safety belt for users. > > Any idea is welcome > > Best regards, > Bapt Is this new mechanism disabled if installing into something other than the live system, such as when using -c or -r (and maybe -j)? -- Ian From owner-freebsd-current@freebsd.org Thu Jan 11 16:49:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6BBDE6E5ED for ; Thu, 11 Jan 2018 16:49:36 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6728079B02; Thu, 11 Jan 2018 16:49:36 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id B234B5A0A; Thu, 11 Jan 2018 16:49:35 +0000 (UTC) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 5EC95698D3; Thu, 11 Jan 2018 17:49:35 +0100 (CET) Date: Thu, 11 Jan 2018 17:49:35 +0100 From: Baptiste Daroussin To: Ian Lepore Cc: Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64 Message-ID: <20180111164934.eqopinjs6tu3i3jn@ivaldir.net> References: <20180110185336.nlwkwhxu574kybvi@ivaldir.net> <1515686254.44630.74.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zglmaeiaz3gz6xim" Content-Disposition: inline In-Reply-To: <1515686254.44630.74.camel@freebsd.org> User-Agent: NeoMutt/20171215 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 16:49:36 -0000 --zglmaeiaz3gz6xim Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2018 at 08:57:34AM -0700, Ian Lepore wrote: > On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote: > > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote: > > >=20 > > > Hi All, > > >=20 > > > I use self built base packages. Seems that I have a problem with pkg. > > > Today I've got this: > > > =3D=3D=3D > > > % sudo pkg update -f > > > Updating FreeBSD-base repository catalogue... > > > Fetching meta.txz: 100%=A0=A0=A0=A0268 B=A0=A0=A00.3kB/s=A0=A0=A0=A00= 0:01 > > > Fetching packagesite.txz: 100%=A0=A0=A029 KiB=A0=A029.4kB/s=A0=A0=A0= =A000:01 > > > Processing entries:=A0=A0=A00% > > > pkg: Newer FreeBSD version for package FreeBSD-libulog: > > > - package: 1200055 > > > - running kernel: 1200054 > > > pkg: repository FreeBSD-base contains packages for wrong OS version: > > > FreeBSD:12:amd64 > > > Processing entries: 100% > > > Unable to update repository FreeBSD-base > > > [...] > > >=20 > > > % uname -aKU > > > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue = Jan > > > =A09 14:32:13 MSK 2018 > > > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X=A0=A0amd64 > > > 1200054 1200054 > > >=20 > > > % pkg -v > > > 1.10.4 > > >=20 > > hum > >=20 > > pkg now has a mechanism to protect from installing too new package (aka= packages > > built on a more recent system than the system you are running on. > >=20 > > While this is great for ports this is a bit painful for upgrading base = packages > > when building on current > >=20 > > One has to specify pkg -o OSVERSION=3D1200055 to allow packages built o= n 1200055 > > to install on 1200054. > >=20 > > I need to figure out a mechanism to make this simpler to handle to upgr= ade of > > base system while keeping this safety belt for users. > >=20 > > Any idea is welcome > >=20 > > Best regards, > > Bapt >=20 > Is this new mechanism disabled if installing into something other than > the live system, such as when using -c or -r (and maybe -j)? >=20 The new mechanism grab the information from the files in the userland, mean= ing, -c, -r and -j will discover the OSVERSION of the target binaries Bapt --zglmaeiaz3gz6xim Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlpXlZwACgkQY4mL3PG3 Plr6TA//f0FrObHDOUTB87pM74sKhlpxj3/HO0a/PCVPRQ3h2qouoFOYK6evcAf5 mHu2LxvNzYmVxV2yRJUr4ottl2QfvazuOdNoSyG2lxE5CAxF9+eVOEuKgQZQuzFG uMMB+rtfxE2FxbREwGgamWbrQUnnhJwaygOmQNRv4G479xwBQ/JGdgaSheARwI1h G9XC2DbImbJ16kFkkejnrCqFR2JNfGh1rE0tTA7XfY+B8S6hnHCNhZ6n+BA9JOvb TglpuFSK70dWvhrQGmRb9FUqCoLvNIvVw0pxDrBD2WxRv7Qt4TKmp5Um0+A7ezVh f35GRWpaktpE23MSXPBvz1tJSqF8VWsUR7ZGuc7qgqKlYD9ngLv/9GP7vWmeoGIH pKrCRfM/SvMFiaBQ6vPktSTa+vflA9zRKgj9aG84hqJC9ld3kf4Ry9ir1cWSKYC6 izP9qg5xoG5XhZ7stQATarQZK+IlqMr3731kfMac5/E/pvIAu4hLbLYD960MVtbA t7+L2Ap72PStC1jmia8YMkVmY8rsjVovWvRlAiFt/9xojzIE3RYq4S6j4UoGu8mO uaJ5tlT+sA9l4ixF6JEwoy1+SL/NhyrVm///4iyF0u/YeKgBlR2Wi6uzhCiOpNBI SqYj/t6pzaefWkj/3E8PAzH9wlduGHnSGehQVBlV6Rkk3FGrpgk= =I/Qj -----END PGP SIGNATURE----- --zglmaeiaz3gz6xim-- From owner-freebsd-current@freebsd.org Thu Jan 11 23:03:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E7DEA56A5 for ; Thu, 11 Jan 2018 23:03:21 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C53F6A41B for ; Thu, 11 Jan 2018 23:03:20 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-236-88.albq.qwest.net [67.0.236.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id B9D641928F3 for ; Thu, 11 Jan 2018 14:58:31 +0000 (UTC) To: freebsd-current From: Sean Bruno Subject: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 Message-ID: Date: Thu, 11 Jan 2018 16:03:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vib3sARdyoT3wfBnlCBcIBAtZK2wgZDRx" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 23:03:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vib3sARdyoT3wfBnlCBcIBAtZK2wgZDRx Content-Type: multipart/mixed; boundary="7hie8Q5FsS2dV1p6iOE4OHydG6MNR9efo"; protected-headers="v1" From: Sean Bruno To: freebsd-current Message-ID: Subject: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 --7hie8Q5FsS2dV1p6iOE4OHydG6MNR9efo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable https://reviews.freebsd.org/D13832 <--- test this update I'd like to get some feedback from AMD cpu users on this update. I've restructured and undone a few things that may have been keeping folks using this port from getting their runtime cpu microcode updates. After installing the port, grab your microcode version via sysutils/x86info. If you don't see an update, that only means there is no update available for your system. x86info -a | grep Microcode Run the microcode_update and repeat. Check /var/log/messages for a notification that the code was updated. You should be able to get something like the following for your system if it executed an update: root@lab:/home/sbruno # x86info -a | grep "CPU Model" CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) root@lab:/home/sbruno # x86info -a | grep Microcode Microcode patch level: 0x6000629 root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@lab:/home/sbruno # x86info -a | grep Microcode Microcode patch level: 0x600063d root@lab:/home/sbruno # grep microcode_update /var/log/messages Jan 10 16:52:26 lab microcode_update: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu /dev/cpuctl0 to revision 0x600063d... done. --7hie8Q5FsS2dV1p6iOE4OHydG6MNR9efo-- --Vib3sARdyoT3wfBnlCBcIBAtZK2wgZDRx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlpX7TNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /Lag4wf/UVS5uo9ziMc2pgj2pT9G54uHIdzoKFYTXWEGnTOTDKEY0KzbMWdX22nl BmYK1sTgfkQiKGrSLQ0NqwsEFQEbeFlJLNrnDB9shKmxJ540n4jDn5OhejsijRyO 30Ck/B19zuGKBebYsO/XjFckkIuJfzzSKMJS653euLagW+H7tjhe9JH2K2+RtQ+k QsfqoO09Z3gxMeblFu7KUlS9Zot8U28fPWBoZZm6SxTkHQbY2QFhtmaNMPCIDnud x3fv/pkTIi17JFaJqfw+7CgSMiYuXx2CMNsDyLlVicSrSNFCnZByqbEC0ldMj4ks MHjzkxV3cZ+aPmVCR0stYSk9b/Z86g== =LAIb -----END PGP SIGNATURE----- --Vib3sARdyoT3wfBnlCBcIBAtZK2wgZDRx-- From owner-freebsd-current@freebsd.org Fri Jan 12 04:53:17 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4C06E70F14; Fri, 12 Jan 2018 04:53:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD3176B63; Fri, 12 Jan 2018 04:53:16 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-fc5ff700000030c7-1d-5a583e034520 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.5E.12487.40E385A5; Thu, 11 Jan 2018 23:48:04 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w0C4m2hh024784; Thu, 11 Jan 2018 23:48:02 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0C4lxDY024134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 23:48:01 -0500 Date: Thu, 11 Jan 2018 22:47:59 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: FINAL CALL for 2017Q4 quarterly status reports Message-ID: <20180112044759.GT72574@kduck.kaduk.org> References: <20171226002716.GG59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20171226002716.GG59505@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixCmqrctiFxFlcG67ssWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6Ma0dWsRQcFK7o625mbGD8JNDFyMkhIWAiMbP3G2sX IxeHkMBiJom9p56wQDgbGSWeL9nGDuFcZZLo/3CbFaSFRUBVoun3NEYQm01ATWL9imvMILaI gLzEvqb37CA2M5D9a2sTmC0sYC5x+3MPE4jNC7TuVcNUMFsIyF5yag0jRFxQ4uRMkM0cQL1l Ev9fhUCY0hLL/3GAVHAKmEo82riXDcQWFVCW2Nt3iH0Co8AsJM2zEJpnITTPAjtHS+LGv5dM GMK2EuvWvWdZwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyi82V2UdjBO /Od1iFGAg1GJh/dBbniUEGtiWXFl7iFGSQ4mJVHePelAIb6k/JTKjMTijPii0pzU4kOMKkC7 Hm1YfYFRiiUvPy9VSYS3phuojjclsbIqtSgfpkyag0VJnNfDRDtKSCA9sSQ1OzW1ILUIJivD waEkwetqExElJFiUmp5akZaZU4KQZuLgPMQowcEDNPyqNVANb3FBYm5xZjpE/hSjLseNF6/b mIXALpAS5y0DGSQAUpRRmgc3B5SuJLL317xiFAd6UZhXH2QUDzDVwU16BbSECWjJ+Y2hIEtK EhFSUg2MC7NubPxdofe1P+xbepAYT1t7gPL1OjahoPnpxzNjn1ZXiG8yEjl40Pno9Mi2aL3b p49NkOn5ETyHv1kv8cHblBkMuzN4l7Bbsl2fck5nuekORfuM6GfyDg+K2QyviRzwynW97tXz tWaF7eXQUz8cd3kxiq7bJ2ATtePL3kMHeFqufpffa+euxFKckWioxVxUnAgAM1xHuTIDAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 04:53:17 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, This is the last call for submissions for the 2017Q4 FreeBSD Quarterly Status Update. The deadline for submissions is January 14, 2018, for work done in October through December. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpYPfkACgkQKNmm82Tr dRJNTAwfU7M53e5Zdq1cg4FP3MZKi0dFyx7n12HxGuSk4ID9/J5UbVx1tVkTLFKk 58ewVKXLe6u2uo+dZ0IdUI2L4CY/V+/g6R1SQzSShjkaM5KU+GK/WIK6g2n0oTZt 5DtSAyiSM+w6FRl4b+UU+jbHaPusDNCoZEw3Oa4OxVZCMCXXtoaf/smyckErEyTj XMu2bfapXycqaijWH0lDfF/+nbsUkrffDt36cUBpcd3Ehok67oZe4qABCnd99b1X 0eAgS4HqwNk/ShtSrg5JJDPIBc2xBB/+W12MS2gBcpA883JB7wFixruH/hktRM8Z 6sx1d25fj2Fkza22SaOftcr9cGTECoKAsqkjX4yD+FTjm/rCra1MG3ELmA0zpRhp kVCRRuKbvjcvvdInYeeJRfjA1tmpGFVVAZWImxX1tsYk+yd1Hf1JSONDC1P3a4HN P1YHvos7PsR6mR1EYHeUntMi0vpFgwYJx4GqyeJwmWhHJ0Jfzuf5U17dG9n2oLhJ v/xWhtG5tJdnUw== =myiJ -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@freebsd.org Fri Jan 12 06:12:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DEFDE74EF7 for ; Fri, 12 Jan 2018 06:12:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-137.reflexion.net [208.70.210.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3DC67920E for ; Fri, 12 Jan 2018 06:12:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5441 invoked from network); 12 Jan 2018 05:12:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Jan 2018 05:12:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Fri, 12 Jan 2018 00:12:00 -0500 (EST) Received: (qmail 28968 invoked from network); 12 Jan 2018 05:12:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jan 2018 05:12:00 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D615DEC9459; Thu, 11 Jan 2018 21:11:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Intel CPU design flaw - FreeBSD affected? [AMD family Zen/17h status] From: Mark Millard In-Reply-To: Date: Thu, 11 Jan 2018 21:11:59 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <05382876-0605-424D-9BDD-CE1BF6C744CF@dsl-only.net> To: freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 06:12:08 -0000 On 2018-Jan-6, at 2:02 PM, Mark Millard wrote: > On 2018-Jan-4, at 7:32 PM, Mark Millard = wrote: >=20 >> Darren Reed darrenr at freebsd.org wrote on >> Thu Jan 4 11:56:29 UTC 2018 : >>=20 >>> Most people are only talking about meltdown which doesn't hit AMD. >>> spectre impacts *both* Intel and AMD. >>>=20 >>> SuSE are making available a microcode patch for AMD 17h processors = that >>> disables branch prediction: >>>=20 >>>=20 >>> = https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.htm= l >>=20 >> https://www.amd.com/en/corporate/speculative-execution >>=20 >> reports. . . >>=20 >> For the Bounds Check Bypass Spectre variant (#1): >>=20 >> Resolved by software / OS updates to be made available >> by system vendors and manufacturers. Negligible performance >> impact expected. >>=20 >> For the Branch Target Injection Spectre variant (#2): >>=20 >> Differences in AMD architecture mean there is a near zero >> risk of exploitation of this variant. Vulnerability to >> Variant 2 has not been demonstrated on AMD processors to >> date. >>=20 >> For the Rogue Data Cache Load Meltdown variant (#3): >>=20 >> Zero AMD vulnerability due to AMD architecture differences. >>=20 >>=20 >>=20 >> How long #2 will have a "has not been demonstrated" status >> is yet to be seen. >=20 > = https://www.phoronix.com/scan.php?page=3Dnews_item&px=3DAMD-Branch-Predict= ion-Still >=20 > reports that SUSE's microcode update for AMD's Zen/17h does > not disable branch prediction, despite SUSE's existing > description: >=20 > QUOTE > I reached out to AMD and on Friday heard back. They wrote in an email > to Phoronix that this Zen/17h microcode update does not disable branch > prediction. They'll be working with SUSE to re-clarify this microcode > update description... But as far as what this microcode update does in > the wake of SPECTRE they have yet to clarify or why this microcode > binary has yet to make it to other Linux distributions. If/when I hear > anything more, I'll certainly post about it but doesn't appear to be > anything as dramatic as disabling branch prediction, which could have > slaughtered their CPU performance. > END QUOTE https://www.amd.com/en/corporate/speculative-execution has been updated and amd no longer claims that #2 has not been demonstrated. They state there will be microcode updates for it: QUOTE AMD will make optional microcode updates available to our customers and = partners for Ryzen and EPYC processors starting this week. We expect to make = updates available for our previous generation products over the coming weeks. END QUOTE =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Jan 12 07:26:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11C31E77FE7 for ; Fri, 12 Jan 2018 07:26:14 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 753767B92F for ; Fri, 12 Jan 2018 07:26:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MC4VE-1eifAS490S-008nhG for ; Fri, 12 Jan 2018 08:26:05 +0100 Date: Fri, 12 Jan 2018 08:25:58 +0100 From: "O. Hartmann" To: freebsd-current Subject: /usr/bin/ld: error: cannot open crt1.o: No such file or directory Message-ID: <20180112082558.303d5936@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QXCwpFCiY9o8TwFHJ0eF2n4Bpgj/nXtv7Zs5smMMA5dy0zRmvYp yM4+cojLoCk69BcoMyen7Ayld/T2a8NK45w3cvTxRTGWoDJirE/6x8cz2+T00P9PYQhbVEx /4MmNgpelpjLgWXVo9IJ7jvMNKhKUiTADEI8N1uNBCTX5GgIuNB6n9YAGVQGtCM3WaOi8pm kRTwmi51e5Mm6MzAUCpTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:gTPHN7Tzaqw=:BmLZOAvZ2msbHI9RnGlJQD gVA8DeL8CYfvERJfWPnWJzaOecFxLlcxeC7LfXmZI9xik/T9RGym7u/hVn4bLsL7Lj70stEJn wX5mZB8VSCcQIitWiT2PzniGmDD/MiI/Cb1p8s9FJo9scTl2LzzKVWR9Zh32czR5T+QejxORC TAb7qDgIvVlGzCMQ39kPf5cueLlb+gyUHPMRvHN7DZgwVKZXW02puR7iU1gbhebugsjFujwXm F44Jh6rbQzlMoFVxmEl42Q0EYvQbZlQfihhuK7wjr4rqlwd+4HzGkCu+ybfQmW8phMr0HYn6t qyJALLXJU8xjQjsd0b3kyk4XuranV1W1eU7o1XcnG3oukD2VVnRt0Ol/Qgn1KCOWdfscUyJbZ KdYDMSrRZ5L3XTOWogC9ZenbYbx8EkHDJ0Oxooyss6WBap4vByCdJWrZzdGcuEQlH1/prB9vo BvUmE97OLkmbbghPJOwtqEklEuDbv+3essFdnEw1ivTA7IQT4oYcBtcMlsxMym0ddlO9T81CP Yi/jXzt9jLYaaebkni7L3jlP2YZ8KSwFLM8cQ2GYGj/Y8k27zajQgrvPqyGk+eTfd+1ekvL1u 1RRZJBQoQ6f1esRGdYbA+F4GvCmaq1iEZiRmEYhrzheB56bBMRx1ikbW4OhnPthS/NeQt0GLQ oYtAuFtf7s4k5CaUiOtvVNnlTeQW7rb9U9Ko1JYkYGGe7dBX4c5M3lj5aDN0aWuChBp9c++7u WycHU+7UMSK1zNNo0a4BaBVtBzPvt7POGRcN5qatfrzXF9V7+8uBtoh193WJWLz/SNPMaqz1f Z+dq28CYCKNb2PSybzdugE3k7L3EyosjsMLPWwI/ngeomIEPqs= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 07:26:14 -0000 When building just checked out sources of Revision: 327866 and try to buildworld with WITH_LLD_IS_LD and/(or not) set WITH_LLD_BOOTSTRAP AND with make -j X, X>1, the build process fails on several CURRENT systems right now with musterious errors regarding crt1.o missing or not linkable: [...] /usr/bin/ld: error: cannot open crt1.o: No such file or directory --- _bootstrap-tools-usr.bin/fortune/strfile --- cc: error: linker command failed with exit code 1 (use -v to see invocation) I tried to compile with "make buildworld" (not parallel builds) and it seems, that the buildworld process is proceeding. Kind regards, oh From owner-freebsd-current@freebsd.org Fri Jan 12 11:49:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61ACFEB2347 for ; Fri, 12 Jan 2018 11:49:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25EF91ABE; Fri, 12 Jan 2018 11:49:32 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a01.um.gwdg.de ([134.76.11.221] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1eZxps-0000Eh-Am; Fri, 12 Jan 2018 12:49:24 +0100 Received: from UM-EXCHT-A02.um.gwdg.de (134.76.9.211) by um-excht-a01.um.gwdg.de (134.76.9.210) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 12 Jan 2018 12:49:24 +0100 Received: from krabat.raven.hur (91.8.148.12) by email.gwdg.de (134.76.9.211) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 12 Jan 2018 12:49:23 +0100 Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 To: Sean Bruno , freebsd-current References: From: Rainer Hurling Message-ID: Date: Fri, 12 Jan 2018 12:49:15 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 11:49:33 -0000 Am 12.01.2018 um 00:03 schrieb Sean Bruno: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. > > After installing the port, grab your microcode version via > sysutils/x86info. If you don't see an update, that only means there is > no update available for your system. > > x86info -a | grep Microcode > > Run the microcode_update and repeat. Check /var/log/messages for a > notification that the code was updated. You should be able to get > something like the following for your system if it executed an update: > > root@lab:/home/sbruno # x86info -a | grep "CPU Model" > CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) > > root@lab:/home/sbruno # x86info -a | grep Microcode > Microcode patch level: 0x6000629 > > root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Done. > > root@lab:/home/sbruno # x86info -a | grep Microcode > Microcode patch level: 0x600063d > > root@lab:/home/sbruno # grep microcode_update /var/log/messages > Jan 10 16:52:26 lab microcode_update: > /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu > /dev/cpuctl0 to revision 0x600063d... done. > Just for the record, for an older Phenom with dmesg: CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x100fa0 Family=0x10 Model=0xa Stepping=0 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff SVM: NP,NRIP,NAsids=64 TSC: P-state invariant, performance statistics #x86info -a | grep "CPU Model" CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion (II)/Opteron (PH-E0) #x86info -a | grep Microcode Microcode patch level: 0x10000bf #/usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. #x86info -a | grep Microcode Microcode patch level: 0x10000bf #grep microcode_update /var/log/messages --- So no recent update and no log messages, as expected ;) Regards, Rainer Hurling From owner-freebsd-current@freebsd.org Fri Jan 12 10:57:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B54E5EA5818; Fri, 12 Jan 2018 10:57:03 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33AE0833BB; Fri, 12 Jan 2018 10:57:02 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MDi9C-1edp9c37c6-00H7VO; Fri, 12 Jan 2018 11:56:54 +0100 Date: Fri, 12 Jan 2018 11:56:47 +0100 From: "O. Hartmann" To: "Andrey V. Elsukov" Cc: "O. Hartmann" , freebsd-current , freebsd-ipfw@freebsd.org Subject: Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces Message-ID: <20180112115639.3b31073f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <5e6811ff-70c6-ee74-bf04-1319e9002b29@yandex.ru> References: <20180109102813.63c32899@freyja.zeit4.iv.bundesimmobilien.de> <5e6811ff-70c6-ee74-bf04-1319e9002b29@yandex.ru> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W8zl6w7tYnxY56sOD8F03wCMIVIARrj/haujKWZ1epwEaiV/SWI dN3aM9zgg/EFHmxyBBfSfu2HukF/zOueMHL0iyuX/9IaUoGKcXedqqojfQ9FzKVu8Pkevma YwUaV4+UDS+NdFFyx53fovZp0t2UFsP3dksykar2ZPM6pT4eE5FqfjodEI+oFT7CsYvALiK gGzj8Bb8cGPJZXh+Yj8Lg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yONudj0npJU=:C3bMwQNqWvJRlDZmhCl+hy C2Gum8egytHHsRp1oHPUrMGT/TmqW8gHjoRbTaIgv/D7xjj9cnu3dWPHEhjTLbTO2Rvmkz8jx j3PzMQr3BXGlvormlDnWkrvK8ZppT+O3HSnjCUVnZDEhtYUeI4MF4UUGvnqK4MyvEAUyQJx10 eDZS5/jXWA8ZuBQ3f0lql7nNxkucFgTeByLB5Rcomz2M5YHWYGnUhXhwbBXxoxs/8BhOfoIrZ wpDFB4EAWyjm8poFmYHk/OrhebGtoQoa/6YQl9cKwZJeqo3CYaGmbFw+neKfXNPv8oXYrrbpq vp7Fg0tSldwpIy24q+Mx8d600i3aDPg4Unp7OZSI5r2ROd13oZuNvVVzl8lwjsbAtR5wfsicd 166PqIIsvSQ4moDXHgmrhfOiH61DX3Vsp0JxCTQlfMBRCMzqtZdiDM5cvgdy0+gKtIiuRrue8 4nQNYZeKsJr3njyoyrvu5wyx7+NRI8y2Hg6IcLke890puf9bH53HLwdJwe2+nKUYBOtUH/25f 48ozZWnVWlITGpnTI6PE/5780/K0KsWKJ1vge8Cdmclq2zcD40CfOZgLaOGdNE9K1kWWHQAne yPakTauVX0r5i1eO60G51Y/A4YzJqDeB6Uzya/w0cmxFOyELcjuefkfqlm8+JPqJ75hO3D41+ 3O3KfT/K74YTSTKdrySu8tzAFcf3nf9gP/Ysn3H+xtVeYPT1MzU2XqsYQ3sXERLAJgJJm7qMA DwBNZkOVu8ahUDTv8kSNqNFGSkjYu3U5GBxKP7gMS14rieT5p5+jJ2cBtwyPdnWm6rkw+MxXq TyxEv3N9qqc2Jh6g2wqmNmZls9mh/nIoWDagefw+9Y4nNbeGBY= X-Mailman-Approved-At: Fri, 12 Jan 2018 12:02:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 10:57:03 -0000 On Tue, 9 Jan 2018 21:23:54 +0300 "Andrey V. Elsukov" wrote: > On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get > > especially confused by the subsequent blocks of text following the line I > > mentioned above. Since not everybody using FreeBSD is capable of studying > > the kernel sources, I have difficulties to put those statements in line > > with a visualization of the packet flow. A local host receiving a packets > > destined for the local host can not have xmit interface? If I imagine, that > > the recv interface might be the interface adjacent directly to the in/out > > port depicted in section PACKET FLOW it doesn't give me any idea why there > > is no xmit interface. > > When your system has two interfaces ed0 and ed1, and it acts as router, > a forwarded packet can be checked by firewall two times: > > 1. When a packet is received on ed0 interface, mbuf associated with this > packet gets a property "receiving interface". This packet is checked for > inbound direction and can be matched by "in" and "recv ed0" opcodes. > If it was not dropped by rules, it will go through IP stack and can be > forwarded according to routing table via interface ed1. > > 2. When the routing decision was made (i.e. outbound interface is > determined) a packet checked by firewall again, now for outbound > direction. And it can be matched by "out" and "xmit ed1" opcodes. The > opcode "recv ed0" still can be matched too, but "in" opcode will not > matched. > > A packet destined for local host is consumed by local IP stack and will > not forwarded. It is checked by firewall only one time (usually). Thus > it can not have xmit interface. > Thanks very much for the explanation. From owner-freebsd-current@freebsd.org Fri Jan 12 15:28:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F16AE6AF0A for ; Fri, 12 Jan 2018 15:28:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14CAB6F9FC; Fri, 12 Jan 2018 15:28:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x234.google.com with SMTP id 25so6207395ioj.9; Fri, 12 Jan 2018 07:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Pfp5oE/2j97HXFqopWpiRqfwFUJg3eIG+WGjwrgHvTE=; b=TptnImGZzJ4YxEWpR6YXqR4O5r7ikQscc+MvsYdqoDbtctl1b7VDFSf2E6oxXs3QIx ljtkabmXWX/ntTkwBqwKcyYs/T0IKY/2SY+OLEGtnALxVeGVs+a4VPkqEbz0IN7E419j RiAa+A4ps+jBVg8wvmvVT3nXIc0MH/4+wM0y+dBugJUeHYC2AbY0Zv64Rh9iWN0jBAhW aM6oSiQq53uKbrxnqFBSgpi9VrVN8zBPKCPqqe63QkHyEQs6E1Bt8yZe9cu+ordl5cXF LLQHneDSDuvR64NCS6jUfa2Y8isIxjc4zd/2+1JK15Tx1sJrmPQpZHS0w4ejKCkFeiSJ FzQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Pfp5oE/2j97HXFqopWpiRqfwFUJg3eIG+WGjwrgHvTE=; b=FAigL+ms1QBcHM6mS3SJq08hsQx2B2jF8WE9DaqH/EbxLK69SXARA77CCEB4R6AAf4 VsLsaX+Jlvu7X9VZbZKwhix/Z1VKhxTKgBc6aM5T5qnjeFYeulQz4zSKYczYORd207as fwcXp6UH00SvBcmfYvmkQZ9/VTnH7JrwXF2ChlXpipbz0vJYEBHk/UBshWQtVvYeiC+K CRt1bliyujDfF72UTIIzjmDJdHhIRvi07kEwhfE1IR8/dYcEhUbCauRwNyYZuwrSJveC gmM+IYLZl9CYZY0deLPXL/9e71rG702bf450h05dolaJX4yu67vZgTJ0rjHQeHkouqbh wjxA== X-Gm-Message-State: AKwxytcFTOZzJWcglthp85V9rn7om0pZ99qAPPgB1jNJAfwwyp9x7hiq SxcjXvz4teHHH6OAF9ilf4pxUieVDG/8ZsVSnjiivA== X-Google-Smtp-Source: ACJfBotT3/uMk2JiZhtwWyFBupwYmxFrGt5i13e6SKScPKt0khiFS6PrEx9TWP6ayzogYvN2uhBuc9rxdn8AbA7f4HM= X-Received: by 10.107.169.94 with SMTP id s91mr1552533ioe.83.1515770922931; Fri, 12 Jan 2018 07:28:42 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.163 with HTTP; Fri, 12 Jan 2018 07:28:22 -0800 (PST) In-Reply-To: <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> From: Ed Maste Date: Fri, 12 Jan 2018 10:28:22 -0500 X-Google-Sender-Auth: 4kb4aXmgUe0Bz1x9Qva1rSeiZE8 Message-ID: Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> To: Michael Tuexen Cc: Warner Losh , "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:28:44 -0000 On 4 January 2018 at 03:10, Michael Tuexen wrote: > > 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. Both of my new co-op students have encountered this as well: after a panic (unrelated to the filesystem), SU+J fsck recovery runs at boot, and than many cylinder checksum warnings are emitted by the kernel. The students used the default installer configuration; it sounds like we should disable SU+J by default in the installer until this issue is addressed. From owner-freebsd-current@freebsd.org Fri Jan 12 15:38:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6391E6BB88 for ; Fri, 12 Jan 2018 15:38:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE9E705AF; Fri, 12 Jan 2018 15:38:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0CFcJGD089544 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Jan 2018 10:38:19 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0CFcHMd083804; Fri, 12 Jan 2018 10:38:17 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 To: Sean Bruno , freebsd-current References: From: Mike Tancsa Organization: Sentex Communications Message-ID: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> Date: Fri, 12 Jan 2018 10:38:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:38:20 -0000 On 1/11/2018 6:03 PM, Sean Bruno wrote: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. Hi, I am trying out on RELENG_11 on a Ryzen CPU Without kib's commits at https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/005320.html I get root@testamd:/usr/ports/sysutils/devcpu-data # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Re-evalutation of CPU flags Failed. root@testamd:/usr/ports/sysutils/devcpu-data # with r327597, root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@testamd:/home/mdtancsa # running x86info -a also generates this error / warning ? CPU0: local APIC error 0x80 root@testamd:/home/mdtancsa # x86info -a | grep -i microco Microcode patch level: 0x8001129 root@testamd:/home/mdtancsa # x86info -a | head -20 x86info v1.31pre Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 root@testamd:/home/mdtancsa # Also your diff is based on a previous version of the port. There was an update since, with new microcode from Intel that gets clobbered in your diffs. Thanks! ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@freebsd.org Fri Jan 12 15:51:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65367E6C7EF for ; Fri, 12 Jan 2018 15:51:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2698570FB9 for ; Fri, 12 Jan 2018 15:51:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id r6so9752194itr.3 for ; Fri, 12 Jan 2018 07:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0REWBF+Z011eOGlV3qj+bWC2zwvsDhghra/98PqUDX0=; b=LW14DeUeC9WeRv6YUXngcp0R52ziDJKDx7ZcneTYzd1ine6zY3Pk0ZyprqXbFBhc+w JU0MpP5c50fNHYTCkDHjqWnZnHkibS/r/efdBf/OIo0cW4zaPQIOuKDA0Z9OzfCWS/mK o7Faj2ZSAtiV4rjbH+1oNrCfvnxGEtusipO8hXEcQAuaF33Zx3cZbcED+o0ksmJqB9wJ tOkZECHSY1XJ6UtRcKbVbxe44UGX3FlTR002hUFeB7pE5a03WgZaw/dgvLLVPVgGqKB5 hJZcoX0342YcVnYtdqtwnxSGdRF8NBud6PkpHzuTaJbtzCCt5NNTcWj4zrWdp+Eh4TP+ BNcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0REWBF+Z011eOGlV3qj+bWC2zwvsDhghra/98PqUDX0=; b=LJxskPnkLpSJ2FU7hPe/6BEC5A5s0yCCrzk0U4bSn7NB8kTHJqofDreqiLj0eSqYB+ qjwpAKisQyYTkWYufkNQGk8ic30Z/Y1utj08eM0SS+IWMqjWFZTU/3ECCq+mUJzVXfWN m7inNppeiMRqq1xY6j0xBMJekHz2b4rGB+VKto9JKQLPPdpSN8h3FibW+PEZ92b91vtH x6PW682Hf09mo5Rd9Pm9uPFGoZIFU7AH6ExKMKlKMZOu2e8Ph8U9Dw91tGW0+QOyTDlA q9+63ODGfUm2UieDeBrYOoMNR6T7SfJ9Hmq38nkE5NS04L6gtH8UMmb/24cHoi2sJKTy LUNw== X-Gm-Message-State: AKwxyteNnITwPhHZQ0NpASORzsKUcsBl/zoZdkSalR7waQ5PnC4jldLz DQ8fcfjH68PFXbm0FxjuKojMtUG+llkoNsUfniKGBA== X-Google-Smtp-Source: ACJfBovjNK1pfLfUz77+zgKDObhRU7xJqA5/f7VpishvskVoDnRpjJ59u1Fq4TA9/AL3R2trNt+q+1jTqPnPdchBgSM= X-Received: by 10.36.91.210 with SMTP id g201mr5487771itb.50.1515772292486; Fri, 12 Jan 2018 07:51:32 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.199.131 with HTTP; Fri, 12 Jan 2018 07:51:31 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> From: Warner Losh Date: Fri, 12 Jan 2018 08:51:31 -0700 X-Google-Sender-Auth: uw1z1NpluX7sujVUEMD-uXGpYI8 Message-ID: Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> To: Ed Maste Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:51:33 -0000 On Fri, Jan 12, 2018 at 8:28 AM, Ed Maste wrote: > On 4 January 2018 at 03:10, Michael Tuexen wrote: > > > > 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. > > Both of my new co-op students have encountered this as well: after a > panic (unrelated to the filesystem), SU+J fsck recovery runs at boot, > and than many cylinder checksum warnings are emitted by the kernel. > The students used the default installer configuration; it sounds like > we should disable SU+J by default in the installer until this issue is > addressed. > I've posted https://reviews.freebsd.org/D13884 as well to change fsck from silently fixing the cg checksum to one that's whiny about it as well. Warner From owner-freebsd-current@freebsd.org Fri Jan 12 16:58:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19AF2E6FE56 for ; Fri, 12 Jan 2018 16:58:33 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE1DE7360A for ; Fri, 12 Jan 2018 16:58:32 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-236-88.albq.qwest.net [67.0.236.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id C94371928F3; Fri, 12 Jan 2018 08:53:27 +0000 (UTC) Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 To: Mike Tancsa , freebsd-current References: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> From: Sean Bruno Message-ID: <3ea937fe-bbb1-7f6f-f2e1-8a7d94e7feef@freebsd.org> Date: Fri, 12 Jan 2018 09:58:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bMeb66K2ywsbyMS49rVIGOU7zKheI3wbJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 16:58:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bMeb66K2ywsbyMS49rVIGOU7zKheI3wbJ Content-Type: multipart/mixed; boundary="NkxMLKz5zIdWb8qYCjWnGb1aqlDJ1PVcG"; protected-headers="v1" From: Sean Bruno To: Mike Tancsa , freebsd-current Message-ID: <3ea937fe-bbb1-7f6f-f2e1-8a7d94e7feef@freebsd.org> Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 References: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> In-Reply-To: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> --NkxMLKz5zIdWb8qYCjWnGb1aqlDJ1PVcG Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/12/18 08:38, Mike Tancsa wrote: > On 1/11/2018 6:03 PM, Sean Bruno wrote: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've= >> restructured and undone a few things that may have been keeping folks >> using this port from getting their runtime cpu microcode updates. > Hi, > I am trying out on RELENG_11 on a Ryzen CPU >=20 > Without kib's commits at >=20 > https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/0053= 20.html >=20 > I get >=20 > root@testamd:/usr/ports/sysutils/devcpu-data # > /usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Re-evalutation of CPU flags Failed. > root@testamd:/usr/ports/sysutils/devcpu-data # Correct, this is expected. >=20 > with r327597, >=20 > root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update ones= tart > Updating CPU Microcode... > Done. > root@testamd:/home/mdtancsa # >=20 >=20 >=20 > running x86info -a also generates this error / warning ? >=20 > CPU0: local APIC error 0x80 >=20 >=20 Probably, update your port of x86info. I pushed an update for this and it might work better for you. > root@testamd:/home/mdtancsa # x86info -a | grep -i microco > Microcode patch level: 0x8001129 > root@testamd:/home/mdtancsa # x86info -a | head -20 > x86info v1.31pre > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Unknown CPU family: 0x17 > Found 12 identical CPUs > Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 > CPU Model (x86info's best guess): > Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core > Processor >=20 > Number of reporting banks : 7 >=20 > root@testamd:/home/mdtancsa # >=20 >=20 > Also your diff is based on a previous version of the port. There was an= > update since, with new microcode from Intel that gets clobbered in your= > diffs. >=20 >=20 The update to Intel microcode was reverted. So, possibly the tree you are using is out of date? sean --NkxMLKz5zIdWb8qYCjWnGb1aqlDJ1PVcG-- --bMeb66K2ywsbyMS49rVIGOU7zKheI3wbJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlpY6TNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /Lb9/wf/Xyt559DKRQsExuc2YON8Wie5n7dUkv18oi+ZFgHBgTcvfzKV8N1HMcp/ X/J47LMo3WBB70YzBNwP6z4yDJGTa70k54Tbe3GMJUaCPM0kgPDMZa74XZGXCn2v rOJ8tTk/kQDBsjTSG/8+Tv+ESev3/++GY1tmKcxOwxWSxTGHVo/3NAoFNKbQX8mL viQKgnzJx4deeCTcK+7WdlVg1cikQ0loiUoZoJ7BoCTKtmcHFHp6QkU/qyqXiK1u Oz64EqvlaNIZNsECcRGDfFY4XNRjFjRhvO7RYbheJsGqCYl+0ZQ6Pm00NqUspF2F lxgM/Z7y9Bx6Kf4E6fc4bWIfGIBeaA== =P8/h -----END PGP SIGNATURE----- --bMeb66K2ywsbyMS49rVIGOU7zKheI3wbJ-- From owner-freebsd-current@freebsd.org Fri Jan 12 16:59:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC637E70000 for ; Fri, 12 Jan 2018 16:59:46 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA3A73784 for ; Fri, 12 Jan 2018 16:59:46 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (67-0-236-88.albq.qwest.net [67.0.236.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 6DD5E1928F3; Fri, 12 Jan 2018 08:54:42 +0000 (UTC) Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 To: Rainer Hurling , freebsd-current References: From: Sean Bruno Message-ID: Date: Fri, 12 Jan 2018 09:59:44 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b2204dL4EI1tE62nxZTMQQt4neysotUYY" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 16:59:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b2204dL4EI1tE62nxZTMQQt4neysotUYY Content-Type: multipart/mixed; boundary="L3AVSkCm3WAYEwLetkjtVL04Sac3AzmT3"; protected-headers="v1" From: Sean Bruno To: Rainer Hurling , freebsd-current Message-ID: Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 References: In-Reply-To: --L3AVSkCm3WAYEwLetkjtVL04Sac3AzmT3 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/12/18 04:49, Rainer Hurling wrote: > Am 12.01.2018 um 00:03 schrieb Sean Bruno: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've= >> restructured and undone a few things that may have been keeping folks >> using this port from getting their runtime cpu microcode updates. >> >> After installing the port, grab your microcode version via >> sysutils/x86info. If you don't see an update, that only means there i= s >> no update available for your system. >> >> x86info -a | grep Microcode >> >> Run the microcode_update and repeat. Check /var/log/messages for a >> notification that the code was updated. You should be able to get >> something like the following for your system if it executed an update:= >> >> root@lab:/home/sbruno # x86info -a | grep "CPU Model" >> CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2) >> >> root@lab:/home/sbruno # x86info -a | grep Microcode >> Microcode patch level: 0x6000629 >> >> root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart >> Updating CPU Microcode... >> Done. >> >> root@lab:/home/sbruno # x86info -a | grep Microcode >> Microcode patch level: 0x600063d >> >> root@lab:/home/sbruno # grep microcode_update /var/log/messages >> Jan 10 16:52:26 lab microcode_update: >> /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu >> /dev/cpuctl0 to revision 0x600063d... done. >> >=20 > Just for the record, for an older Phenom with dmesg: >=20 > CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU) > Origin=3D"AuthenticAMD" Id=3D0x100fa0 Family=3D0x10 Model=3D0xa S= tepping=3D0 > Features=3D0x178bfbff > Features2=3D0x802009 > AMD > Features=3D0xee500800 > AMD > Features2=3D0x37ff > SVM: NP,NRIP,NAsids=3D64 > TSC: P-state invariant, performance statistics >=20 >=20 > #x86info -a | grep "CPU Model" > CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion > (II)/Opteron (PH-E0) >=20 > #x86info -a | grep Microcode > Microcode patch level: 0x10000bf >=20 > #/usr/local/etc/rc.d/microcode_update onestart > Updating CPU Microcode... > Done. >=20 > #x86info -a | grep Microcode > Microcode patch level: 0x10000bf >=20 > #grep microcode_update /var/log/messages > --- >=20 > So no recent update and no log messages, as expected ;) >=20 > Regards, > Rainer Hurling >=20 Thank you! sean --L3AVSkCm3WAYEwLetkjtVL04Sac3AzmT3-- --b2204dL4EI1tE62nxZTMQQt4neysotUYY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAlpY6YBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LaaNQf8DLzajcjMM7i7BlAveTQ5QWaLbTe7aHwORf2eJleIW7swodXQ4V3AKelh Ympdx8dNY9TbPZ74CBjaniu18rzpGMQResvBUiEb45iQGP3WLjrkYq+t0a5DD2mR QBZZQEmHWnkp45i7VA+CQt9wehdT4qW9yq+uv18mBANHhymVdOWi4+DoAAaqupWO 6R5lkJbt1hQHRT4jsGKKtnDsBqf5SeLTlJ8HJ6vJIuk3FS/F0J/MLiqzO/KB7lxi vpI1FA4u+/wM+uVlHQp55aa9mZnCPC/brQ/P5malKKpuTRLGTK8p0TUuf6oI/1E1 QYl+bp/giWcdEEqXT1mgizEU+e565A== =31zV -----END PGP SIGNATURE----- --b2204dL4EI1tE62nxZTMQQt4neysotUYY-- From owner-freebsd-current@freebsd.org Fri Jan 12 17:12:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EA76E70B9E for ; Fri, 12 Jan 2018 17:12:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BBC07465C; Fri, 12 Jan 2018 17:12:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0CHCXGH011179 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Jan 2018 12:12:33 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0CHCVL1084026; Fri, 12 Jan 2018 12:12:31 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 To: Sean Bruno , freebsd-current References: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> <3ea937fe-bbb1-7f6f-f2e1-8a7d94e7feef@freebsd.org> From: Mike Tancsa Organization: Sentex Communications Message-ID: Date: Fri, 12 Jan 2018 12:12:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <3ea937fe-bbb1-7f6f-f2e1-8a7d94e7feef@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 17:12:34 -0000 On 1/12/2018 11:58 AM, Sean Bruno wrote: >> > > Probably, update your port of x86info. I pushed an update for this and > it might work better for you. Thanks, I tried it but still generates the error / warning. What does it mean ? (CPU0: local APIC error 0x80) It does however get rid of the "Unknown CPU family" error. root@testamd:/usr/ports/sysutils/devcpu-data # x86info -a | head x86info v1.31pre Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): AMD Zen Series Processor (ZP-B1) Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 MCG_CTL: Data cache check enabled root@testamd:/usr/ports/sysutils/devcpu-data # >> >> Also your diff is based on a previous version of the port. There was an >> update since, with new microcode from Intel that gets clobbered in your >> diffs. >> >> > > The update to Intel microcode was reverted. So, possibly the tree you > are using is out of date? Ahh, yes. I must have grabbed the ports just before you backed it out https://lists.freebsd.org/pipermail/svn-ports-all/2018-January/171209.html Thanks! ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@freebsd.org Fri Jan 12 17:36:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78416E71E03 for ; Fri, 12 Jan 2018 17:36:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C17676273; Fri, 12 Jan 2018 17:36:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w0CHa57s095689 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jan 2018 19:36:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w0CHa57s095689 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w0CHa5Ii095688; Fri, 12 Jan 2018 19:36:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jan 2018 19:36:05 +0200 From: Konstantin Belousov To: Mike Tancsa Cc: Sean Bruno , freebsd-current Subject: Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832 Message-ID: <20180112173605.GJ1684@kib.kiev.ua> References: <1075465a-ffef-95c7-7750-2d50d7b8a15c@sentex.net> <3ea937fe-bbb1-7f6f-f2e1-8a7d94e7feef@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 17:36:14 -0000 On Fri, Jan 12, 2018 at 12:12:31PM -0500, Mike Tancsa wrote: > On 1/12/2018 11:58 AM, Sean Bruno wrote: > >> > > > > Probably, update your port of x86info. I pushed an update for this and > > it might work better for you. > > Thanks, I tried it but still generates the error / warning. What does it > mean ? (CPU0: local APIC error 0x80) It means that the x86info accessed not implemented LAPIC register. This warning is mostly harmless. From owner-freebsd-current@freebsd.org Fri Jan 12 17:41:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36757E72354 for ; Fri, 12 Jan 2018 17:41:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9F5F76A89 for ; Fri, 12 Jan 2018 17:41:13 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id u62so9970413ita.2 for ; Fri, 12 Jan 2018 09:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H7lpZsSC0IXKOJ9bXZO0dLObJKhQkvQ+F2md5xtgySg=; b=ZEA97pHRxcSxAEDk5e0GjWEjCveMbPXqtQb+0k4hmF1klIg/YOETdeU7S0tW77Ayd+ Fetc2MTXhmUeuhf2pTqBcV6lyu62g9ZM6b7TMADrpqXR05+DyxWmlulc8UOVzao/Kh1w 1pGxnytThu0mOyQJJf/dO2aPkigM1lqjPzi3qHBZQehRqJ7W6oo1lJ7BYumMhAk6EgDp l3+eI1p8MDW9zWHxXvVuOD2ykFDK8Us9P34M3d0xxivssNieJEnJyC9/j7MlxUspkeZg nXffrzpI7G5MTNuxC5D+xl9oHb0GkAsbdifkw+cUOMZKx7/AfQGT9/wmPKblQgKcnV5E 7YFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H7lpZsSC0IXKOJ9bXZO0dLObJKhQkvQ+F2md5xtgySg=; b=RJRWH22FGQeXYKJvriM6UnrBY1qSBGVvJHcif1veEaN3P9iekfPEw8V0zTQ2iB2lmx BDYv6bOUnViicn/F+HMjIB1NQ9L4OW+iIIF8RAxpzTfDZ3j4J3RNMUPfF3Yg1IciZBQ9 EJQVk7o+prMRSNS8lti5l70tqYWnjAg2Rz8rgS812cuPSNtN+LmxT/+lm7zD5F+nLK6B jmMbADSlwVhDAIBwpbWfFaCFRGhWHZbx8sRDDZTz7WP+T5cPvy2MDwNTwGNvvksf9xXP i4lckg/z78tWAG41ypjIY/247H0S5SyS3jrnBHtPmNQyNAPPlTIxNGFuGm7m/TTPfHNm jIAQ== X-Gm-Message-State: AKwxytcGXvGkko1/5uWYuSmZh7o/NkD0EuxqfpNStKEH/zXm82BRArMQ HJiFf2H3VXYNItlkbR//bPqs74u5spRQebc8wfo= X-Google-Smtp-Source: ACJfBos0kRGHXUdEUQIRCZxuBvJhGMX7K9KWejOYEW6jW8hR60c/+tYhUlp9l5Jdjn8x3ZxWjjEk8hbVEUEY4lsijWg= X-Received: by 10.36.50.73 with SMTP id j70mr5438519ita.149.1515778872891; Fri, 12 Jan 2018 09:41:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.193 with HTTP; Fri, 12 Jan 2018 09:41:11 -0800 (PST) In-Reply-To: <90803456-FCAE-4F2D-9CC8-18C395E2C952@dsl-only.net> References: <3F9697E3-3C25-45CB-804A-9C3607E434C4@dsl-only.net> <0AB4ED58-E01A-4761-B6EF-4D56F8CA21E3@dsl-only.net> <1F10CBFE-1AAC-4307-976A-0CDA80EDC616@dsl-only.net> <2B2F495A-9CBE-4366-B049-0EC5EF7F9629@dsl-only.net> <899567F7-0C02-4A60-ADA0-5F43A6CF594B@dsl-only.net> <90803456-FCAE-4F2D-9CC8-18C395E2C952@dsl-only.net> From: blubee blubeeme Date: Sat, 13 Jan 2018 01:41:11 +0800 Message-ID: Subject: Re: USB stack To: Mark Millard Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 17:41:14 -0000 On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard wrote: > > On 2018-Jan-8, at 1:15 AM, blubee blubeeme wrote: > > > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard > wrote: > >> [The involvement of sysutils/fusefs-simple-mtpfs > >> and sysutils/fusefs-libs and multimedia/libmtp > >> in order to use the Media Transfer Protocol (MTP) > >> against the LG v30 likely explains much of the > >> performance difference vs. local UFS file > >> systems. I provide some related notes.] > >> > >> blubee blubeeme gurenchan at gmail.com wrote on > >> Mon Jan 8 05:17:24 UTC 2018 : > >> > >> [Note: the original was in a reply to a Jon Brawn > >> post. I've merged it back with my post.] > >> > >> > On 2018-Jan-7, at 11:46 AM, Mark Millard > wrote: > >> > > >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme > wrote: > >> >> > >> >> > >> >> > >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard dsl-only.net> wrote: > >> >>> > >> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme > wrote: > >> >>>> > >> >>>>> I ran this test and here's some results. > >> >>>>> gstat -pd images: > >> >>>>> > >> >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >> >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >> >>>>> multiple small files from laptop to phone: > https://imgur.com/a/B4v4y > >> >>>>> multiple small files from laptop to ssd: > https://imgur.com/a/mDiMu > >> >>>>> > >> >>>>> The files are missing timestamps but the originals were taken > with scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >> >>>>> > >> >>>>> as far as why there's such high deletions? I can't say I'm only > using cp. > >> >>>> > >> >>>> I assume that md99 is for a file-based swap-space, such as > >> >>>> via /var/swap0 file. (As a side note I warn about bugzilla > >> >>>> 206048 for such contexts.) Otherwise please describe how > >> >>>> md99 is created. (Below I assume the swap-space usage of > >> >>>> md99.) > >> >>>> > >> >>>> The only other device that your pictures show is your > >> >>>> NVMe device nvd0. > >> >>>> > >> >>>> No picture shows a device for the LG v30 when it is mentioned > >> >>>> above as being copied to or from. How is it that there is no > >> >>>> mounted device shown for the LG v30? > >> >>>> > >> >>>> No picture shows a device for the SSD when it is mentioned > >> >>>> above as being copied to or from. How is it that there > >> >>>> is no mounted device shown for the SSD? > >> >>>> > >> >>>> Without a device displayed for the LG-v30/SSD there is nothing > >> >>>> displayed for its reads or writes. This makes the gstat -pd > >> >>>> useless. > >> >>>> > >> >>>> May be the p needs to be omitted for some reason? gstat -d > >> >>>> > >> >>>> === > >> >>>> Mark Millard > >> >>>> markmi at dsl-only.net > >> >>> > >> >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >> >>> > >> >>> Those tests earlier was a huge time sink. > >> >>> Here's the dmesg output from earlier: > >> >>> . . . > >> >>> ---------------------------------- > >> >>> > >> >>> I don't know why gstat isn't showing the info u are looking for. > >> >>> > >> >>> You said earlier that something was getting deleted, > >> >>> I don't know what could be causing that. > >> >> > >> >> Those "deletes" are more commonly called TRIM on SSD's. > >> >> FreeBSD called them, BIO_DELETE as I remember. > >> >> > >> >> Those deletes have nothing to do with umounting, deleteing > >> >> devices, etc. > >> >> > >> >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... > >> >>> Even say forget the mobile device and go from > >> >>> zpool > >> >> > >> >> From which I've not been able to figure out the kind of > >> >> information that I'm looking for. > >> >> > >> >> Just because a device is present, does not mean that it > >> >> is available as a file system. I'm more interested in > >> >> how the file systems are made available --or if some > >> >> non-file system way of working is involved. > >> >> > >> >>> Are you saying that there's something misconfigured on my end? > >> >>> What other info do you need me to provide to try to figure out > >> >>> what's going on or why I'm getting these transfer rates? > >> >> > >> >> I'm saying I still can not tell how you make the SSD or the > >> >> LGv 30 available to FreeBSD (mount?). Or why no matching > >> >> mounted device shows up in gstat's display. > >> >> > >> >> If you wish to keep trying to help me help you, . . . > >> >> > >> >> Please show how you make the file system on the > >> >> SSD available to FreeBSD: what FreeBSD commands make > >> >> the device available for use. (I'd guess that mount > >> >> is used or that something like /etc/fstab is used > >> >> to do mounts more implicitly.) > >> >> > >> >> Please show how you make the LG v30 available to FreeBSD: > >> >> what FreeBSD commands make the device available for > >> >> use. (I'd guess that mount is used or that 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? > >> > > >> [Extracted from a reply to a Jon Brawn post.] > >> > @Mark Millard > >> > I use sysutils/simple-mtpfs to mount the android device. > >> > when I mount the phone through USB this is the relevant section: > >> > /dev/fuse 356311 78912 277398 22% > >> > /mnt > >> > > >> > That's the most complicated mount process that I use, > >> > for the ssd it's just a simple mount /dev/device /mnt > >> > relevant output: > >> > /dev/da0 923913 121450 728550 > 14% > >> > /mnt > >> > > >> > Can you tell me what information you're looking for so that I can > gather it > >> > all up and send it. > >> > >> > >> I do not find a /usr/ports/sysutils/simple-mtpfs . But I > >> do find: > >> > >> # ls -lTd /usr/ports/sysutils/*simple* > >> drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 > /usr/ports/sysutils/fusefs-simple-mtpfs > >> > >> And that was very important to know. > >> > >> . . . > > > > > > OK, forget the android specific usb issues for now; > > there is quite a few layers of crud between the laptop and the android > device. > > > > I have this SSD. > > > > What are some tests that you'd like to run to test the speeds > > on my end? > > Returning to just the SSD context. . . > > Because your pictures were missing the SSD for some > reason, we first need to figure out if and how to > see the SSD activity levels, such as via gstat. > > For now I focus on just that. > > You provided as information about the SSD: > > /dev/da0 923913 121450 728550 14% > /mnt > > which is from "df -m". But I'd also asked for "mount" > output. As an example for one of my contexts: > > # mount > /dev/gpt/FBSDFSSDroot on / (ufs, NFS exported, local, noatime, > soft-updates) > devfs on /dev (devfs, local, multilabel) > > Note the types of information displayed, which is very different from > what df -m reports. > > ( /dev/gpt/FBSDFSSDroot is a label reference instead of a physical > device and partition/slice number notation.) > > After mounting the partition/slice from the SSD, can you show the > mount command's description of the partition/slice that you mounted? > > (Actually, your "df -m" output does not show a partition/slice > notation. I'm not sure what to make of that.) > > There is another view of things that can be handy. . . > (output is from one of my example contexts) > > # gpart show -p da0 > => 40 937703008 da0 GPT (447G) > 40 1024 da0p1 freebsd-boot (512K) > 1064 746586112 da0p2 freebsd-ufs (356G) > 746587176 31457280 da0p3 freebsd-swap (15G) > 778044456 159383552 da0p4 freebsd-swap (76G) > 937428008 275040 - free - (134M) > > Note: Normally da0 would not show up in a mount > line, instead it would be /dev/da0p2 for the UFS > partition being mounted in my example. > > Your da0 might not show GPT or any other partition > or slice structure (given the "df -m" output that > you listed). > > (If zfs is involved, there may be better commands > for some types of information above, but I've minimal > ZFS background knowledge. You may have to explain > your configuration if ZFS is in use on the SSD.) > > With that much information (if non-ZFS), I know what > I expect to be listed in gstat -pd and in gstat -d . > > It is possible to use just: > > gstat -d > > and the same device and its partitions will show up > multiple times for different ways they can be > accessed. For example: > > dT: 1.073s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| label/FBSDx64Cboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDroot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDswap > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDswap2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDbkp > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| ufsid/ > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSroot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| ufsid/ > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFBswap > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSswap > > The sorter list from gstat -pd can be nicer to look at > when its content happens to be sufficient for ones > purpose at the time. Otherwise the fuller list can be > used, giving specific rates and such for individual > partitions. > > > The initial question for gstat seems to be: can we find the mounted > SSD partition/slice and/or the overall SSD device in the gstat output. > Can you check on that? If you find the partition and/or overall device, > can you show those lines so that I know what they look like? > > (gstat might not be an appropriate tool if the SSD is a ZFS-only > device.) > > === > Mark Millard > markmi at dsl-only.net > > > I didn't restart gstat between the tests... so It didn't update to show the devices after they were added. dT: 1.064s w: 1.000s filter: d L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| nvd0 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p1 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p2 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p3 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p4 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI 0 0 0 0 0.0 0 0 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0.0| ufsid/xxxx 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/TRANSCEND This is the current output for a simple USB device but this brings up a whole new slew of errors; not related to speed but of encodings. From owner-freebsd-current@freebsd.org Fri Jan 12 19:31:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C5C0E77B90 for ; Fri, 12 Jan 2018 19:31:50 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 67E1D7BAB9 for ; Fri, 12 Jan 2018 19:31:49 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 52E865646F for ; Fri, 12 Jan 2018 13:31:43 -0600 (CST) From: Eric van Gyzen Subject: td_swvoltick To: FreeBSD Current Message-ID: <603d2786-86be-583c-9ff6-d8d73eddf77e@vangyzen.net> Date: Fri, 12 Jan 2018 13:31:41 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 19:31:50 -0000 should_yield() compares thread::td_swvoltick to 'ticks' to determine whether a thread is hogging and should yield. Since td_swvoltick records 'ticks' /before/ the actual context switch, the calculation in should_yield() includes any time that the thread was switched out. It seems that should_yield() wants to know how long the thread has actually been running. Therefore, td_swvoltick should record 'ticks' /after/ sched_switch() returns. Does this make sense, or am I missing something? If this makes sense, I would probably keep the current assignment in mi_switch() and simply add a second assignment after the call to sched_switch(). That way, db_show_thread will still show useful data for sleeping threads. I would do the same for td_swinvolticks. I'll be happy to make the change myself. I just want a sanity check before I bother. Thanks in advance, Eric From owner-freebsd-current@freebsd.org Fri Jan 12 19:37:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D44D1E77F91 for ; Fri, 12 Jan 2018 19:37:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5205C7BEE2 for ; Fri, 12 Jan 2018 19:37:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w0CJaxop023848 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jan 2018 21:37:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w0CJaxop023848 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w0CJaxpA023847; Fri, 12 Jan 2018 21:36:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jan 2018 21:36:59 +0200 From: Konstantin Belousov To: Eric van Gyzen Cc: FreeBSD Current Subject: Re: td_swvoltick Message-ID: <20180112193659.GL1684@kib.kiev.ua> References: <603d2786-86be-583c-9ff6-d8d73eddf77e@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <603d2786-86be-583c-9ff6-d8d73eddf77e@vangyzen.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 19:37:07 -0000 On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote: > should_yield() compares thread::td_swvoltick to 'ticks' to determine > whether a thread is hogging and should yield. Since td_swvoltick > records 'ticks' /before/ the actual context switch, the calculation in > should_yield() includes any time that the thread was switched out. It > seems that should_yield() wants to know how long the thread has actually > been running. Therefore, td_swvoltick should record 'ticks' /after/ > sched_switch() returns. > > Does this make sense, or am I missing something? Yes, it does make sense to me. > > If this makes sense, I would probably keep the current assignment in > mi_switch() and simply add a second assignment after the call to > sched_switch(). That way, db_show_thread will still show useful data > for sleeping threads. I would do the same for td_swinvolticks. > > I'll be happy to make the change myself. I just want a sanity check > before I bother. > > Thanks in advance, > > Eric > _______________________________________________ > 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" From owner-freebsd-current@freebsd.org Fri Jan 12 22:37:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0683CEA5534 for ; Fri, 12 Jan 2018 22:37:00 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id E51C884E92 for ; Fri, 12 Jan 2018 22:36:58 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 8CD065646F; Fri, 12 Jan 2018 16:36:57 -0600 (CST) Subject: Re: td_swvoltick To: Konstantin Belousov Cc: FreeBSD Current References: <603d2786-86be-583c-9ff6-d8d73eddf77e@vangyzen.net> <20180112193659.GL1684@kib.kiev.ua> From: Eric van Gyzen Message-ID: Date: Fri, 12 Jan 2018 16:36:56 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180112193659.GL1684@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 22:37:00 -0000 On 01/12/2018 13:36, Konstantin Belousov wrote: > On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote: >> should_yield() compares thread::td_swvoltick to 'ticks' to determine >> whether a thread is hogging and should yield. Since td_swvoltick >> records 'ticks' /before/ the actual context switch, the calculation in >> should_yield() includes any time that the thread was switched out. It >> seems that should_yield() wants to know how long the thread has actually >> been running. Therefore, td_swvoltick should record 'ticks' /after/ >> sched_switch() returns. >> >> Does this make sense, or am I missing something? > Yes, it does make sense to me. Thanks, Kostik. If anyone else is interested: https://reviews.freebsd.org/D13892 >> >> If this makes sense, I would probably keep the current assignment in >> mi_switch() and simply add a second assignment after the call to >> sched_switch(). That way, db_show_thread will still show useful data >> for sleeping threads. I would do the same for td_swinvolticks. >> >> I'll be happy to make the change myself. I just want a sanity check >> before I bother. >> >> Thanks in advance, >> >> Eric