head -r334749 breaks the FreeBSD-head-amd64-gcc ci.freebsd.org build [via pmc.h struct's having constructors in C++]

[Note other build failures stopped builds before the below before this was run into. Now those pass to reach the below.] ci.free.bsd.org has FreeBSD-head-amd64-gcc failing for: --- libpmc_json.o --- In file included from /workspace/src/lib/libpmc/libpmc_json.cc:39:0: /workspace/src/lib/libpmc/pmc

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

On Fri, Jun 08, 2018 at 11:40:37AM -0400, Jonathan T. Looney wrote: > ... > If anyone is hitting this bug and needs to get a working system in the > meantime, you'll need to revert the following commits which implemented (or > updated) this change: > > r334830 > r334829 > r334824 > > Jonathan I

Re: rust broken?

On Thu, Jun 7, 2018 at 11:26 PM, Greg wrote: > On 06/07, Matthew Macy wrote: >> >> On Thu, Jun 7, 2018 at 10:33 Michael Butler >> wrote: >> >>> Ah - I'll re-enable that to see if it makes a difference .. >>> >> >> >> It's not a question of enabling. It doesn't explicitly use the 11 symbols. >> Ru

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

weird, my grep-fu failed me hardcore i guess. Will fix shortly. On Fri, Jun 8, 2018 at 5:40 PM, Jonathan T. Looney wrote: > On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney > wrote: > > > > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill > wrote: > > > > > > Sorry for lack of much analysis

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney wrote: > > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill wrote: > > > > Sorry for lack of much analysis; am at BSDCan. jtl@ suggested that a > > sequence of changes involving memory allocation and ipfw counters is > > likely to be at issue. >

Re: Panic from ipfw_alloc_rule() after r334769 -> r334832

On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill wrote: > > Sorry for lack of much analysis; am at BSDCan. jtl@ suggested that a > sequence of changes involving memory allocation and ipfw counters is > likely to be at issue. Just to be clear, I speculated that this seemed like it could be caused

Re: Is kern.sched.preempt_thresh=0 a sensible default?

On Fri, 8 Jun 2018 17:18:43 +0300 Andriy Gapon wrote: > On 08/06/2018 15:27, Gary Jennejohn wrote: > > On Thu, 7 Jun 2018 20:14:10 +0300 > > Andriy Gapon wrote: > > > >> On 03/05/2018 12:41, Andriy Gapon wrote: > >>> I think that we need preemption policies that might not be expressible as

Re: Is kern.sched.preempt_thresh=0 a sensible default?

On 08/06/2018 15:27, Gary Jennejohn wrote: > On Thu, 7 Jun 2018 20:14:10 +0300 > Andriy Gapon wrote: > >> On 03/05/2018 12:41, Andriy Gapon wrote: >>> I think that we need preemption policies that might not be expressible as >>> one or >>> two numbers. A policy could be something like this: >>>

Panic from ipfw_alloc_rule() after r334769 -> r334832

Sorry for lack of much analysis; am at BSDCan. jtl@ suggested that a sequence of changes involving memory allocation and ipfw counters is likely to be at issue. I tried grabbing some screen shots, the last of which has a backtrace (that isn't cut off, as the middle one is); they are available at

Re: Is kern.sched.preempt_thresh=0 a sensible default?

On Thu, 7 Jun 2018 20:14:10 +0300 Andriy Gapon wrote: > On 03/05/2018 12:41, Andriy Gapon wrote: > > I think that we need preemption policies that might not be expressible as > > one or > > two numbers. A policy could be something like this: > > - interrupt threads can preempt only threads from

Re: r334533 renders head unbootable on XenServer 7.4

On Fri, 8 Jun 2018 02:51+0200, Mateusz Guzik wrote: > Thanks for the report. Next time if you identify the culprit please cc: > the committer - not everyone watches mailing lists too closely. Wilco. > I set it up on FreeBSD as dom0 and verified the problem exists. > I fixed it with the following