From owner-freebsd-stable@freebsd.org Sun Dec 1 00:34:46 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBFED1BDF72 for ; Sun, 1 Dec 2019 00:34:46 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from ihor-5.amdmi3.ru (ihor-5.amdmi3.ru [185.238.136.130]) by mx1.freebsd.org (Postfix) with ESMTP id 47QTln4kjVz3FN6 for ; Sun, 1 Dec 2019 00:34:45 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from amdmi3.ru (localhost [IPv6:::1]) by ihor-5.amdmi3.ru (Postfix) with SMTP id 98B2113B95; Sun, 1 Dec 2019 03:34:36 +0300 (MSK) Received: by amdmi3.ru (nbSMTP-1.00) for uid 1001 amdmi3@amdmi3.ru; Sun, 1 Dec 2019 03:34:36 +0300 (MSK) Date: Sun, 1 Dec 2019 03:24:11 +0300 From: Dmitry Marakasov To: Konstantin Belousov Cc: freebsd-stable@freebsd.org Subject: Re: How can kill(-1, 0) return EPERM? Message-ID: <20191201002411.GF4071@hades.panopticon> References: <20191129151606.GD4071@hades.panopticon> <20191129164509.GE4071@hades.panopticon> <20191129225834.GY10580@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191129225834.GY10580@kib.kiev.ua> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 47QTln4kjVz3FN6 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of amdmi3@amdmi3.ru has no SPF policy when checking 185.238.136.130) smtp.mailfrom=amdmi3@amdmi3.ru X-Spamd-Result: default: False [3.53 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[amdmi3.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.12)[0.125,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.98)[0.985,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:48666, ipnet:185.238.136.0/22, country:RU]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.42)[ip: (-0.17), ipnet: 185.238.136.0/22(0.48), asn: 48666(1.77), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 00:34:46 -0000 * Konstantin Belousov (kostikbel@gmail.com) wrote: > > > I'm helping to investigate some userspace issue [1], where kill(-1, SIGKILL) > > > fails with EPERM. I've managed to isolate this case in a small program: > > > > > > > > > ``` > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > > > > int main() { > > > if (setuid(66) == -1) // uucp, just for the test > > > err(1, "setuid"); > > > > > > int res = kill(-1, 0); // <- fails with EPERM > > > fprintf(stderr, "kill(-1, 0) result=%d, errno=%s\n", res, strerror(errno)); > > > > > > return 0; > > > } > > > ``` > > > > > > when run from root on 12.1 kill call fails with EPERM. However I cannot > > > comprehend what it is caused by and how it's even possible: kill(2) manpage > > > says that with pid=-1 kill should only send (and in this case of sig=0, > > > /not/ send) signals to the processes belonging to the current uid, so there > > > should be no permission problems. I've also looked into the kernel code > > > (sys_kill, killpg1), and it matches to what manpage says, I see no way > > > for it to return EPERM: sys_kill() should fall through to the switch, call > > > killpg1() with all=1 and killpg1() if(all) branch may only set `ret` to > > > either 0 or ESRCH. Am I missing something, or is there a problem somewhere? > > > > It looks like I have misread the `else if' path of this core. > > > > if (all) { > > /* > > * broadcast > > */ > > sx_slock(&allproc_lock); > > FOREACH_PROC_IN_SYSTEM(p) { > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > p == td->td_proc || p->p_state == PRS_NEW) { > > continue; > > } > > PROC_LOCK(p); > > err = p_cansignal(td, p, sig); > > if (err == 0) { > > if (sig) > > pksignal(p, sig, ksi); > > ret = err; > > } > > else if (ret == ESRCH) > > ret = err; > > PROC_UNLOCK(p); > > } > > sx_sunlock(&allproc_lock); > > } ... > > > > so it's clear now where EPERM comes from. However it looks like the > > behavior contradicts the manpage - there are no signs of check that > > the signalled process has the same uid as the caller. > > I am not sure what you mean by 'signs of check'. Look at p_cansignal() > and cr_cansignal() implementation. I've meant that according to the manpage If pid is -1: If the user has super-user privileges, the signal is sent to all processes excluding system processes (with P_SYSTEM flag set), process with ID 1 (usually init(8)), and the process sending the signal. If the user is not the super user, the signal is sent to all processes with the same uid as the user excluding the process sending the signal. No error is returned if any process could be signaled. IMO there should be an additional check in this condition: if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || p == td->td_proc || p->p_state == PRS_NEW) { continue; } E.g. something like if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || p == td->td_proc || p->p_state == PRS_NEW || (td->td_ucred->cr_ruid != 0 && p->td_ucred->cr_ruid != td->td_ucred->cr_ruid) { continue; } e.g. it should not even attempt to signal processes with other uids. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: https://github.com/AMDmi3 From owner-freebsd-stable@freebsd.org Sun Dec 1 14:48:28 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 412E41ADD82 for ; Sun, 1 Dec 2019 14:48:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Qrhq0VYlz3PMy for ; Sun, 1 Dec 2019 14:48:26 +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 xB1EmDpD055444 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 1 Dec 2019 16:48:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xB1EmDpD055444 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xB1EmDqZ055443; Sun, 1 Dec 2019 16:48:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Dec 2019 16:48:13 +0200 From: Konstantin Belousov To: Dmitry Marakasov Cc: freebsd-stable@freebsd.org Subject: Re: How can kill(-1, 0) return EPERM? Message-ID: <20191201144813.GD10580@kib.kiev.ua> References: <20191129151606.GD4071@hades.panopticon> <20191129164509.GE4071@hades.panopticon> <20191129225834.GY10580@kib.kiev.ua> <20191201002411.GF4071@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191201002411.GF4071@hades.panopticon> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47Qrhq0VYlz3PMy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.70), ipnet: 2001:470::/32(-4.64), asn: 6939(-3.52), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 14:48:28 -0000 On Sun, Dec 01, 2019 at 03:24:11AM +0300, Dmitry Marakasov wrote: > * Konstantin Belousov (kostikbel@gmail.com) wrote: > > > > > I'm helping to investigate some userspace issue [1], where kill(-1, SIGKILL) > > > > fails with EPERM. I've managed to isolate this case in a small program: > > > > > > > > > > > > ``` > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > > > > > int main() { > > > > if (setuid(66) == -1) // uucp, just for the test > > > > err(1, "setuid"); > > > > > > > > int res = kill(-1, 0); // <- fails with EPERM > > > > fprintf(stderr, "kill(-1, 0) result=%d, errno=%s\n", res, strerror(errno)); > > > > > > > > return 0; > > > > } > > > > ``` > > > > > > > > when run from root on 12.1 kill call fails with EPERM. However I cannot > > > > comprehend what it is caused by and how it's even possible: kill(2) manpage > > > > says that with pid=-1 kill should only send (and in this case of sig=0, > > > > /not/ send) signals to the processes belonging to the current uid, so there > > > > should be no permission problems. I've also looked into the kernel code > > > > (sys_kill, killpg1), and it matches to what manpage says, I see no way > > > > for it to return EPERM: sys_kill() should fall through to the switch, call > > > > killpg1() with all=1 and killpg1() if(all) branch may only set `ret` to > > > > either 0 or ESRCH. Am I missing something, or is there a problem somewhere? > > > > > > It looks like I have misread the `else if' path of this core. > > > > > > if (all) { > > > /* > > > * broadcast > > > */ > > > sx_slock(&allproc_lock); > > > FOREACH_PROC_IN_SYSTEM(p) { > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > > p == td->td_proc || p->p_state == PRS_NEW) { > > > continue; > > > } > > > PROC_LOCK(p); > > > err = p_cansignal(td, p, sig); > > > if (err == 0) { > > > if (sig) > > > pksignal(p, sig, ksi); > > > ret = err; > > > } > > > else if (ret == ESRCH) > > > ret = err; > > > PROC_UNLOCK(p); > > > } > > > sx_sunlock(&allproc_lock); > > > } ... > > > > > > so it's clear now where EPERM comes from. However it looks like the > > > behavior contradicts the manpage - there are no signs of check that > > > the signalled process has the same uid as the caller. > > > > I am not sure what you mean by 'signs of check'. Look at p_cansignal() > > and cr_cansignal() implementation. > > I've meant that according to the manpage > > If pid is -1: > If the user has super-user privileges, the signal is sent to all > processes excluding system processes (with P_SYSTEM flag set), > process with ID 1 (usually init(8)), and the process sending the > signal. If the user is not the super user, the signal is sent to > all processes with the same uid as the user excluding the process > sending the signal. No error is returned if any process could be > signaled. > > IMO there should be an additional check in this condition: > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > p == td->td_proc || p->p_state == PRS_NEW) { > continue; > } > > E.g. something like > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > p == td->td_proc || p->p_state == PRS_NEW || > (td->td_ucred->cr_ruid != 0 && > p->td_ucred->cr_ruid != td->td_ucred->cr_ruid) { > continue; > } > > e.g. it should not even attempt to signal processes with other uids. Why ? You are trying to outguess p_cansignal(), which could deny action for much more reasons, so you would get EPERM still, e.g. if the target is suid. Or, p_cansignal() also might allow to send the signal even for mismatched uids, again look at it code. I might guess that your complain is really about a different aspect of it. If you look at the posix description of the EPERM error from kill(2) (really kill(3)), it says [EPERM] The process does not have permission to send the signal to any receiving process. In other words, we should not return EPERM if we signalled at least one of the process. Is this the problem ? From owner-freebsd-stable@freebsd.org Sun Dec 1 23:21:46 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49DAC1BC571 for ; Sun, 1 Dec 2019 23:21:46 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from ihor-5.amdmi3.ru (ihor-5.amdmi3.ru [185.238.136.130]) by mx1.freebsd.org (Postfix) with ESMTP id 47R4544DtRz4Nf7 for ; Sun, 1 Dec 2019 23:21:44 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from amdmi3.ru (localhost [IPv6:::1]) by ihor-5.amdmi3.ru (Postfix) with SMTP id 37BAC13B79; Mon, 2 Dec 2019 02:21:41 +0300 (MSK) Received: by amdmi3.ru (nbSMTP-1.00) for uid 1001 amdmi3@amdmi3.ru; Mon, 2 Dec 2019 02:21:41 +0300 (MSK) Date: Mon, 2 Dec 2019 02:11:14 +0300 From: Dmitry Marakasov To: Konstantin Belousov Cc: freebsd-stable@freebsd.org Subject: Re: How can kill(-1, 0) return EPERM? Message-ID: <20191201231114.GG4071@hades.panopticon> References: <20191129151606.GD4071@hades.panopticon> <20191129164509.GE4071@hades.panopticon> <20191129225834.GY10580@kib.kiev.ua> <20191201002411.GF4071@hades.panopticon> <20191201144813.GD10580@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191201144813.GD10580@kib.kiev.ua> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 47R4544DtRz4Nf7 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of amdmi3@amdmi3.ru has no SPF policy when checking 185.238.136.130) smtp.mailfrom=amdmi3@amdmi3.ru X-Spamd-Result: default: False [3.83 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[amdmi3.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.43)[0.428,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.99)[0.986,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:48666, ipnet:185.238.136.0/22, country:RU]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.42)[ip: (-0.17), ipnet: 185.238.136.0/22(0.47), asn: 48666(1.77), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 23:21:46 -0000 * Konstantin Belousov (kostikbel@gmail.com) wrote: > > > > > I'm helping to investigate some userspace issue [1], where kill(-1, SIGKILL) > > > > > fails with EPERM. I've managed to isolate this case in a small program: > > > > > > > > > > > > > > > ``` > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > #include > > > > > > > > > > int main() { > > > > > if (setuid(66) == -1) // uucp, just for the test > > > > > err(1, "setuid"); > > > > > > > > > > int res = kill(-1, 0); // <- fails with EPERM > > > > > fprintf(stderr, "kill(-1, 0) result=%d, errno=%s\n", res, strerror(errno)); > > > > > > > > > > return 0; > > > > > } > > > > > ``` > > > > > > > > > > when run from root on 12.1 kill call fails with EPERM. However I cannot > > > > > comprehend what it is caused by and how it's even possible: kill(2) manpage > > > > > says that with pid=-1 kill should only send (and in this case of sig=0, > > > > > /not/ send) signals to the processes belonging to the current uid, so there > > > > > should be no permission problems. I've also looked into the kernel code > > > > > (sys_kill, killpg1), and it matches to what manpage says, I see no way > > > > > for it to return EPERM: sys_kill() should fall through to the switch, call > > > > > killpg1() with all=1 and killpg1() if(all) branch may only set `ret` to > > > > > either 0 or ESRCH. Am I missing something, or is there a problem somewhere? > > > > > > > > It looks like I have misread the `else if' path of this core. > > > > > > > > if (all) { > > > > /* > > > > * broadcast > > > > */ > > > > sx_slock(&allproc_lock); > > > > FOREACH_PROC_IN_SYSTEM(p) { > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > > > p == td->td_proc || p->p_state == PRS_NEW) { > > > > continue; > > > > } > > > > PROC_LOCK(p); > > > > err = p_cansignal(td, p, sig); > > > > if (err == 0) { > > > > if (sig) > > > > pksignal(p, sig, ksi); > > > > ret = err; > > > > } > > > > else if (ret == ESRCH) > > > > ret = err; > > > > PROC_UNLOCK(p); > > > > } > > > > sx_sunlock(&allproc_lock); > > > > } ... > > > > > > > > so it's clear now where EPERM comes from. However it looks like the > > > > behavior contradicts the manpage - there are no signs of check that > > > > the signalled process has the same uid as the caller. > > > > > > I am not sure what you mean by 'signs of check'. Look at p_cansignal() > > > and cr_cansignal() implementation. > > > > I've meant that according to the manpage > > > > If pid is -1: > > If the user has super-user privileges, the signal is sent to all > > processes excluding system processes (with P_SYSTEM flag set), > > process with ID 1 (usually init(8)), and the process sending the > > signal. If the user is not the super user, the signal is sent to > > all processes with the same uid as the user excluding the process > > sending the signal. No error is returned if any process could be > > signaled. > > > > IMO there should be an additional check in this condition: > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > p == td->td_proc || p->p_state == PRS_NEW) { > > continue; > > } > > > > E.g. something like > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > p == td->td_proc || p->p_state == PRS_NEW || > > (td->td_ucred->cr_ruid != 0 && > > p->td_ucred->cr_ruid != td->td_ucred->cr_ruid) { > > continue; > > } > > > > e.g. it should not even attempt to signal processes with other uids. > Why ? You are trying to outguess p_cansignal(), which could deny > action for much more reasons, so you would get EPERM still, e.g. if the > target is suid. Or, p_cansignal() also might allow to send the signal > even for mismatched uids, again look at it code. Exactly because of that - p_cansignal behaves in it's own way, which doesn't match the indended/documented kill(2) behavior. You're right in a sence that plain uid check is not sufficient though. > I might guess that your complain is really about a different aspect > of it. If you look at the posix description of the EPERM error from > kill(2) (really kill(3)), it says > [EPERM] The process does not have permission to send the signal to > any receiving process. > In other words, we should not return EPERM if we signalled at least one > of the process. > > Is this the problem ? It's not limited with this aspect. Here are some possible cases: - no processes with the same UID - one process with the same UID which can be signalled - one process with the same UID which cannot (say, because of MAC) be signalled - case of one process with the different UID which can be signalled The kill(-1, 0) with the given UID results are/should be, correspondingly: As per documentation: ESRCH, 0, EPERM, ESRCH As per current implementation: EPERM, 0, EPERM, 0 As per implementation which relies solely on *_cansignal: ESRCH, 0, ESRCH, 0 (unrelated process signalled) As you can see, relying soleley on p_cansignel would fix one case, but break the others. We may need a trimmed down variant of p_cansignal for this. Or make the latter take the mask of which checks it should perform or skip. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: https://github.com/AMDmi3 From owner-freebsd-stable@freebsd.org Mon Dec 2 00:45:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5AE171BEDDF for ; Mon, 2 Dec 2019 00:45:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47R5xk3KDsz4S29 for ; Mon, 2 Dec 2019 00:45:30 +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 xB20jL3f004862 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 2 Dec 2019 02:45:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xB20jL3f004862 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xB20jK82004845; Mon, 2 Dec 2019 02:45:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Dec 2019 02:45:20 +0200 From: Konstantin Belousov To: Dmitry Marakasov Cc: freebsd-stable@freebsd.org Subject: Re: How can kill(-1, 0) return EPERM? Message-ID: <20191202004520.GI10580@kib.kiev.ua> References: <20191129151606.GD4071@hades.panopticon> <20191129164509.GE4071@hades.panopticon> <20191129225834.GY10580@kib.kiev.ua> <20191201002411.GF4071@hades.panopticon> <20191201144813.GD10580@kib.kiev.ua> <20191201231114.GG4071@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191201231114.GG4071@hades.panopticon> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47R5xk3KDsz4S29 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.68), ipnet: 2001:470::/32(-4.64), asn: 6939(-3.52), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 00:45:31 -0000 On Mon, Dec 02, 2019 at 02:11:14AM +0300, Dmitry Marakasov wrote: > * Konstantin Belousov (kostikbel@gmail.com) wrote: > > > > > > > I'm helping to investigate some userspace issue [1], where kill(-1, SIGKILL) > > > > > > fails with EPERM. I've managed to isolate this case in a small program: > > > > > > > > > > > > > > > > > > ``` > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > > > > > > > int main() { > > > > > > if (setuid(66) == -1) // uucp, just for the test > > > > > > err(1, "setuid"); > > > > > > > > > > > > int res = kill(-1, 0); // <- fails with EPERM > > > > > > fprintf(stderr, "kill(-1, 0) result=%d, errno=%s\n", res, strerror(errno)); > > > > > > > > > > > > return 0; > > > > > > } > > > > > > ``` > > > > > > > > > > > > when run from root on 12.1 kill call fails with EPERM. However I cannot > > > > > > comprehend what it is caused by and how it's even possible: kill(2) manpage > > > > > > says that with pid=-1 kill should only send (and in this case of sig=0, > > > > > > /not/ send) signals to the processes belonging to the current uid, so there > > > > > > should be no permission problems. I've also looked into the kernel code > > > > > > (sys_kill, killpg1), and it matches to what manpage says, I see no way > > > > > > for it to return EPERM: sys_kill() should fall through to the switch, call > > > > > > killpg1() with all=1 and killpg1() if(all) branch may only set `ret` to > > > > > > either 0 or ESRCH. Am I missing something, or is there a problem somewhere? > > > > > > > > > > It looks like I have misread the `else if' path of this core. > > > > > > > > > > if (all) { > > > > > /* > > > > > * broadcast > > > > > */ > > > > > sx_slock(&allproc_lock); > > > > > FOREACH_PROC_IN_SYSTEM(p) { > > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > > > > p == td->td_proc || p->p_state == PRS_NEW) { > > > > > continue; > > > > > } > > > > > PROC_LOCK(p); > > > > > err = p_cansignal(td, p, sig); > > > > > if (err == 0) { > > > > > if (sig) > > > > > pksignal(p, sig, ksi); > > > > > ret = err; > > > > > } > > > > > else if (ret == ESRCH) > > > > > ret = err; > > > > > PROC_UNLOCK(p); > > > > > } > > > > > sx_sunlock(&allproc_lock); > > > > > } ... > > > > > > > > > > so it's clear now where EPERM comes from. However it looks like the > > > > > behavior contradicts the manpage - there are no signs of check that > > > > > the signalled process has the same uid as the caller. > > > > > > > > I am not sure what you mean by 'signs of check'. Look at p_cansignal() > > > > and cr_cansignal() implementation. > > > > > > I've meant that according to the manpage > > > > > > If pid is -1: > > > If the user has super-user privileges, the signal is sent to all > > > processes excluding system processes (with P_SYSTEM flag set), > > > process with ID 1 (usually init(8)), and the process sending the > > > signal. If the user is not the super user, the signal is sent to > > > all processes with the same uid as the user excluding the process > > > sending the signal. No error is returned if any process could be > > > signaled. > > > > > > IMO there should be an additional check in this condition: > > > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > > p == td->td_proc || p->p_state == PRS_NEW) { > > > continue; > > > } > > > > > > E.g. something like > > > > > > if (p->p_pid <= 1 || p->p_flag & P_SYSTEM || > > > p == td->td_proc || p->p_state == PRS_NEW || > > > (td->td_ucred->cr_ruid != 0 && > > > p->td_ucred->cr_ruid != td->td_ucred->cr_ruid) { > > > continue; > > > } > > > > > > e.g. it should not even attempt to signal processes with other uids. > > Why ? You are trying to outguess p_cansignal(), which could deny > > action for much more reasons, so you would get EPERM still, e.g. if the > > target is suid. Or, p_cansignal() also might allow to send the signal > > even for mismatched uids, again look at it code. > > Exactly because of that - p_cansignal behaves in it's own way, which > doesn't match the indended/documented kill(2) behavior. You're right > in a sence that plain uid check is not sufficient though. > > > I might guess that your complain is really about a different aspect > > of it. If you look at the posix description of the EPERM error from > > kill(2) (really kill(3)), it says > > [EPERM] The process does not have permission to send the signal to > > any receiving process. > > In other words, we should not return EPERM if we signalled at least one > > of the process. > > > > Is this the problem ? > > It's not limited with this aspect. Here are some possible cases: > > - no processes with the same UID > - one process with the same UID which can be signalled > - one process with the same UID which cannot (say, because of MAC) be signalled > - case of one process with the different UID which can be signalled > > The kill(-1, 0) with the given UID results are/should be, correspondingly: > > As per documentation: ESRCH, 0, EPERM, ESRCH > As per current implementation: EPERM, 0, EPERM, 0 > As per implementation which relies solely on *_cansignal: > ESRCH, 0, ESRCH, 0 (unrelated process signalled) > > As you can see, relying soleley on p_cansignel would fix one case, but > break the others. We may need a trimmed down variant of p_cansignal for > this. Or make the latter take the mask of which checks it should > perform or skip. No, I do not see. Matching uid is red herring, according to POSIX ESRCH should be returned when there is no visible matching processes at all, EPERM should be returned if there are processes, but no processes can be signalled due to permission issues. Otherwise, at least one process got a signal, and the return value should be zero. I tried to adjust this in https://reviews.freebsd.org/D22621, where I already added you as subscriber. From owner-freebsd-stable@freebsd.org Mon Dec 2 04:30:33 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B8F71C456D for ; Mon, 2 Dec 2019 04:30:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RBxN3M8Jz4c84 for ; Mon, 2 Dec 2019 04:30:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB24QF1X012522 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Dec 2019 04:26:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bennett@sdf.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB24Q8au093939 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Dec 2019 11:26:08 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Slow zfs destroy To: Scott Bennett References: <201911291757.xATHv1P1003382@sdf.org> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> Date: Mon, 2 Dec 2019 11:26:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201911291757.xATHv1P1003382@sdf.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, HELO_MISC_IP, LOCAL_FROM, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * 1.1 HELO_MISC_IP Looking for more Dynamic IP Relays X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eg.sd.rdtc.ru X-Rspamd-Queue-Id: 47RBxN3M8Jz4c84 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.68)[ip: (-4.46), ipnet: 2a01:4f8::/29(-2.35), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 04:30:33 -0000 30.11.2019 0:57, Scott Bennett wrote: > On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein > wrote: > >> 28.11.2019 20:34, Steven Hartland wrote: >> >>> It may well depend on the extent of the deletes occurring. >>> >>> Have you tried disabling TRIM to see if it eliminates the delay? >> >> This system used mfi(4) first and mfi(4) does not support TRIM at all. Performance was abysmal. >> Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one then re-added them to RAID1. >> Disabling TRIM is not an option. >> >> Almost a year has passed since then and I suspect SSDs have no or a few spare trimmed cells for some reason. >> Is there documented way to check this out? Maybe some SMART attribute? >> > You neglected to state whether you used "zfs destroy datasetname" or > "zfs destroy -d datasetname". If you used the former, then ZFS did what > you told it to do. If you want the data set destroyed in the background, > you will need to include the "-d" option in the command. (See the zfs(1) > man page at defer_destroy under "Native Properties".) The manual says "zfs destroy -d" is not for "background" but for "deferred". The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs hold) or bound with a clone, but "zfs destroy -d" would mark the snapshot for later destruction in a moment the clone is deleted or user lock (hold) is lifted. Until then the snapshot still usable and destruction does not happen. All my snapshots are free from holds or clones and can be deleted, so "zfs destroy -d" is equal to "zfs destroy" for them. From owner-freebsd-stable@freebsd.org Mon Dec 2 08:23:45 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 901081C9F33 for ; Mon, 2 Dec 2019 08:23:45 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 47RJ6S74PVz4nSK for ; Mon, 2 Dec 2019 08:23:44 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id xB28Nhfm026214 for ; Mon, 2 Dec 2019 09:23:43 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 6349B8EE for ; Mon, 2 Dec 2019 09:23:43 +0100 (CET) From: Harry Schmalzbauer Subject: Re: UEFI ISO boot not working in 12.1 ? To: FreeBSD-STABLE Mailing List References: <20191106191711.GK1177@westeros.distal.com> <20191106210256.GL1177@westeros.distal.com> <1db62ff2-e7df-5bef-7c6d-424f4367370a@freebsd.org> <24bd3c37-e834-9599-acd9-2f4966916eae@freebsd.org> <20191107195325.GO1177@westeros.distal.com> <20191109164233.GB1053@westeros.distal.com> Organization: OmniLAN Message-ID: Date: Mon, 2 Dec 2019 09:23:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------7ED70A944226CF0887322411" Content-Language: en-US X-Greylist: ACL 136 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 02 Dec 2019 09:23:43 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-Rspamd-Queue-Id: 47RJ6S74PVz4nSK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-3.61 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[omnilan.de]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.31)[ip: (-9.19), ipnet: 2a00:e10:2800::/38(-4.56), asn: 61157(2.20), country: DE(-0.01)] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 08:23:45 -0000 This is a multi-part message in MIME format. --------------7ED70A944226CF0887322411 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 09.11.2019 um 18:24 schrieb Kyle Evans: > On Sat, Nov 9, 2019 at 10:42 AM Chris Ross wrote: >> On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote: >>>>> On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer wrote: >>>>>> You could try some bisection back along the 12 branch.. >>> Yeah. I was hoping for an easier path, but. I can try slogging back >>> through stable-12 a month or two at a time. >> Okay. I spent a bunch of time moving around stable-12 by date, and >> an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and >> 2019-10-15 (rev 353541) does not. … >> That helps- thanks! I'm CC'ing tsoome@, as this is basically just >> r353501 in that range. Can you give the latest -CURRENT snapshot boot >> as another data point? I can confirm that reverting r353501 on stable/12 from yesterday solves my problem with booting the setup media. (My symptoms on ESXi 6.7 guest using SATA vODD: r355263 loads kernel/modules but stucks with 100%CPU while trying to hand over to kernel) My svn skills are as lousy as my C skills, but to me it seems like a mismerge. The attached patch (against r355263, stable/12 from yesterday _without_ reverting r353501!) solves my problem. But please could someone familiar with svn&code inspect what happened and verify/correct/commit the fix. Solving my problem doesn't mean my approach is correct.  I don't know HandleProtocol() nor OpenProtocol() nor did I read the code trying to understand what's happening in "proto.c". I just text-edited a obvious cannotbe… Maby I missed a lot of things… In case attachment won't make it to the list (white space nits to be expected): Index: stand/efi/boot1/proto.c =================================================================== --- stand/efi/boot1/proto.c     (Revision 355263) +++ stand/efi/boot1/proto.c     (Arbeitskopie) @@ -61,7 +61,7 @@         int preferred;         /* Figure out if we're dealing with an actual partition. */ -       status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath); +       status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath);         if (status == EFI_UNSUPPORTED)                 return (0); @@ -77,7 +77,7 @@                 efi_free_devpath_name(text);         }  #endif -       status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio); +       status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void **)&blkio);         if (status == EFI_UNSUPPORTED)                 return (0); Index: stand/efi/gptboot/proto.c =================================================================== --- stand/efi/gptboot/proto.c   (Revision 355263) +++ stand/efi/gptboot/proto.c   (Arbeitskopie) @@ -146,7 +146,7 @@         EFI_STATUS status;         /* Figure out if we're dealing with an actual partition. */ -       status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath); +       status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath);         if (status != EFI_SUCCESS)                 return;  #ifdef EFI_DEBUG @@ -169,7 +169,7 @@                         return;                 }         } -       status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio); +       status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void **)&blkio);         if (status != EFI_SUCCESS) {                 DPRINTF("Can't get the block I/O protocol block\n");                 return; But reading this thread leaves one question: Does 12.1-RELEASE refuse to boot on regular ESXi UEFI guests!? Thanks, -Harry (resent due to ?expired? subscription…; original message was addressed to all other recipients) --------------7ED70A944226CF0887322411 Content-Type: text/x-patch; name="efiloader_MFCfix-HandleProtocol2OpenProtocol.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="efiloader_MFCfix-HandleProtocol2OpenProtocol.patch" Index: stand/efi/boot1/proto.c =================================================================== --- stand/efi/boot1/proto.c (Revision 355263) +++ stand/efi/boot1/proto.c (Arbeitskopie) @@ -61,7 +61,7 @@ int preferred; /* Figure out if we're dealing with an actual partition. */ - status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath); + status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath); if (status == EFI_UNSUPPORTED) return (0); @@ -77,7 +77,7 @@ efi_free_devpath_name(text); } #endif - status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio); + status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void **)&blkio); if (status == EFI_UNSUPPORTED) return (0); Index: stand/efi/gptboot/proto.c =================================================================== --- stand/efi/gptboot/proto.c (Revision 355263) +++ stand/efi/gptboot/proto.c (Arbeitskopie) @@ -146,7 +146,7 @@ EFI_STATUS status; /* Figure out if we're dealing with an actual partition. */ - status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath); + status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath); if (status != EFI_SUCCESS) return; #ifdef EFI_DEBUG @@ -169,7 +169,7 @@ return; } } - status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio); + status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void **)&blkio); if (status != EFI_SUCCESS) { DPRINTF("Can't get the block I/O protocol block\n"); return; --------------7ED70A944226CF0887322411-- From owner-freebsd-stable@freebsd.org Mon Dec 2 09:27:55 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 625181CBAE5 for ; Mon, 2 Dec 2019 09:27:55 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RKXQ3BVVz4rZX for ; Mon, 2 Dec 2019 09:27:49 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id xB29Rnfp007499 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Mon, 2 Dec 2019 09:27:49 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id xB29RmLd024059; Mon, 2 Dec 2019 03:27:48 -0600 (CST) From: Scott Bennett Message-Id: <201912020927.xB29RmLd024059@sdf.org> Date: Mon, 02 Dec 2019 03:27:48 -0600 To: eugen@grosbein.net Subject: Re: Slow zfs destroy Cc: freebsd-stable@freebsd.org References: <201911291757.xATHv1P1003382@sdf.org> <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> In-Reply-To: <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RKXQ3BVVz4rZX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bennett@sdf.org has no SPF policy when checking 205.166.94.20) smtp.mailfrom=bennett@sdf.org X-Spamd-Result: default: False [-1.39 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982,0]; FROM_HAS_DN(0.00)[]; IP_SCORE(-0.31)[ip: (-0.99), ipnet: 205.166.94.0/24(-0.49), asn: 14361(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sdf.org]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[20.94.166.205.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 09:27:55 -0000 Eugene Grosbein wrote: > 30.11.2019 0:57, Scott Bennett wrote: > > > On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein > > wrote: > > > >> 28.11.2019 20:34, Steven Hartland wrote: > >> > >>> It may well depend on the extent of the deletes occurring. > >>> > >>> Have you tried disabling TRIM to see if it eliminates the delay? > >> > >> This system used mfi(4) first and mfi(4) does not support TRIM at all. Performance was abysmal. > >> Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one then re-added them to RAID1. > >> Disabling TRIM is not an option. > >> > >> Almost a year has passed since then and I suspect SSDs have no or a few spare trimmed cells for some reason. > >> Is there documented way to check this out? Maybe some SMART attribute? > >> > > You neglected to state whether you used "zfs destroy datasetname" or > > "zfs destroy -d datasetname". If you used the former, then ZFS did what > > you told it to do. If you want the data set destroyed in the background, > > you will need to include the "-d" option in the command. (See the zfs(1) > > man page at defer_destroy under "Native Properties".) > > The manual says "zfs destroy -d" is not for "background" but for "deferred". > The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs hold) > or bound with a clone, but "zfs destroy -d" would mark the snapshot for later destruction > in a moment the clone is deleted or user lock (hold) is lifted. > Until then the snapshot still usable and destruction does not happen. > > All my snapshots are free from holds or clones and can be deleted, > so "zfs destroy -d" is equal to "zfs destroy" for them. > What you say is true, and I have seen it accept a "zfs destroy -d" for a held snapshot but do nothing until the hold is released, whereupon the "destroy" begins. However, that cannot be the whole story because... The vast majority of my "destroy" operations are for snapshots, but what I have seen is that, without the "-d", the command does not return until the disk activity of the "destroy" finishes, but with the "-d", it returns within a couple of seconds,--i.e., just long enough to get the operation going--and the disk I/Os continue until the work is done and free space in the pool increases until the I/Os stop. Perhaps the man pages for zfs(8) and zpool-features(7) need some modification/ clarification on this matter. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@freebsd.org Mon Dec 2 13:51:26 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1E9721AA6E0 for ; Mon, 2 Dec 2019 13:51:26 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RRNY0PyQz3NCW; Mon, 2 Dec 2019 13:51:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB2DlJXA018627 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Dec 2019 13:47:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB2DlGN4005080 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Dec 2019 20:47:16 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Slow zfs destroy To: Andriy Gapon , Scott Bennett References: <201911291757.xATHv1P1003382@sdf.org> <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> <201912020927.xB29RmLd024059@sdf.org> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: Date: Mon, 2 Dec 2019 20:47:14 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, HELO_MISC_IP, LOCAL_FROM, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * 1.1 HELO_MISC_IP Looking for more Dynamic IP Relays X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eg.sd.rdtc.ru X-Rspamd-Queue-Id: 47RRNY0PyQz3NCW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.68)[ip: (-4.47), ipnet: 2a01:4f8::/29(-2.35), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 13:51:26 -0000 02.12.2019 20:35, Andriy Gapon wrote: > On 02/12/2019 11:27, Scott Bennett wrote: >> The vast majority of my "destroy" operations are for snapshots, but what >> I have seen is that, without the "-d", the command does not return until the >> disk activity of the "destroy" finishes, but with the "-d", it returns within >> a couple of seconds,--i.e., just long enough to get the operation going--and >> the disk I/Os continue until the work is done and free space in the pool increases >> until the I/Os stop. >> Perhaps the man pages for zfs(8) and zpool-features(7) need some modification/ >> clarification on this matter. > > I don't know how to explain what you see, but the manual pages are correct. > -d has nothing to do with asynchronous destroy which is automatic (when enabled). It seems that "zfs destroy" writes and/or removes large enough amount of data to spend lots of time before return when TRIM performance is bad. From owner-freebsd-stable@freebsd.org Mon Dec 2 15:21:08 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 586101ACF98 for ; Mon, 2 Dec 2019 15:21:08 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) (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 47RTN25Jpzz3xkC for ; Mon, 2 Dec 2019 15:21:06 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ibnVX-0007uf-Rq for freebsd-stable@freebsd.org; Mon, 02 Dec 2019 16:21:03 +0100 Received: from 94-209-85-88.cable.dynamic.v4.ziggo.nl ([94.209.85.88] helo=wan0.bsd4all.org) by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1) (envelope-from ) id 1ibnVX-0006qy-OB for freebsd-stable@freebsd.org; Mon, 02 Dec 2019 16:21:03 +0100 Received: from newnas.bsd4all.local (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 212DC381 for ; Mon, 2 Dec 2019 16:21:03 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas.bsd4all.local (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haU7ADvZ8poa for ; Mon, 2 Dec 2019 16:21:02 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 6782E187 for ; Mon, 2 Dec 2019 16:21:02 +0100 (CET) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: rev 355285 breaks stable build Message-Id: <470A370C-362E-4F29-BC55-2047D4C48A4E@bsd4all.org> Date: Mon, 2 Dec 2019 16:21:01 +0100 To: FreeBSD Stable X-Mailer: Apple Mail (2.3445.104.11) X-SourceIP: 94.209.85.88 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=eLFtc0h1 c=1 sm=1 tr=0 a=LYXyOGYQqFYBMgK+Y6iqTg==:17 a=kj9zAlcOel0A:10 a=pxVhFHJ0LMsA:10 a=LoJ2hHBQqNtKeWQz50oA:9 a=CjuIK1q_8ugA:10 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: 47RTN25Jpzz3xkC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.168 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-3.23 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsd4all.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.33)[ipnet: 212.54.32.0/20(-4.11), asn: 33915(-2.56), country: NL(0.02)]; TO_DN_ALL(0.00)[]; FROM_NO_DN(0.00)[]; MV_CASE(0.50)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[168.42.54.212.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[88.85.209.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 15:21:08 -0000 Hi, While building rescue ld: error: undefined symbol: lz4_init >>> referenced by spa_misc.c:2066 = (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066) >>> spa_misc.o:(spa_init) in archive = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a ld: error: undefined symbol: lz4_fini >>> referenced by spa_misc.c:2096 = (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096) >>> spa_misc.o:(spa_fini) in archive = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** [rescue] Error code 1 Peter= From owner-freebsd-stable@freebsd.org Mon Dec 2 15:47:23 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8F70B1ADECC for ; Mon, 2 Dec 2019 15:47:23 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) (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 47RTyL2fvMz40rD for ; Mon, 2 Dec 2019 15:47:21 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.135] (helo=smtp11.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ibnuy-00071b-75 for freebsd-stable@freebsd.org; Mon, 02 Dec 2019 16:47:20 +0100 Received: from 94-209-85-88.cable.dynamic.v4.ziggo.nl ([94.209.85.88] helo=wan0.bsd4all.org) by smtp11.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1) (envelope-from ) id 1ibntt-0005pF-Az for freebsd-stable@freebsd.org; Mon, 02 Dec 2019 16:46:13 +0100 Received: from newnas.bsd4all.local (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id D9C122AF for ; Mon, 2 Dec 2019 16:46:12 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas.bsd4all.local (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0MYHPp1JyeC for ; Mon, 2 Dec 2019 16:46:11 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 5F578193 for ; Mon, 2 Dec 2019 16:46:11 +0100 (CET) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: rev 355285 breaks stable build Date: Mon, 2 Dec 2019 16:46:10 +0100 References: <470A370C-362E-4F29-BC55-2047D4C48A4E@bsd4all.org> To: FreeBSD Stable In-Reply-To: <470A370C-362E-4F29-BC55-2047D4C48A4E@bsd4all.org> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-SourceIP: 94.209.85.88 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=Gok8BX9C c=1 sm=1 tr=0 a=LYXyOGYQqFYBMgK+Y6iqTg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=pxVhFHJ0LMsA:10 a=6Q3WNqvRAAAA:8 a=6I5d2MoRAAAA:8 a=64klGiIqmbtlkf3wEzcA:9 a=CjuIK1q_8ugA:10 a=I8PBwKCn76L9oNdl0isp:22 a=IjZwj45LgO3ly-622nXo:22 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: 47RTyL2fvMz40rD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.164 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-3.21 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[88.85.209.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsd4all.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.32)[ipnet: 212.54.32.0/20(-4.07), asn: 33915(-2.53), country: NL(0.02)]; TO_DN_ALL(0.00)[]; FROM_NO_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_IN_DNSWL_LOW(-0.10)[164.42.54.212.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 15:47:23 -0000 Fixed by rev. 355290 > On 2 Dec 2019, at 16:21, peter.blok@bsd4all.org wrote: >=20 > Hi, >=20 > While building rescue >=20 > ld: error: undefined symbol: lz4_init >>>> referenced by spa_misc.c:2066 = (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066) >>>> spa_misc.o:(spa_init) in archive = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a >=20 > ld: error: undefined symbol: lz4_fini >>>> referenced by spa_misc.c:2096 = (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096) >>>> spa_misc.o:(spa_fini) in archive = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a > cc: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [rescue] Error code 1 >=20 > Peter > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Mon Dec 2 20:13:29 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B71BB1B5C1F for ; Mon, 2 Dec 2019 20:13:29 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RbsN4lzcz4JVk for ; Mon, 2 Dec 2019 20:13:25 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id xB2KD4pM031648 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 2 Dec 2019 21:13:05 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id xB2KD4s2031647 for freebsd-stable@FreeBSD.ORG; Mon, 2 Dec 2019 21:13:04 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id xB2JuGUU031835 for ; Mon, 2 Dec 2019 20:56:16 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id xB2Js0Mx031351 for ; Mon, 2 Dec 2019 20:54:02 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id xB2Js0B0031350 for freebsd-stable@FreeBSD.ORG; Mon, 2 Dec 2019 20:54:00 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: wrong value from DTRACE (uint32 for int64) Date: Mon, 02 Dec 2019 20:44:59 +0100 Organization: n/a Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="29371"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Opera Mail/12.16 (FreeBSD) Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [185.220.148.12]); Mon, 02 Dec 2019 21:13:07 +0100 (CET) X-Rspamd-Queue-Id: 47RbsN4lzcz4JVk X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org has no SPF policy when checking 2001:1440:5001:1::2) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org X-Spamd-Result: default: False [4.42 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(0.80)[0.796,0]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.43)[ip: (1.13), ipnet: 2001:1440::/32(0.56), asn: 8469(0.45), country: DE(-0.01)]; NEURAL_SPAM_LONG(1.00)[0.995,0]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; DMARC_NA(0.00)[sub.org]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:8469, ipnet:2001:1440::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 20:13:29 -0000 Hi @all, I felt the need to look into my ZFS ARC, but DTRACE provided misleading (i.e., wrong) output (on i386, 11.3-RELEASE): # dtrace -Sn 'arc-available_memory { printf("%x %x", arg0, arg1); }' DIFO 0x286450a0 returns D type (integer) (size 8) OFF OPCODE INSTRUCTION 00: 29010601 ldgs DT_VAR(262), %r1 ! DT_VAR(262) = "arg0" 01: 23000001 ret %r1 NAME ID KND SCP FLAG TYPE arg0 262 scl glb r D type (integer) (size 8) DIFO 0x286450f0 returns D type (integer) (size 8) OFF OPCODE INSTRUCTION 00: 29010701 ldgs DT_VAR(263), %r1 ! DT_VAR(263) = "arg1" 01: 23000001 ret %r1 NAME ID KND SCP FLAG TYPE arg1 263 scl glb r D type (integer) (size 8) dtrace: description 'arc-available_memory ' matched 1 probe 0 14 none:arc-available_memory 2fb000 2 0 14 none:arc-available_memory 4e000 2 1 14 none:arc-available_memory ffffb000 2 1 14 none:arc-available_memory ffffb000 2 1 14 none:arc-available_memory ffffb000 2 1 14 none:arc-available_memory 19000 2 0 14 none:arc-available_memory d38000 2 # dtrace -n 'arc-available_memory { printf("%d %d", arg0, arg1); }' 1 14 none:arc-available_memory 81920 5 1 14 none:arc-available_memory 69632 5 1 14 none:arc-available_memory 4294955008 5 1 14 none:arc-available_memory 4294955008 5 The arg0 Variable is shown here obviousely as an unsigned int32 value. But in fact, the probe in the sourcecode in arc.c is a signed int64: DTRACE_PROBE2(arc__available_memory, int64_t, lowest, int, r); User @shkhin in the forum pointed me to check the bare dtrace program, unattached to the kernel code: https://forums.freebsd.org/threads/dtrace-treats-int64_t-as-uint32_t-on-i386.73223/post-446517 And there everything appears correct. So two questions: 1. can anybody check and confirm this happening? 2. any idea what could be wrong here? (The respective variable in arc.c bears the correct 64bit negative value, I checked that - and otherwise the ARC couldn't shrink.) rgds, PMc From owner-freebsd-stable@freebsd.org Mon Dec 2 20:58:41 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 050BA1B70BF for ; Mon, 2 Dec 2019 20:58:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RcsX0tSyz4MHp for ; Mon, 2 Dec 2019 20:58:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x841.google.com with SMTP id k11so1294912qtm.3 for ; Mon, 02 Dec 2019 12:58:39 -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=nANP2Xm7AI8nFhDH9aN5C8mBc0CROAOc8ySVraP7P3U=; b=jwj/+7tMVZzBsFEj/xk0ggKzhK6YObDrYSm8nd0oSSrri/H7C4quIO6cby/ST9928m zMK5zmaRgymKbjl4BCrS7aW45fXc6we7Mg9RwZgF5mOl7RRfPBGbeuKXh6h7U1YtWBLK U73Ev1MTdiTxkrhLJsv5pRHEoB97RFGCeNjJFyUpCBI9Mn7G405nhCe6vPdiC9XRKAJR EBxPME91lcleilGerXpP6KkcNvTL3mH4KDAMbfIJRgxWayrbWJcZMANQylcT6zL5rCtM 0sV02wU2a8BQOGj2tTXcS4brYMxcdxk5NL9qCzbCFr6lV+gcQJM/lCaAh+gNPs4IjRgz XQ6Q== 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=nANP2Xm7AI8nFhDH9aN5C8mBc0CROAOc8ySVraP7P3U=; b=oYeh2bQYgMCqYP6OCtsIr/WNoREbZ91lK87gWGon2+a0jDDFVQcvFAAQ+oYz5vmipH MXrrgcnu8viiPW/yo5+XUBUGV4zr7j4ZLPL5N+vPMYj03rLhVn/oOTR49bc69l+XYHLR XgyAO4fT3xdHAiYe5Xjs3UDRGJBdhJ9IvMV2OgCwb2UZtqgDcWwxiNpZDqL/i3YHXGdN cW4AVreOULcEFVn3kny7ykHfz+amDnriVpqfOe9UQt8WaOhFgd2eef46FofAAs8Ggaem 4epTOcoS8cdcQTRm9kzs+f4jNp1exdsxlDx0AAoWjCHS/lqzp6e50tsjjOdI4Gt7Ou6A qYjQ== X-Gm-Message-State: APjAAAUZ3DNQn7JDMm3tfD7/p9ZQUT3oZ7RkaHD8PRfbqjZ2j9oLoa/l eypSOeUClb/r/yUmQy5wNvULVmscEPg= X-Google-Smtp-Source: APXvYqy3vUCHwYM0ODEiCD3Pnx5nwgDVWSNdK8g5KqJavSYmXKE78jB3p+PX7PlxQbyLkUuOu7f9Vw== X-Received: by 2002:aed:2f26:: with SMTP id l35mr1566099qtd.162.1575320318804; Mon, 02 Dec 2019 12:58:38 -0800 (PST) Received: from raichu (toroon0560w-lp130-05-69-158-183-252.dsl.bell.ca. [69.158.183.252]) by smtp.gmail.com with ESMTPSA id s63sm410068qkf.129.2019.12.02.12.58.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2019 12:58:38 -0800 (PST) Sender: Mark Johnston Date: Mon, 2 Dec 2019 15:58:36 -0500 From: Mark Johnston To: Peter Cc: freebsd-stable@freebsd.org Subject: Re: wrong value from DTRACE (uint32 for int64) Message-ID: <20191202205836.GF43802@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47RcsX0tSyz4MHp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jwj/+7tM; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::841 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.36)[ip: (2.43), ipnet: 2607:f8b0::/32(-2.24), asn: 15169(-1.94), country: US(-0.05)]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 20:58:41 -0000 On Mon, Dec 02, 2019 at 08:44:59PM +0100, Peter wrote: > Hi @all, > > I felt the need to look into my ZFS ARC, but DTRACE provided misleading > (i.e., wrong) output (on i386, 11.3-RELEASE): > > # dtrace -Sn 'arc-available_memory { printf("%x %x", arg0, arg1); }' > DIFO 0x286450a0 returns D type (integer) (size 8) > OFF OPCODE INSTRUCTION > 00: 29010601 ldgs DT_VAR(262), %r1 ! DT_VAR(262) = "arg0" > 01: 23000001 ret %r1 > > NAME ID KND SCP FLAG TYPE > arg0 262 scl glb r D type (integer) (size 8) > > DIFO 0x286450f0 returns D type (integer) (size 8) > OFF OPCODE INSTRUCTION > 00: 29010701 ldgs DT_VAR(263), %r1 ! DT_VAR(263) = "arg1" > 01: 23000001 ret %r1 > > NAME ID KND SCP FLAG TYPE > arg1 263 scl glb r D type (integer) (size 8) > dtrace: description 'arc-available_memory ' matched 1 probe > 0 14 none:arc-available_memory 2fb000 2 > 0 14 none:arc-available_memory 4e000 2 > 1 14 none:arc-available_memory ffffb000 2 > 1 14 none:arc-available_memory ffffb000 2 > 1 14 none:arc-available_memory ffffb000 2 > 1 14 none:arc-available_memory 19000 2 > 0 14 none:arc-available_memory d38000 2 > > # dtrace -n 'arc-available_memory { printf("%d %d", arg0, arg1); }' > 1 14 none:arc-available_memory 81920 5 > 1 14 none:arc-available_memory 69632 5 > 1 14 none:arc-available_memory 4294955008 5 > 1 14 none:arc-available_memory 4294955008 5 > > > The arg0 Variable is shown here obviousely as an unsigned int32 value. But > in fact, the probe in the sourcecode in arc.c is a signed int64: > > DTRACE_PROBE2(arc__available_memory, int64_t, lowest, int, r); > > > User @shkhin in the forum pointed me to check the bare dtrace program, > unattached to the kernel code: > https://forums.freebsd.org/threads/dtrace-treats-int64_t-as-uint32_t-on-i386.73223/post-446517 > > And there everything appears correct. > > So two questions: > 1. can anybody check and confirm this happening? > 2. any idea what could be wrong here? (The respective variable in arc.c > bears the correct 64bit negative value, I checked that - and otherwise the > ARC couldn't shrink.) The DTRACE_PROBE* macros cast their parameters to uintptr_t, which will be 32 bits wide on i386. You might be able to work around the problem by casting arg0 to uint32_t in the script. From owner-freebsd-stable@freebsd.org Mon Dec 2 21:02:47 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 94B3D1B769A; Mon, 2 Dec 2019 21:02:47 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RcyH3T4Sz4N9p; Mon, 2 Dec 2019 21:02:47 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 56B691D75D; Mon, 2 Dec 2019 21:02:47 +0000 (UTC) Date: Mon, 2 Dec 2019 21:02:47 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-11-17 Message-ID: <20191202210247.GA20097@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:02:47 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-11-17 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-11 to 2019-11-17. During this period, we have: * 2174 builds (91.2% (-3.7) passed, 8.8% (+3.7) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 331 test runs (97.9% (+5.8) passed, 2.1% (-4.3) unstable, 0% (-1.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc builds (100% passed) Test case status (on 2019-11-17 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7611 (0) | 7546 (+3) | 0 (0) | 65 (-3) | | head/i386 | 7609 (0) | 7537 (-3) | 0 (0) | 72 (+3) | | 12-STABLE/amd64 | 7483 (0) | 7435 (0) | 0 (0) | 48 (0) | | 12-STABLE/i386 | 7481 (0) | 7423 (-3) | 0 (0) | 58 (+3) | | 11-STABLE/amd64 | 6853 (+4) | 6806 (+4) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6851 (+4) | 6799 (+1) | 0 (0) | 52 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191117 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-testing@FreeBSD.org and lwhsu@FreeBSD.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~7 failing and ~100 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Mon Dec 2 21:03:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4EDE81B7A4F; Mon, 2 Dec 2019 21:03:56 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rczc15rCz4NdC; Mon, 2 Dec 2019 21:03:56 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 04C741D9FC; Mon, 2 Dec 2019 21:03:55 +0000 (UTC) Date: Mon, 2 Dec 2019 21:03:55 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-11-24 Message-ID: <20191202210355.GB20097@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:03:56 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-11-24 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-18 to 2019-11-24. During this period, we have: * 2617 builds (95.1% (+3.9) passed, 4.9% (-3.9) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 349 test runs (83.1% (-14.8) passed, 8.9% (-6.8) unstable, 8.0% (+8) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 48 doc builds (100% (0) passed) Test case status (on 2019-11-24 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7618 (+7) | 7552 (+6) | 0 (0) | 66 (+1) | | head/i386 | 7616 (+7) | 7546 (+9) | 0 (0) | 70 (-2) | | 12-STABLE/amd64 | 7483 (0) | 7435 (0) | 0 (0) | 48 (0) | | 12-STABLE/i386 | 7481 (0) | 7426 (+3) | 0 (0) | 55 (-3) | | 11-STABLE/amd64 | 6853 (0) | 6803 (-3) | 0 (0) | 50 (+3) | | 11-STABLE/i386 | 6851 (0) | 6799 (0) | 0 (0) | 52 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191124 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-testing@FreeBSD.org and lwhsu@FreeBSD.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## Fixed tests * https://bugs.freebsd.org/242095 failing test case: usr.bin.unifdef.basic_test.basic ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~100 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Mon Dec 2 21:04:57 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BE101B7D84; Mon, 2 Dec 2019 21:04:57 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Rd0m6ZnNz4NwJ; Mon, 2 Dec 2019 21:04:56 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id C123F1DB32; Mon, 2 Dec 2019 21:04:56 +0000 (UTC) Date: Mon, 2 Dec 2019 21:04:56 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-12-01 Message-ID: <20191202210456.GC20097@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:04:57 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-12-01 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-25 to 2019-12-01. During this period, we have: * 2134 builds (96.3% (+1.2) passed, 3.7% (-1.2) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 283 test runs (97.5% (+14.4) passed, 2.5% (-6.4) unstable, 0% (-8) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 22 doc builds (100% (0) passed) Test case status (on 2019-12-01 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7620 (+2) | 7554 (+2) | 0 (0) | 66 (0) | | head/i386 | 7618 (+2) | 7548 (+2) | 0 (0) | 70 (0) | | 12-STABLE/amd64 | 7483 (0) | 7432 (-3) | 0 (0) | 51 (+3) | | 12-STABLE/i386 | 7481 (0) | 7426 (0) | 0 (0) | 55 (0) | | 11-STABLE/amd64 | 6853 (0) | 6806 (+3) | 0 (0) | 47 (-3) | | 11-STABLE/i386 | 6851 (0) | 6802 (+3) | 0 (0) | 49 (-3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191201 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-testing@FreeBSD.org and lwhsu@FreeBSD.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~14 failing and ~100 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Tue Dec 3 00:13:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED2491BD12A for ; Tue, 3 Dec 2019 00:13:31 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RjBL4W3bz4ZVD for ; Tue, 3 Dec 2019 00:13:29 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id xB30D4Xv043853 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 3 Dec 2019 01:13:05 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id xB30D4m9043852 for freebsd-stable@FreeBSD.ORG; Tue, 3 Dec 2019 01:13:04 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id xB2NtLPN033268 for ; Tue, 3 Dec 2019 00:55:21 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id xB2Ns4Wu033047 for ; Tue, 3 Dec 2019 00:54:05 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id xB2Ns3uj033044 for freebsd-stable@FreeBSD.ORG; Tue, 3 Dec 2019 00:54:03 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: wrong value from DTRACE (uint32 for int64) Date: Tue, 03 Dec 2019 00:41:48 +0100 Organization: n/a Message-ID: References: <20191202205836.GF43802@raichu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="30381"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Opera Mail/12.16 (FreeBSD) Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [185.220.148.12]); Tue, 03 Dec 2019 01:13:08 +0100 (CET) X-Rspamd-Queue-Id: 47RjBL4W3bz4ZVD X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org has no SPF policy when checking 2001:1440:5001:1::2) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org X-Spamd-Result: default: False [4.16 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.623,0]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.36)[ip: (0.97), ipnet: 2001:1440::/32(0.48), asn: 8469(0.39), country: DE(-0.01)]; NEURAL_SPAM_LONG(0.97)[0.972,0]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; DMARC_NA(0.00)[sub.org]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:8469, ipnet:2001:1440::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 00:13:32 -0000 On Mon, 02 Dec 2019 21:58:36 +0100, Mark Johnston wrote: > The DTRACE_PROBE* macros cast their parameters to uintptr_t, which > will be 32 bits wide on i386. You might be able to work around the > problem by casting arg0 to uint32_t in the script. Thanks for the info - good that it has a logical explanation. From owner-freebsd-stable@freebsd.org Tue Dec 3 10:47:44 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C1B11A9798 for ; Tue, 3 Dec 2019 10:47:44 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) (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 47RzG64wmBz4FBY for ; Tue, 3 Dec 2019 10:47:42 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.135] (helo=smtp11.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ic5iV-0005v0-Pk for freebsd-stable@freebsd.org; Tue, 03 Dec 2019 11:47:39 +0100 Received: from 94-209-85-88.cable.dynamic.v4.ziggo.nl ([94.209.85.88] helo=wan0.bsd4all.org) by smtp11.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1) (envelope-from ) id 1ic5iV-0003PO-Lx for freebsd-stable@freebsd.org; Tue, 03 Dec 2019 11:47:39 +0100 Received: from newnas.bsd4all.local (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id EC394385 for ; Tue, 3 Dec 2019 11:47:38 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas.bsd4all.local (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iezFt3-VPTCm for ; Tue, 3 Dec 2019 11:47:38 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 79A8A98 for ; Tue, 3 Dec 2019 11:47:38 +0100 (CET) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: panic when stopping jails Message-Id: <74BFA719-C09A-47C7-89F9-B7F9DF6B1EF7@bsd4all.org> Date: Tue, 3 Dec 2019 11:47:37 +0100 To: FreeBSD Stable X-Mailer: Apple Mail (2.3445.104.11) X-SourceIP: 94.209.85.88 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=Gok8BX9C c=1 sm=1 tr=0 a=LYXyOGYQqFYBMgK+Y6iqTg==:17 a=IkcTkHD0fZMA:10 a=pxVhFHJ0LMsA:10 a=ESh1R9CXuiyo8G3Zs9UA:9 a=QEXdDO2ut3YA:10 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: 47RzG64wmBz4FBY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.168 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsd4all.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.30)[ipnet: 212.54.32.0/20(-4.03), asn: 33915(-2.50), country: NL(0.02)]; TO_DN_ALL(0.00)[]; FROM_NO_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[168.42.54.212.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[88.85.209.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 10:47:44 -0000 Hi, I=E2=80=99m getting the following panic when stopping jais. When = ifunit_ref iterates over the VNET ifnet=E2=80=99s it gets a bad ifp. = I=E2=80=99m using netgrapg bridge=E2=80=99s. Any pointers how to debug are welcome. Crash dump is available. Peter Fatal trap 9: general protection fault while in kernel mode cpuid =3D 3; apic id =3D 03 instruction pointer =3D 0x20:0xffffffff807377c5 stack pointer =3D 0x28:0xfffffe00d1e90870 frame pointer =3D 0x28:0xfffffe00d1e90870 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 8537 (ifconfig) trap number =3D 9 panic: general protection fault cpuid =3D 3 time =3D 1575297301 KDB: stack backtrace: #0 0xffffffff8069a8d7 at kdb_backtrace+0x67 #1 0xffffffff8064ec6d at vpanic+0x19d #2 0xffffffff8064eac3 at panic+0x43 #3 0xffffffff809e450c at trap_fatal+0x39c #4 0xffffffff809e395a at trap+0x6a #5 0xffffffff809be97c at calltrap+0x8 #6 0xffffffff80750ff1 at ifunit_ref+0x51 #7 0xffffffff8075328c at ifioctl+0x47c #8 0xffffffff806b8b2e at kern_ioctl+0x2be #9 0xffffffff806b87fd at sys_ioctl+0x15d #10 0xffffffff809e50a2 at amd64_syscall+0x362 #11 0xffffffff809bf2b0 at fast_syscall_common+0x101= From owner-freebsd-stable@freebsd.org Tue Dec 3 10:57:49 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 735C11A9BBD for ; Tue, 3 Dec 2019 10:57:49 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) (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 47RzTm1JhMz4Ffq for ; Tue, 3 Dec 2019 10:57:47 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.135] (helo=smtp11.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ic5sI-0002Pb-D4 for freebsd-stable@freebsd.org; Tue, 03 Dec 2019 11:57:46 +0100 Received: from 94-209-85-88.cable.dynamic.v4.ziggo.nl ([94.209.85.88] helo=wan0.bsd4all.org) by smtp11.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1) (envelope-from ) id 1ic5sI-0001ef-8m for freebsd-stable@freebsd.org; Tue, 03 Dec 2019 11:57:46 +0100 Received: from newnas.bsd4all.local (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 1275E386 for ; Tue, 3 Dec 2019 11:57:46 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas.bsd4all.local (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NijHZMLD1nEf for ; Tue, 3 Dec 2019 11:57:43 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 9D17B19C for ; Tue, 3 Dec 2019 11:57:43 +0100 (CET) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: panic when stopping jails Date: Tue, 3 Dec 2019 11:57:41 +0100 References: <74BFA719-C09A-47C7-89F9-B7F9DF6B1EF7@bsd4all.org> To: FreeBSD Stable In-Reply-To: <74BFA719-C09A-47C7-89F9-B7F9DF6B1EF7@bsd4all.org> Message-Id: <1D8CFDE4-D146-4275-8253-D48BE441B58A@bsd4all.org> X-Mailer: Apple Mail (2.3445.104.11) X-SourceIP: 94.209.85.88 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=Gok8BX9C c=1 sm=1 tr=0 a=LYXyOGYQqFYBMgK+Y6iqTg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=pxVhFHJ0LMsA:10 a=6Q3WNqvRAAAA:8 a=6I5d2MoRAAAA:8 a=-Og-5rvwwDLcdhRCQvwA:9 a=QEXdDO2ut3YA:10 a=I8PBwKCn76L9oNdl0isp:22 a=IjZwj45LgO3ly-622nXo:22 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: 47RzTm1JhMz4Ffq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.164 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-4.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[88.85.209.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsd4all.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.63)[ip: (-6.71), ipnet: 212.54.32.0/20(-3.99), asn: 33915(-2.48), country: NL(0.02)]; TO_DN_ALL(0.00)[]; FROM_NO_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[164.42.54.212.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 10:57:49 -0000 Forgot to mention that it is a very recent 12-STABLE and I don=E2=80=99t = suspect any recent commits. It is just that jails are now stopped more = often. > On 3 Dec 2019, at 11:47, peter.blok@bsd4all.org wrote: >=20 > Hi, >=20 > I=E2=80=99m getting the following panic when stopping jais. When = ifunit_ref iterates over the VNET ifnet=E2=80=99s it gets a bad ifp. = I=E2=80=99m using netgrapg bridge=E2=80=99s. >=20 > Any pointers how to debug are welcome. Crash dump is available. >=20 > Peter >=20 >=20 > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 3; apic id =3D 03 > instruction pointer =3D 0x20:0xffffffff807377c5 > stack pointer =3D 0x28:0xfffffe00d1e90870 > frame pointer =3D 0x28:0xfffffe00d1e90870 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 8537 (ifconfig) > trap number =3D 9 > panic: general protection fault > cpuid =3D 3 > time =3D 1575297301 > KDB: stack backtrace: > #0 0xffffffff8069a8d7 at kdb_backtrace+0x67 > #1 0xffffffff8064ec6d at vpanic+0x19d > #2 0xffffffff8064eac3 at panic+0x43 > #3 0xffffffff809e450c at trap_fatal+0x39c > #4 0xffffffff809e395a at trap+0x6a > #5 0xffffffff809be97c at calltrap+0x8 > #6 0xffffffff80750ff1 at ifunit_ref+0x51 > #7 0xffffffff8075328c at ifioctl+0x47c > #8 0xffffffff806b8b2e at kern_ioctl+0x2be > #9 0xffffffff806b87fd at sys_ioctl+0x15d > #10 0xffffffff809e50a2 at amd64_syscall+0x362 > #11 0xffffffff809bf2b0 at fast_syscall_common+0x101 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Wed Dec 4 04:39:10 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1190F1C8DF6 for ; Wed, 4 Dec 2019 04:39:10 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail02.asahi-net.or.jp (mail02.asahi-net.or.jp [202.224.55.14]) by mx1.freebsd.org (Postfix) with ESMTP id 47SR2M0h75z4NbN for ; Wed, 4 Dec 2019 04:39:06 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from rv515.advok.com (cpe-184-152-96-96.nj.res.rr.com [184.152.96.96]) (Authenticated sender: NR2Y-OOT) by mail02.asahi-net.or.jp (Postfix) with ESMTPSA id 15DA9928A4 for ; Wed, 4 Dec 2019 13:39:01 +0900 (JST) Date: Tue, 3 Dec 2019 23:38:52 -0500 From: Yoshihiro Ota To: freebsd-stable Subject: "dhclient: send_packet: No buffer space available" Message-Id: <20191203233852.f03c3d5ff2c6ad9a31ed44e9@j.email.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i386-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47SR2M0h75z4NbN X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 202.224.55.14 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp X-Spamd-Result: default: False [2.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:202.224.55.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[email.ne.jp]; NEURAL_SPAM_MEDIUM(0.38)[0.377,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(1.06)[ip: (1.04), ipnet: 202.224.32.0/19(0.30), asn: 4685(3.93), country: JP(0.02)]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.39)[0.395,0]; MV_CASE(0.50)[]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[14.55.224.202.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.96.152.184.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 04:39:10 -0000 Hi, I recently switched internet service provider and got much faster connection. However, I started seeing some unstable connections between the WiFi router and FreeBSD. I was on FreeBSD 12.0-RELEASE and switched to 12.1-RELEASE. Both versions have same symptoms. I get "dhclient: send_packet: No buffer space available" to console and then I frequently lose connection after seeing it. After taking the wlan down and re-connect it with wpa_supplicant, I usually get a connection back. On the side note, I also see these outputs to console and syslog: ath0: bb hang detected (0x4), resetting ath0: ath_legacy_rx_tasklet: sc_inreset_cnt > 0; skipping Does anyone have any advice how to fix/work-around or where to start looking: ath driver, dhclinet, kernel, wlan, and/or wpa_supplicant? Thanks, Hiro From owner-freebsd-stable@freebsd.org Wed Dec 4 17:56:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 647E21AA121 for ; Wed, 4 Dec 2019 17:56:56 +0000 (UTC) (envelope-from walterp@gmail.com) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Smkv3Ql8z49B6 for ; Wed, 4 Dec 2019 17:56:55 +0000 (UTC) (envelope-from walterp@gmail.com) Received: by mail-io1-xd2b.google.com with SMTP id v18so589859iol.2 for ; Wed, 04 Dec 2019 09:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kZga++Qi+S/7iXP0X+esEoq40aNJRysnEs+phfyMtU4=; b=A4HJGLX4yzFMbHRnBqSyw5yN8GICjoSjaNSRAepVt3wKkmV11Yd/79p/nHyHIRiV5Q n53CQ5C1GkEC/QLp2Jx09vlKIUEN6ZE23H0Pu0LUR2FPWvDeBq7Ur9QarGNfATg+tPQb z4Qg03u2OPKXElF1TFv1mJhHtiFzVRSXZd20IiS+pqpD0vAbWIKPVahbFXsy2aWrbwL4 4zVNFQdCnC6KG2dG+iGhEwMbaUjB5qB/waPjWfBh/DZmTiOxOPpMKvsCf0BNsxLsH5iZ XM7xQiux/N7i3JQ9dW5Xh749hsnPRYdSHJAk0JmxPwCx9vXatuMfySwmnFkxTe5N/8wW 51tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kZga++Qi+S/7iXP0X+esEoq40aNJRysnEs+phfyMtU4=; b=np2KmwuAis+/kVGE0XmQcuoYtBjP+89Q3ePYifWJwnVkShT2IMOTGfB0WgWubg1rLD JE37Uk3l8v70NW+eZgXGVZx//1BTv5F61/AbYpi/Xp365G9CifXa7pbpyZS4Qmay60wt NKQiJlxTtSZvGHpd4REQxVjwA47rqB3Va5i/gBwOoLBStLi4YiB4c7RoJw9cdta2L5oE zsiNmaDarZ4dLgyNkfvW/o/BOoVTjpuBIFWNGYE/Tuztt/ZWuV5MPehNf+s8lRUvhHpM z5AzV+vLqc9q5O0UnzHrYgwy789CfYoj5UZL2DP7QIGN4soyX8hbSAJCtCz5LOFF/rPb bnGw== X-Gm-Message-State: APjAAAXRoiWNSNjNgEkM8BTONG87sKjUduaV7mrvpL6XwszKVEATpiI4 +jK+CxPAGzJuCcXZ1wn2GbwonM3yehqFzlznm/1+FZU4 X-Google-Smtp-Source: APXvYqwJVzDodfcFZg5PU3uRl94llcHkvqjLisE3F0LUiSydz3V803MBvfzT+NP9tqUxu2xevbfmH0JfDmcmtt9gAmQ= X-Received: by 2002:a5e:9246:: with SMTP id z6mr3230402iop.232.1575482213720; Wed, 04 Dec 2019 09:56:53 -0800 (PST) MIME-Version: 1.0 References: <20191203233852.f03c3d5ff2c6ad9a31ed44e9@j.email.ne.jp> In-Reply-To: <20191203233852.f03c3d5ff2c6ad9a31ed44e9@j.email.ne.jp> From: Walter Parker Date: Wed, 4 Dec 2019 09:56:44 -0800 Message-ID: Subject: Re: "dhclient: send_packet: No buffer space available" To: freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47Smkv3Ql8z49B6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=A4HJGLX4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of walterp@gmail.com designates 2607:f8b0:4864:20::d2b as permitted sender) smtp.mailfrom=walterp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-5.86), ipnet: 2607:f8b0::/32(-2.23), asn: 15169(-1.93), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[b.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 17:56:56 -0000 On Tue, Dec 3, 2019 at 8:39 PM Yoshihiro Ota wrote: > > Hi, > > I recently switched internet service provider and got much faster connection. > However, I started seeing some unstable connections between the WiFi router and FreeBSD. > I was on FreeBSD 12.0-RELEASE and switched to 12.1-RELEASE. > Both versions have same symptoms. > > I get "dhclient: send_packet: No buffer space available" to console and then I frequently lose connection after seeing it. > After taking the wlan down and re-connect it with wpa_supplicant, I usually get a connection back. > > On the side note, I also see these outputs to console and syslog: > ath0: bb hang detected (0x4), resetting > ath0: ath_legacy_rx_tasklet: sc_inreset_cnt > 0; skipping > > Does anyone have any advice how to fix/work-around or where to start looking: ath driver, dhclinet, kernel, wlan, and/or wpa_supplicant? > > Thanks, > Hiro > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" IIRC, that means that you are running out of mbufs. There are two ways to fix it, increase the number of mbufs (kern.ipc.nmbufs or kern.ipc.nmbclusters), or increase the aggressiveness of closing old network connections (I do this from a menu in pfSense, so I don't remember the command line setting name off hand). Searching for the error online suggests that this error can also be caused if the layer 2 network connection failed, such as a wlan association failure. Or that there is a network filter somewhere that is sinking/blocking packets and that this is causing the mbuf queue to fill up (every network request requires an mbuf). In the past, people have also fixed this by swapping the network hardware. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis From owner-freebsd-stable@freebsd.org Fri Dec 6 05:25:46 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDB9A1B999D for ; Fri, 6 Dec 2019 05:25:46 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [150.101.137.136]) by mx1.freebsd.org (Postfix) with ESMTP id 47TgzD30Ttz42c2 for ; Fri, 6 Dec 2019 05:25:43 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp14-2-112-104.adl-apt-pir-bras32.tpg.internode.on.net (HELO midget.dons.net.au) ([14.2.112.104]) by ipmail01.adl6.internode.on.net with ESMTP; 06 Dec 2019 15:54:10 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id xB65NtgP027003 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 6 Dec 2019 15:54:05 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id xB65LA5N026838 for ; Fri, 6 Dec 2019 15:51:10 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 203.31.81.177 Received: from [203.31.81.177] ([203.31.81.177]) by ppp14-2-112-104.adl-apt-pir-bras32.tpg.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id xB65L5TK026837; Fri, 06 Dec 2019 15:51:10 +1030 From: "O'Connor, Daniel" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 6 Dec 2019 15:51:04 +1030 Subject: Disabling speculative execution mitigations Message-Id: To: freebsd-stable X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: 1.4 (*) No, score=1.4 required=5.0 tests=HELO_MISC_IP, RDNS_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 47TgzD30Ttz42c2 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.136) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [4.91 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[136.137.101.150.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[dons.net.au]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.98)[0.979,0]; IP_SCORE(1.53)[ip: (3.72), ipnet: 150.101.0.0/16(2.57), asn: 4739(1.36), country: AU(0.01)]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 05:25:47 -0000 Hi, I am trying to track down a performance drop with the ASPEED xorg video = driver between FreeBSD 11 and 12 (I'm not expecting miracles from it but = it was basically unusable..) I wondered if some of the speculative execution mitigations could be = causing the problem so I did some digging and found these.. vm.pmap.pti=3D"0" # Disable page table isolation hw.ibrs_disable=3D"1" # Disable Indirect Branch Restricted = Speculation hw.mds_disable=3D"0" # Disable Microarchitectural Data Sampling = flush hw.vmm.vmx=3D"1" # Don't flush RSB on vmexit (presumably only = affects bhyve etc) hw.lazy_fpu_switch=3D"1" # Lazily flush FPU Does anyone know of any others? I have 2 systems with the same motherboard (Supermicro X11SSH-F), one is = older and runs FreeBSD 11 (and had an older BIOS_ and the newer runs = FreeBSD 12. FWIW on FreeBSD 11 the performance (measured by a subset of x11perf = benchmarks) went down 40% after updating to the latest BIOS (2.2a). = Unfortunately on FreeBSD 12 rolling back to the original BIOS (2.2) did = not improve performance. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-stable@freebsd.org Fri Dec 6 14:22:49 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7CF531CD131 for ; Fri, 6 Dec 2019 14:22:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Tvtw3dfzz4Sxp for ; Fri, 6 Dec 2019 14:22:48 +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 xB6EMMt7012299 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 6 Dec 2019 16:22:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xB6EMMt7012299 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xB6EMLsX012298; Fri, 6 Dec 2019 16:22:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 6 Dec 2019 16:22:21 +0200 From: Konstantin Belousov To: "O'Connor, Daniel" Cc: freebsd-stable Subject: Re: Disabling speculative execution mitigations Message-ID: <20191206142221.GL2744@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47Tvtw3dfzz4Sxp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-2.76), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.53), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:22:49 -0000 On Fri, Dec 06, 2019 at 03:51:04PM +1030, O'Connor, Daniel wrote: > Hi, > I am trying to track down a performance drop with the ASPEED xorg video driver between FreeBSD 11 and 12 (I'm not expecting miracles from it but it was basically unusable..) > > I wondered if some of the speculative execution mitigations could be causing the problem so I did some digging and found these.. > > vm.pmap.pti="0" # Disable page table isolation > hw.ibrs_disable="1" # Disable Indirect Branch Restricted Speculation This line enables IBRS. > hw.mds_disable="0" # Disable Microarchitectural Data Sampling flush > hw.vmm.vmx="1" # Don't flush RSB on vmexit (presumably only affects bhyve etc) I have no idea what this line should configure. > hw.lazy_fpu_switch="1" # Lazily flush FPU > > Does anyone know of any others? Did you read security(7) (on HEAD)? > > I have 2 systems with the same motherboard (Supermicro X11SSH-F), one is older and runs FreeBSD 11 (and had an older BIOS_ and the newer runs FreeBSD 12. > > FWIW on FreeBSD 11 the performance (measured by a subset of x11perf benchmarks) went down 40% after updating to the latest BIOS (2.2a). Unfortunately on FreeBSD 12 rolling back to the original BIOS (2.2) did not improve performance. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Dec 6 17:49:47 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 900DD1B1B00 for ; Fri, 6 Dec 2019 17:49:47 +0000 (UTC) (envelope-from mil@milshop.ru) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V0Tk0jlxz4g8d for ; Fri, 6 Dec 2019 17:49:45 +0000 (UTC) (envelope-from mil@milshop.ru) Received: by mail-il1-x12e.google.com with SMTP id t17so6904443ilm.13 for ; Fri, 06 Dec 2019 09:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=milshop-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=x/wiCoVKZ08yTaa6zAQb+P9x1+yaZ/iLzJRASXcZqNM=; b=QvgXAHt9gnx+N4NhPt03pO5czwMjtYr5gPS7qqEs0zVJxkySMql0u0jiZkonui+UHd 2zjKpB22UiCbDIUPzZT5S1rSszUf81WWEhPiUAgvsMrt12cw6cJ8+/5KmSuCQ/6GEux7 wgUd8XoiTdVDfBIfhZJxFQneUvWzO9EaPQBTYA+QEueANQQaYInHx5Q2YIE5hxykT8b9 qj4ZhuFj5TddOBUMgL/egXZSrEPT07aS+XiJy3fpc4t3PHNRyOGfgBCUl4vdflsL90Lf XkmiTf62LJKJRriYbAoIwoSGsrX1JcigHpMu7d/at7fQmYMkARPGm53xRwx+el/8iya/ f2Tw== 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=x/wiCoVKZ08yTaa6zAQb+P9x1+yaZ/iLzJRASXcZqNM=; b=hEbRRmugxXHdp/OvbhfkQjfIPa7psnMqEXV9LJPihVZi2ptypcn1hjzG1D3CNH4Ymb gVqmbHKwSRXZNc8015neZazU96QK4thSbSY2rpmKciiuPShaWAEupfchJlUAsn0C/Atd oRj5Yd/tDBBZ91jJI4OM2jMD8Q9eFsA1ym3V4uo8uM7IfYPWX+g/+xn9Bf6d8WGrwOGR rLZQhl2BDR0WKRj7sMcH3PZtIUgN8q/IxchvnzW9k39WRGmcoKLsnyHereZ8iWgS6yzq ft14vHqcozz3Tp2Ueqvt4Bv7sRAUAuVtM9ugGqjIZOyT5/NOdlo4yBjgjKiL0MoNel4t Ubkw== X-Gm-Message-State: APjAAAX1GonoDdzjZoAs0ypTEU9+aCigux3AC7/Q5MmSbTZjtYNKKNBt AQ/rcUdGkrJR/a+RY+S1Os7/hRsS9CF5AfwgKaRjsMFfCG8= X-Google-Smtp-Source: APXvYqywUTI4n55fBhx/trXdwNMImpAM8YsLunekw899M2K/Nboz3BmJQoA+K0JKMGpDDfzEN7xKN2CF4JTcjnVL7bk= X-Received: by 2002:a92:ccd0:: with SMTP id u16mr11890734ilq.215.1575654584225; Fri, 06 Dec 2019 09:49:44 -0800 (PST) MIME-Version: 1.0 From: Eugene Kazarinov Date: Fri, 6 Dec 2019 20:49:33 +0300 Message-ID: Subject: ng_ipacct on FreeBSD 12.1 doesnt work To: freebsd-stable X-Rspamd-Queue-Id: 47V0Tk0jlxz4g8d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=milshop-ru.20150623.gappssmtp.com header.s=20150623 header.b=QvgXAHt9; dmarc=none; spf=none (mx1.freebsd.org: domain of mil@milshop.ru has no SPF policy when checking 2607:f8b0:4864:20::12e) smtp.mailfrom=mil@milshop.ru X-Spamd-Result: default: False [-4.63 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[milshop-ru.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[milshop.ru]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[milshop-ru.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[e.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[kamuzon@milshop.ru,mil@milshop.ru]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.63)[ip: (-8.92), ipnet: 2607:f8b0::/32(-2.23), asn: 15169(-1.93), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[kamuzon@milshop.ru,mil@milshop.ru]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 17:49:47 -0000 Hi. pkg install ng_ipacct install ng_ipacct.ko in /boot/modules/ and it doesnt start if I copy ng_ipacct.ko to /boot/kernel/ it didnt start with error: link_elf_obj: symbol tcbinfo undefined linker_load_file: /boot/kernel/ng_ipacct.ko - unsupported file type How to run ng_ipacct on FreeBSD 12.1? Thanks. From owner-freebsd-stable@freebsd.org Fri Dec 6 19:37:21 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA95B1B4431 for ; Fri, 6 Dec 2019 19:37:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V2sr3SM1z3JJV for ; Fri, 6 Dec 2019 19:37:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB6JakmP087332 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Dec 2019 19:36:48 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kamuzon@milshop.ru Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB6JahsH036299 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2019 02:36:43 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ng_ipacct on FreeBSD 12.1 doesnt work To: Eugene Kazarinov , freebsd-stable References: From: Eugene Grosbein Message-ID: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> Date: Sat, 7 Dec 2019 02:36:43 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS,T_DATE_IN_FUTURE_Q_PLUS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 T_DATE_IN_FUTURE_Q_PLUS Date: is over 4 months after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 47V2sr3SM1z3JJV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.69)[ip: (-4.49), ipnet: 2a01:4f8::/29(-2.37), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 19:37:21 -0000 07.12.2019 0:49, Eugene Kazarinov wrote: > pkg install ng_ipacct install ng_ipacct.ko in /boot/modules/ and it > doesnt start > > if I copy ng_ipacct.ko to /boot/kernel/ it didnt start with error: > link_elf_obj: symbol tcbinfo undefined > linker_load_file: /boot/kernel/ng_ipacct.ko - unsupported file type > > How to run ng_ipacct on FreeBSD 12.1? The port has option VIMAGE enabled by default matching GENERIC kernel that has options VIMAGE included. It seems you have built the port with option VIMAGE disabled for some reason. Use: make config clean all deinstall reinstall to enable this option and rebuild ng_ipacct. You don't need to copy in manually, remove copied file. From owner-freebsd-stable@freebsd.org Fri Dec 6 23:03:57 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B8D01BA7C1 for ; Fri, 6 Dec 2019 23:03:57 +0000 (UTC) (envelope-from mil@milshop.ru) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V7SD3yxNz43lc for ; Fri, 6 Dec 2019 23:03:56 +0000 (UTC) (envelope-from mil@milshop.ru) Received: by mail-io1-xd41.google.com with SMTP id l17so9041362ioj.3 for ; Fri, 06 Dec 2019 15:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=milshop-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Aq/W9vEU6dM4suLSMmCBEtucPvh3wTD9Vf8fURDYBE=; b=o0FeWIIq8cE+/LM0OZF0YF4Y6ALbQBMZKeb01XUPMROj/9ytWe5NbNKIGB+MyMWsUG h9TqVXTXOPUOryzU3mCZHRIHLcBvYR+d3xmk+yIX8oXVYPrTHk6rISzzp3ppxwi7bdFN t2Se2+Ki0M0HidtI53EM3tiYMPsTS5tmkya9Cwl5uc5fU5/JhwVZ/b8WNFs5/xQwzBOj U7wsqdwCbVu4Jyg1QZGvaZdG7gepGODjvOx8FUTiT0h/JKgbkBtX+6W8TUFZ2gCSAoAc fZByBhtiZm1QDv+r+EqGqIKOYsc8EpZnDpI+TDxJf6Bxj0DMX0REhG53YwkevTMGH3ia zeRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Aq/W9vEU6dM4suLSMmCBEtucPvh3wTD9Vf8fURDYBE=; b=HjFbjLAewUl/tP0xKWS7hEQ9nvesqtPjSyJauc5GDelbBtnuO6zR7YG5oQNeQpRm58 xYiSVcL1NVVhRg4gkf3KKoG8kSylv6YZIL3naOCNkfY8BBuHupp9SFBksUzwqPn65Jzw QgZhKeK6GwTBGt7kN+lhhiZyIDuN0q9SGW8TTFx22cj7SzKkMDLOl9ZLUPERu3zS2QTe qy2nZkUv/Vt1Xex/14E49zA+UMyiABTzhqnrPoIl/DjShYQ1dSVKt+AxaD6hhz7+3ess xk41DUHZEnpSnxcJ6uZzrnLHIrAgV0KnLE/qEIXX6lIPFtGdEjvOUQg/vIU3ZnjkFeeZ 1sjw== X-Gm-Message-State: APjAAAXP1U86JhhmG6nzQGgipvZJtGkaouzxFk4mitFU5XN/GvM1ExBO p+XAYmbZd+tU+eYOk7Pd2MZgPoLkX93xsn1QKXC5GeH1 X-Google-Smtp-Source: APXvYqzD8nGqPintHY2ddD7FP4hKoVVXsFUP5ACyHKa5YMhRYOo8B1A4D4A0c4aL0YScgLewYz/6pOesh/FfNjpJQxk= X-Received: by 2002:a02:c9c6:: with SMTP id c6mr16177758jap.133.1575673435196; Fri, 06 Dec 2019 15:03:55 -0800 (PST) MIME-Version: 1.0 References: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> In-Reply-To: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> From: Eugene Kazarinov Date: Sat, 7 Dec 2019 02:03:44 +0300 Message-ID: Subject: Re: ng_ipacct on FreeBSD 12.1 doesnt work To: Eugene Grosbein Cc: freebsd-stable X-Rspamd-Queue-Id: 47V7SD3yxNz43lc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=milshop-ru.20150623.gappssmtp.com header.s=20150623 header.b=o0FeWIIq; dmarc=none; spf=none (mx1.freebsd.org: domain of mil@milshop.ru has no SPF policy when checking 2607:f8b0:4864:20::d41) smtp.mailfrom=mil@milshop.ru X-Spamd-Result: default: False [-2.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[milshop-ru.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[milshop.ru]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[milshop-ru.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[kamuzon@milshop.ru,mil@milshop.ru]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.41)[ip: (2.18), ipnet: 2607:f8b0::/32(-2.23), asn: 15169(-1.93), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[kamuzon@milshop.ru,mil@milshop.ru]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 23:03:57 -0000 Yes. It works. Thank you very much. I delete manual copied file. I install ports via portsnap. I fetch srcs from ftp. And install ng_ipacct from ports. And option VIMAGE in port ng_ipacct was disabled. I dont know why. option VIMAGE in kernel of 12.1 by default is enabled. PS Is any option for pkg install to enable VIMAGE in this port? Or I need to return to /usr/src and /usr/ports to rebuild this port after each FreeBSD version upgrade? So. I use FreeBSD many years. And in a few years ago I switched from manual building of kernel and world to freebsd-update. It works on 10.x version well. I install on that freebsd version ng_ipacct via "pkg install". And all works fine. On version 11.1 it looks like all was fine too. Work with total pkg upgrade after upgrade FreeBSD from version 10 to 11. Here I dont sure, because I was on version 11.3 only a few days. At least one or two years it works on version 11.1 very well. But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken. Is it really can be? Or it's my mistake? Thanks again. =D0=BF=D1=82, 6 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 22:37, Eugene Grosb= ein : > 07.12.2019 0:49, Eugene Kazarinov wrote: > > > pkg install ng_ipacct install ng_ipacct.ko in /boot/modules/ and it > > doesnt start > > > > if I copy ng_ipacct.ko to /boot/kernel/ it didnt start with error: > > link_elf_obj: symbol tcbinfo undefined > > linker_load_file: /boot/kernel/ng_ipacct.ko - unsupported file type > > > > How to run ng_ipacct on FreeBSD 12.1? > > The port has option VIMAGE enabled by default matching GENERIC kernel tha= t > has options VIMAGE included. > It seems you have built the port with option VIMAGE disabled for some > reason. > > Use: make config clean all deinstall reinstall > to enable this option and rebuild ng_ipacct. You don't need to copy in > manually, remove copied file. > > From owner-freebsd-stable@freebsd.org Fri Dec 6 23:17:54 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 173001BAFE4 for ; Fri, 6 Dec 2019 23:17:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V7mK20cqz44VV for ; Fri, 6 Dec 2019 23:17:53 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lj1-x242.google.com with SMTP id r19so9418227ljg.3 for ; Fri, 06 Dec 2019 15:17:53 -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=o38AaV0V9LpyiqAX7kjhaHiigaJUxyFeWKNzoBzL+C4=; b=XT3yDwe79GSS3ozAjwRk0uslBNGW+fbu81lOo8wV1I7BTjworsULZ4O5lzjOP0MLnE m7IZWDo9hKSMA6pAOZykbdBmotu5uuB5W4duRtDpe9yseAjJuFK2Gp9rI7vd+ksVLP+e d6tgO6j/t9SRCgtgRrBf06eDtAgwi7d4OFNBsQ/HmQFH3LtImohrmlzvMgDV5HSjHM0Q 8VBEG9yXjyX4A8YisqOyxKRq2epF3Olitv6zRcYjYOIcw5fmqqC5BIaguFUzPlmxJLz+ pzdtix0EjQ68Vm9aM8MFduROa6wq41by1ZIVZypRbZXfTyVb+++lpT6X3HXpKVpxei2n PTpw== 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=o38AaV0V9LpyiqAX7kjhaHiigaJUxyFeWKNzoBzL+C4=; b=tQanvarLjdGc5LHDdQohOBs1BGBG7cLv7q5Z3taJJzZi8DKPyO+OOCMi8KbSJ5Ky2o l9bUcXGMxXP+bDmIEQ3tA3uIFLJNpCmlz1SYmJaR3e3SuJ4AP9NCcpPYV1W28aIe9LY1 w5FNumTXCVolnfl9Iu4Pq9LGhE1W+pAD9rCsD/Hlug3GEDWsp5U8Ra2JY0CZeOtdEKjr sB+omJtjSm++WJXzg3Pu2SzlBsPTfId6P/hRagEniHkGTyyvBpXhamkk84TNb2UAwdnU 0qpJlw2MkIW2oT4Ctoun4jBJiRLx1uz/8lD7cGY/02Hk32kh1wS8niV9EsiNOCTj6TF+ fLPg== X-Gm-Message-State: APjAAAXO2R6An2UFoK8aWnYPcoHhYZypaIc0b/ZVN+biqNc3tS07YgwY qMeomgv4YI1/D6UG2EBWYL6zmYcdLt1NhJ9qdQ1zc0BU X-Google-Smtp-Source: APXvYqxPHzuRpB98clgcS13PgakH/AJi4MU0GxIet3RzRYQnTzyHPkpjzMIbIYUXcC7YA6HoUz4VrbymnPykEKlfVfA= X-Received: by 2002:a2e:b0e3:: with SMTP id h3mr9817988ljl.56.1575674271386; Fri, 06 Dec 2019 15:17:51 -0800 (PST) MIME-Version: 1.0 From: Freddie Cash Date: Fri, 6 Dec 2019 15:17:37 -0800 Message-ID: Subject: Boot fails with USB 3.0 external harddrive plugged in To: FreeBSD Stable X-Rspamd-Queue-Id: 47V7mK20cqz44VV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XT3yDwe7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2a00:1450:4864:20::242 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (2.72), ipnet: 2a00:1450::/32(-2.68), asn: 15169(-1.93), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 23:17:54 -0000 [fcash@rogue /home/fcash]$ freebsd-version -ku 12.0-RELEASE-p8 12.0-RELEASE-p8 This system was previously running FreeBSD 11.2 and didn't have any issues booting with the external USB drive plugged into the USB 3.0 ports on the motherboard. Ever since upgrading to 12.0, and through all the updates to -p8, booting with the external drive plugged in fails. It will eventually get through the loader, start to load the kernel, then drop to a black screen, and (after a few minutes) power off the system completely. The boot process is *extremely* slow with the USB drive plugged in. As in, you can watch the loader cursor twirl at about 1 frame every few seconds. However, if I am sitting at the computer, I can press any key on the keyboard (even shift, ctrl, alt, or spacebar), and it will make the cursor spin at a normal speed for a second or two. So, if I hit a key on the keyboard every other second, it will go through a normal boot process. I seem to recall there was a similar issue on the mailing list a couple months back, but my google-fu is failing me. :( I thought there was a loader.conf setting that resolved that issue, but I can't seem to find it. If I unplug the external drive, it boots normally without any user intervention. Connecting the drive after the login prompt appears, everything works normally. It's only the boot process that is an issue. This is an olded system, using an AMD Phenom-II quad-core CPU, but has 16 GB of RAM, and 6 harddrives in a ZFS pool. Has been working great, up until the 12.0 upgrade. I have plans to upgrade this system to 12.1 later this month. Just wondering if this is a known issue that's fixed in that release, or something new. xhci0: mem 0xfe800000-0xfe807fff irq 46 at device 0.0 on pci2 xhci0: 32 bytes context size, 32-bit DMA xhci0: Unable to map MSI-X table usbus0 on xhci0 xhci1: mem 0xfe600000-0xfe607fff irq 50 at device 0.0 on pci4 xhci1: 32 bytes context size, 32-bit DMA xhci1: Unable to map MSI-X table usbus1 on xhci1 ohci0: mem 0xfe90a000-0xfe90afff irq 18 at device 18.0 on pci0 usbus2 on ohci0 ehci0: mem 0xfe909000-0xfe9090ff irq 17 at device 18.2 on pci0 usbus3 on ehci0 ohci1: mem 0xfe908000-0xfe908fff irq 20 at device 19.0 on pci0 usbus4 on ohci1 ehci1: mem 0xfe907000-0xfe9070ff irq 21 at device 19.2 on pci0 usbus5 on ehci1 ohci2: mem 0xfe906000-0xfe906fff irq 18 at device 20.5 on pci0 usbus6 on ohci2 ohci3: mem 0xfe905000-0xfe905fff irq 22 at device 22.0 on pci0 usbus7 on ohci3 ehci2: mem 0xfe904000-0xfe9040ff irq 23 at device 22.2 on pci0 usbus8 on ehci2 da0 at umass-sim0 bus 0 scbus12 target 0 lun 0 da0: Fixed Direct Access SPC-3 SCSI device da0: Serial Number Z297HW2Q da0: 400.000MB/s transfers da0: 2861588MB (5860533168 512 byte sectors) da0: quirks=0x2 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@freebsd.org Sat Dec 7 00:26:35 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 210491BD24D for ; Sat, 7 Dec 2019 00:26:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V9HY5TdNz48Sc for ; Sat, 7 Dec 2019 00:26:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB70MPEK090437 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 7 Dec 2019 00:22:29 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kamuzon@milshop.ru Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB70MHIl039126 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2019 07:22:17 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ng_ipacct on FreeBSD 12.1 doesnt work To: Eugene Kazarinov References: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> Cc: freebsd-stable From: Eugene Grosbein Message-ID: <2c6253a9-d6e6-28ed-19d1-efa1fcb9eb01@grosbein.net> Date: Sat, 7 Dec 2019 07:22:16 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.6 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_48_96, HELO_MISC_IP,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.2 DATE_IN_FUTURE_48_96 Date: is 48 to 96 hours after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * 1.1 HELO_MISC_IP Looking for more Dynamic IP Relays X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eg.sd.rdtc.ru X-Rspamd-Queue-Id: 47V9HY5TdNz48Sc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.69)[ip: (-4.51), ipnet: 2a01:4f8::/29(-2.37), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 00:26:35 -0000 07.12.2019 6:03, Eugene Kazarinov wrote: > Yes. It works. Thank you very much. > > I delete manual copied file. > I install ports via portsnap. > I fetch srcs from ftp. > And install ng_ipacct from ports. > And option VIMAGE in port ng_ipacct was disabled. I dont know why. > option VIMAGE in kernel of 12.1 by default is enabled. > > PS Is any option for pkg install to enable VIMAGE in this port? > Or I need to return to /usr/src and /usr/ports to rebuild this port after each FreeBSD version upgrade? > > So. I use FreeBSD many years. And in a few years ago I switched from manual building of kernel and world to freebsd-update. It works on 10.x version well. I install on that freebsd version ng_ipacct via "pkg install". And all works fine. > On version 11.1 it looks like all was fine too. Work with total pkg upgrade after upgrade FreeBSD from version 10 to 11. Here I dont sure, because I was on version 11.3 only a few days. At least one or two years it works on version 11.1 very well. > But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken. > Is it really can be? Or it's my mistake? This option is enabled by default, so the package should be built accordingly. Are you sure you use official source for packages? From owner-freebsd-stable@freebsd.org Sat Dec 7 00:28:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5FC411BD726 for ; Sat, 7 Dec 2019 00:28:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V9LH5Xzsz48wk; Sat, 7 Dec 2019 00:28:55 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB70SCXI090513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 7 Dec 2019 00:28:13 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kamuzon@milshop.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB70SABH039203 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2019 07:28:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ng_ipacct on FreeBSD 12.1 doesnt work To: Eugene Kazarinov References: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> <2c6253a9-d6e6-28ed-19d1-efa1fcb9eb01@grosbein.net> Cc: freebsd-stable , Vsevolod Stakhov From: Eugene Grosbein Message-ID: <3fa47dd3-ec81-0908-a782-afa88fc023af@grosbein.net> Date: Sat, 7 Dec 2019 07:28:04 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2c6253a9-d6e6-28ed-19d1-efa1fcb9eb01@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 47V9LH5Xzsz48wk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.70)[ip: (-4.53), ipnet: 2a01:4f8::/29(-2.37), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 00:28:56 -0000 07.12.2019 7:22, Eugene Grosbein wrote: Adding port maintainer to CC: >> Yes. It works. Thank you very much. >> >> I delete manual copied file. >> I install ports via portsnap. >> I fetch srcs from ftp. >> And install ng_ipacct from ports. >> And option VIMAGE in port ng_ipacct was disabled. I dont know why. >> option VIMAGE in kernel of 12.1 by default is enabled. >> >> PS Is any option for pkg install to enable VIMAGE in this port? >> Or I need to return to /usr/src and /usr/ports to rebuild this port after each FreeBSD version upgrade? >> >> So. I use FreeBSD many years. And in a few years ago I switched from manual building of kernel and world to freebsd-update. It works on 10.x version well. I install on that freebsd version ng_ipacct via "pkg install". And all works fine. >> On version 11.1 it looks like all was fine too. Work with total pkg upgrade after upgrade FreeBSD from version 10 to 11. Here I dont sure, because I was on version 11.3 only a few days. At least one or two years it works on version 11.1 very well. >> But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken. >> Is it really can be? Or it's my mistake? > > This option is enabled by default, so the package should be built accordingly. > Are you sure you use official source for packages? Sorry, I was wrong: the port defaults to disabled VIMAGE option, this explains your difficulty. Vsevolid, please consider enabling option VIMAGE for net-mgmt/ng_ipacct for branches having VIMAGE in GENERIC, so the package would be usable out-of-the-box there. From owner-freebsd-stable@freebsd.org Sat Dec 7 02:13:40 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DF6C71C34E8 for ; Sat, 7 Dec 2019 02:13:40 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47VCg76HtSz4HQZ for ; Sat, 7 Dec 2019 02:13:39 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id xB72D5VK062798 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 7 Dec 2019 03:13:06 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id xB72D5ZY062797 for freebsd-stable@FreeBSD.ORG; Sat, 7 Dec 2019 03:13:05 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id xB70Gc52094021 for ; Sat, 7 Dec 2019 01:16:38 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id xB70E1Dl093767 for ; Sat, 7 Dec 2019 01:14:01 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id xB70E1Ts093766 for freebsd-stable@FreeBSD.ORG; Sat, 7 Dec 2019 01:14:01 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: Disabling speculative execution mitigations Date: Sat, 07 Dec 2019 01:02:59 +0100 Organization: n/a Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="92961"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Opera Mail/12.16 (FreeBSD) Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [185.220.148.12]); Sat, 07 Dec 2019 03:13:09 +0100 (CET) X-Rspamd-Queue-Id: 47VCg76HtSz4HQZ X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org has no SPF policy when checking 2001:1440:5001:1::2) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org X-Spamd-Result: default: False [4.41 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(0.89)[0.892,0]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.34)[ip: (0.90), ipnet: 2001:1440::/32(0.45), asn: 8469(0.36), country: DE(-0.01)]; NEURAL_SPAM_LONG(0.98)[0.975,0]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; DMARC_NA(0.00)[sub.org]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:8469, ipnet:2001:1440::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 02:13:40 -0000 On Fri, 06 Dec 2019 06:21:04 +0100, O'Connor, Daniel wrote: > vm.pmap.pti="0" # Disable page table isolation > hw.ibrs_disable="1" # Disable Indirect Branch Restricted Speculation > hw.mds_disable="0" # Disable Microarchitectural Data Sampling flush > hw.vmm.vmx="1" # Don't flush RSB on vmexit (presumably only > affects bhyve etc) > hw.lazy_fpu_switch="1" # Lazily flush FPU > > Does anyone know of any others? hw.spec_store_bypass_disable=2 I have that on 11.3 (no idea yet about 12). And honestly, I lost track which of these should be on, off, automatic, opaque or elsewhere to achieve either performance or security (not to mention for which cores and under which circumstances it would matter, and what the impact might be), and my oracle says this will not end with these. From owner-freebsd-stable@freebsd.org Sat Dec 7 03:54:22 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8BE211C6D2C for ; Sat, 7 Dec 2019 03:54:22 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [150.101.137.136]) by mx1.freebsd.org (Postfix) with ESMTP id 47VFvJ6dL4z4MmT for ; Sat, 7 Dec 2019 03:54:20 +0000 (UTC) (envelope-from darius@dons.net.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ArAACO3/Jb/2hwAg5iGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAQGBVAEBAQEBAQsBggNmTyESJ4xvix0BSQIBAQEBAQEGgTEEiQc?= =?us-ascii?q?OkBsLAQEjCAGEQAKDbCM3Bg0BAwEBAgEBAm0cDIU8AQEBAQIBLA4cIwULCw4KL?= =?us-ascii?q?iEYHgYTgyEBgWkDCAUHEAOoZB6FIoI2DYIUBROMCXiBB4ERJx+CTIJWgiiDNYI?= =?us-ascii?q?mAp9BLgkChniHAoMrGIFYiCuGeo05gQiGVIJaAgoHFIFcIoFVbBllAYJBPoFpF?= =?us-ascii?q?4hehVEsAQIwgQUBAY1VAQE?= Received: from ppp14-2-112-104.adl-apt-pir-bras32.tpg.internode.on.net (HELO midget.dons.net.au) ([14.2.112.104]) by ipmail01.adl6.internode.on.net with ESMTP; 07 Dec 2019 14:24:15 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id xB73rtH5007059 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 7 Dec 2019 14:24:10 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id xB73SVi4088795 for ; Sat, 7 Dec 2019 13:58:31 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 10.0.2.38 Received: from havok.dons.net.au (Havok.dons.net.au [10.0.2.38]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id xB73SPJd088785; Sat, 07 Dec 2019 13:58:31 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Disabling speculative execution mitigations From: "O'Connor, Daniel" In-Reply-To: <20191206142221.GL2744@kib.kiev.ua> Date: Sat, 7 Dec 2019 13:58:25 +1030 Cc: freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191206142221.GL2744@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 47VFvJ6dL4z4MmT X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.136) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [4.90 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.971,0]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[136.137.101.150.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(1.53)[ip: (3.71), ipnet: 150.101.0.0/16(2.57), asn: 4739(1.36), country: AU(0.01)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 03:54:22 -0000 > On 7 Dec 2019, at 00:52, Konstantin Belousov = wrote: >=20 > On Fri, Dec 06, 2019 at 03:51:04PM +1030, O'Connor, Daniel wrote: >> Hi, >> I am trying to track down a performance drop with the ASPEED xorg = video driver between FreeBSD 11 and 12 (I'm not expecting miracles from = it but it was basically unusable..) >>=20 >> I wondered if some of the speculative execution mitigations could be = causing the problem so I did some digging and found these.. >>=20 >> vm.pmap.pti=3D"0" # Disable page table isolation >> hw.ibrs_disable=3D"1" # Disable Indirect Branch Restricted = Speculation > This line enables IBRS. Oops, thanks. >> hw.mds_disable=3D"0" # Disable Microarchitectural Data Sampling = flush >> hw.vmm.vmx=3D"1" # Don't flush RSB on vmexit (presumably only = affects bhyve etc) > I have no idea what this line should configure. It should have been.. hw.vmm.vmx.no_flush_rsb=3D"1" Not that it would affect my test system since I'm not use vmm.ko >> hw.lazy_fpu_switch=3D"1" # Lazily flush FPU >>=20 >> Does anyone know of any others? > Did you read security(7) (on HEAD)? Nope, I didn't even know it existed. Basically, I went through the MFCs listed at = https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities and looked = for tuneables and sysctls. With respect to the man page, I find it difficult to know what a given = value for each sysctl will do, as evidenced by my confusion above about = IBRS. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-stable@freebsd.org Sat Dec 7 19:10:26 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6DD781CA41F for ; Sat, 7 Dec 2019 19:10:26 +0000 (UTC) (envelope-from mil@milshop.ru) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47VfDK22VHz47Gl for ; Sat, 7 Dec 2019 19:10:24 +0000 (UTC) (envelope-from mil@milshop.ru) Received: by mail-io1-xd29.google.com with SMTP id z26so10701221iot.8 for ; Sat, 07 Dec 2019 11:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=milshop-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6KvsK8g2zWJS6hgMcW1urc1hAQUH4I8exm0I7m5R06M=; b=b554/P/8xY8IJ5EZA4pk0p5tqdfS7Kw7zmOmznUwD40aH4rWLUFimzlHKYyf0XCThE LZbOps3X/i34vcqpnnBfa5tvd10+GbUeFPShmcK3//2maHt36aV6Q52tMvslAAUPpd8T g3P75Un7Nbvtc+cvzxOJQKo505w+AcA+ZELQ7k99onHVqFhf1TA6lZSh+fXk18V9luRP l8XbPWgeqBda5doPc/gwQnfIIZSoi/a4IvWC0YvHEwa/9SpOj1SiJqZ5FH2cE9lgDTQ2 pVeRQUJqHKrthwf79S7dOfitNc7GAWovECFQnnOmSSuoalVP+M95JXUFeYjRiMm9Zshl 6s5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6KvsK8g2zWJS6hgMcW1urc1hAQUH4I8exm0I7m5R06M=; b=EuCXZBnjC28dOsuLL6oE4OLq6BVLnf63epLrdQRqgYM4Iy8/OnzpwMX6Ji6jD3pdhy HEX0npl0vhpFemb2hjGMZQ8jqfPEBH+7XxJMOVy0aiR/HCflTB802bIuVfJtId+pDvnQ B0w2TiFbXBGCu5sOdOwT252KMlenDdM5H0l/BVbt7RqaBmMAFjpOc9RG0nEPGeBNwvsf e88j9lAdQjIDc0jLC/t7VTcDTLioL00OtzxhDjkGd6Gnejj0r1ym62rbEtHyuN+bF97L NjZz2ypis9OqRXV51DmPJhHvfC0lR3cy9EhfVFqNJAxq2tA4a1uyuvoNcxktkzEMAim+ WgIw== X-Gm-Message-State: APjAAAX+1fPwQcvVA89izI0q9y7Kz2za6fX6OE78Uj3wndzNUCbF6D5C RMr50KFPgO+NU9FdbuCqNvxGlPtxlR1qKE54gRyQfw== X-Google-Smtp-Source: APXvYqzrkPaFLy5aGyvb2yUlFlf1/1g2Hh6RjjJflsXNgmFHVnTM/ZPBlYiMyijYMCs08fKMCXaVMnjfLCDxBpzjJ8U= X-Received: by 2002:a6b:b5d2:: with SMTP id e201mr15125340iof.74.1575745823676; Sat, 07 Dec 2019 11:10:23 -0800 (PST) MIME-Version: 1.0 References: <1cc79b58-813d-60ae-477c-e89dd114e59c@grosbein.net> <2c6253a9-d6e6-28ed-19d1-efa1fcb9eb01@grosbein.net> <3fa47dd3-ec81-0908-a782-afa88fc023af@grosbein.net> In-Reply-To: <3fa47dd3-ec81-0908-a782-afa88fc023af@grosbein.net> From: Eugene Kazarinov Date: Sat, 7 Dec 2019 22:10:11 +0300 Message-ID: Subject: Re: ng_ipacct on FreeBSD 12.1 doesnt work To: Eugene Grosbein Cc: freebsd-stable , Vsevolod Stakhov X-Rspamd-Queue-Id: 47VfDK22VHz47Gl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=milshop-ru.20150623.gappssmtp.com header.s=20150623 header.b=b554/P/8; dmarc=none; spf=none (mx1.freebsd.org: domain of mil@milshop.ru has no SPF policy when checking 2607:f8b0:4864:20::d29) smtp.mailfrom=mil@milshop.ru X-Spamd-Result: default: False [-3.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[milshop-ru.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[milshop.ru]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[milshop-ru.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[9.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[kamuzon@milshop.ru,mil@milshop.ru]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.92)[ip: (-5.40), ipnet: 2607:f8b0::/32(-2.22), asn: 15169(-1.93), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[kamuzon@milshop.ru,mil@milshop.ru]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 19:10:26 -0000 Great Thanks. =D1=81=D0=B1, 7 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 03:28, Eugene Grosb= ein : > 07.12.2019 7:22, Eugene Grosbein wrote: > > Adding port maintainer to CC: > > >> Yes. It works. Thank you very much. > >> > >> I delete manual copied file. > >> I install ports via portsnap. > >> I fetch srcs from ftp. > >> And install ng_ipacct from ports. > >> And option VIMAGE in port ng_ipacct was disabled. I dont know why. > >> option VIMAGE in kernel of 12.1 by default is enabled. > >> > >> PS Is any option for pkg install to enable VIMAGE in this port? > >> Or I need to return to /usr/src and /usr/ports to rebuild this port > after each FreeBSD version upgrade? > >> > >> So. I use FreeBSD many years. And in a few years ago I switched from > manual building of kernel and world to freebsd-update. It works on 10.x > version well. I install on that freebsd version ng_ipacct via "pkg > install". And all works fine. > >> On version 11.1 it looks like all was fine too. Work with total pkg > upgrade after upgrade FreeBSD from version 10 to 11. Here I dont sure, > because I was on version 11.3 only a few days. At least one or two years = it > works on version 11.1 very well. > >> But after upgrade from 11.3 to 12.1 "pkg install ng_ipacct" got broken= . > >> Is it really can be? Or it's my mistake? > > > > This option is enabled by default, so the package should be built > accordingly. > > Are you sure you use official source for packages? > > Sorry, I was wrong: the port defaults to disabled VIMAGE option, this > explains your difficulty. > > Vsevolid, please consider enabling option VIMAGE for net-mgmt/ng_ipacct > for branches having VIMAGE in GENERIC, > so the package would be usable out-of-the-box there. > >