weird, my grep-fu failed me hardcore i guess. Will fix shortly. On Fri, Jun 8, 2018 at 5:40 PM, Jonathan T. Looney <jtl_at_freebsd.org> wrote: > On Fri, Jun 8, 2018 at 10:52 AM, Jonathan T. Looney <jtl_at_freebsd.org> > wrote: > > > > On Fri, Jun 8, 2018 at 9:38 AM, David Wolfskill <david_at_catwhisker.org> > wrote: > > > > > > Sorry for lack of much analysis; am at BSDCan. jtl_at_ 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 > by r334824. > > > > And, screen_1.jpg does indeed seem to point at that commit. > > Yes, it is clear that this is hitting r334824. > > V_ipfw_cntr_zone is defined with UMA_ZONE_PCPU. > > ipfw_alloc_rule() allocates from V_ipfw_cntr_zone with M_ZERO. > > That clearly violates the assertion added in r334824, as well as the > assumption behind the commit: "Nothing in the tree uses it..." > > It seems like something will need to be changed here to resolve the > mismatch in assumptions/expectations... :-/ > > 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 > -- Mateusz Guzik <mjguzik gmail.com>Received on Fri Jun 08 2018 - 13:54:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC