> 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. Scott _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
