Date: Sat, 2 Jul 2016 13:31:01 -0400 From: outro pessoa <outro.pessoa@gmail.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Review request: sparse CPU ID maps Message-ID: <CAD9=5Xw-MmVVSSo6nRvSRvGaLbd1Z1YRyVKyF9JfmucNKMGBZg@mail.gmail.com> In-Reply-To: <57761101.3030101@freebsd.org> References: <57761101.3030101@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nathan, What type of ARM hardware do you need? On Fri, Jul 1, 2016 at 2:43 AM, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: > I have been working on fixing PR 210106 ( > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210106) and have run > into the fact that several pieces of the kernel, notably parts of > subr_taskqueue.c, require that CPU IDs be dense in the range [0, mp_ncpus), > which the kernel does not guarantee, for example in the case of CPUs with > hyperthreading in which the threading is disabled. This is leading to hangs > in late boot in -CURRENT. > > I've prepared the following patch, which fixes PR 210106, but I would like > a few more eyeballs on it before committing it. It fixes most of the bogus > uses of mp_ncpus in the kernel, but not all: doing grep -R '< mp_ncpus' > /sys | wc -l gives 52 remaining instances of loops in [0, mp_ncpus) or [1, > mp_ncpus), most or all of which should instead be CPU_FOREACH(), but none > of which I feel comfortable changing (36 are in ARM code for hardware I > don't have access to). > > The patch lives here: > http://people.freebsd.org/~nwhitehorn/sparse_cpu_ids.diff > -Nathan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD9=5Xw-MmVVSSo6nRvSRvGaLbd1Z1YRyVKyF9JfmucNKMGBZg>