On 23 April 2015 at 22:26, Scott Long <scott4l...@yahoo.com> wrote: > >> On Apr 23, 2015, at 1:28 PM, Chagin Dmitry <dcha...@freebsd.org> wrote: >> >> On Thu, Apr 23, 2015 at 12:49:51PM -0600, Scott Long wrote: >>> >>>> On Apr 23, 2015, at 6:19 AM, Scott Long <scott4l...@yahoo.com> wrote: >>>> >>>>> >>>>> On Apr 12, 2015, at 12:21 AM, Dmitry Chagin <dcha...@freebsd.org> wrote: >>>>> >>>>> Author: dchagin >>>>> Date: Sun Apr 12 06:21:58 2015 >>>>> New Revision: 281451 >>>>> URL: https://svnweb.freebsd.org/changeset/base/281451 >>>>> >>>>> Log: >>>>> Rework r281162. Indeed, the flexible array member is preferable here. >>>>> >>>>> Suggested by: Justin T. Gibbs >>>>> >>>>> MFC after: 3 days >>>>> >>>>> Modified: >>>>> head/sys/vm/uma_core.c >>>>> head/sys/vm/uma_int.h >>>> >>>> There???s still something wrong with this. I have a machine with 28 cores >>>> (56 with hyperthreading) and 256GB of RAM, and ever since you committed >>>> r281162, it panics early in boot with a failed assertion. It looks like >>>> the first few members of a uma_slab_t are getting overwritten >>>> accidentally, and somehow the padding of the extra member in the >>>> uma_zone_t was previously protecting it. I don???t know the exact cause >>>> yet, but I must ask that you revert to r281161 in HEAD and stable/10 until >>>> the problem is resolved. >>>> >>> >>> I think the problem is that the masterzone_k and masterzone_z objects that >>> are statically allocated in uma_core.c no longer have space for the uz_cpu >>> field, but uma_zalloc_arg() always assumes that it???s there. Early in >>> boot when the ???kegs' and ???zones??? zones are being initialized, >>> there???s only 1 CPU so pre-allocating 1 uz_cpu element in the uma_zone is >>> enough. I can???t see any way around this without significantly changing >>> how uma_zalloc_arg() treats per-cpu caches. I think it???s best to revert >>> this change. >>> >> Hi, >> they initialized in uma_startup() and not used before. >> I have a private converstion with a man which stable/10 hangs in >> vm_mem_init().\ >> with my commit. weird. >> >> I do not object to revert, but give me a chance to figure out what's going >> on. > > With INVARIANTS enabled, the system will panic. Without it, it will spin in > vm_mem_init(), as you noted. Even if it’s not happening to everyone, it’s a > serious problem for such a minor anticipated benefit. I must insist that it > be reverted.
Hi, +1 - please revert the patch for now and figure it out locally. Having -HEAD broken is very annoying. -a _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
