FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=upstream%2F11.0.0 2016-07-06T14:09:49Z 2016-07-06T14:09:49Z Nathan Whitehorn nwhitehorn@FreeBSD.org 2016-07-06T14:09:49Z urn:sha1:96c85efb4b85dbc0bfc4968516a627a727ac7ec5 mp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places in the kernel that assumed CPU IDs are dense in [0, mp_ncpus) and would try, for example, to run tasks on CPUs that did not exist or to allocate too few buffers on systems with sparse CPU IDs in which there are holes in the range and mp_maxid > mp_ncpus. Such circumstances generally occur on systems with SMT, but on which SMT is disabled. This patch restores system operation at least on POWER8 systems configured in this way. There are a number of other places in the kernel with potential problems in these situations, but where sparse CPU IDs are not currently known to occur, mostly in the ARM machine-dependent code. These will be fixed in a follow-up commit after the stable/11 branch. PR: kern/210106 Reviewed by: jhb Approved by: re (glebius) 2014-02-10T19:59:46Z Gleb Smirnoff glebius@FreeBSD.org 2014-02-10T19:59:46Z urn:sha1:49fef6a202a5c2f4113940f87de5d8765897ab3b Sponsored by: Nginx, Inc. 2011-11-07T06:44:47Z Ed Schouten ed@FreeBSD.org 2011-11-07T06:44:47Z urn:sha1:d745c852becf3792a2185003947324721209195a This means that their use is restricted to a single C file. 2011-07-19T14:57:59Z Attilio Rao attilio@FreeBSD.org 2011-07-19T14:57:59Z urn:sha1:edf26ab83e5d4f274cfee43495472aef14b39b93 pc_name is only included when KTR option is and it does introduce a subdle KBI breakage that totally breaks vmstat when world and kernel are not in sync. Besides, it is not used somewhere. In collabouration with: pluknet Reviewed by: jhb Approved by: re (kib) 2011-07-04T10:45:54Z Attilio Rao attilio@FreeBSD.org 2011-07-04T10:45:54Z urn:sha1:a2f4e284b063d4ef888098f52b5474e1425bb404 Tested by: pluknet 2011-05-31T21:22:44Z Attilio Rao attilio@FreeBSD.org 2011-05-31T21:22:44Z urn:sha1:61b926921f1e0ea3eae9511fb25ca6f016e0a5c2 2011-05-31T15:11:43Z Nathan Whitehorn nwhitehorn@FreeBSD.org 2011-05-31T15:11:43Z urn:sha1:d098f93019ca215163773034de59731e92c2e52e be brought up in the order they are enumerated in the device tree (in particular, that thread 0 on each core be brought up first). The SLIST through which we loop to start the CPUs has all of its entries added with SLIST_INSERT_HEAD(), which means it is in reverse order of enumeration and so AP startup would always fail in such situations (causing a machine check or RTAS failure). Fix this by changing the SLIST into an STAILQ, and inserting new CPUs at the end. Reviewed by: jhb 2011-05-05T14:39:14Z Attilio Rao attilio@FreeBSD.org 2011-05-05T14:39:14Z urn:sha1:71a19bdc640eb9d54e7db3d1d135753888f3469c cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno 2011-01-11T13:59:06Z John Baldwin jhb@FreeBSD.org 2011-01-11T13:59:06Z urn:sha1:58ccf5b41c6baf98367501218fda6c511941d367 it internally contain nested includes. Reviewed by: bde 2010-11-22T19:32:54Z Dimitry Andric dim@FreeBSD.org 2010-11-22T19:32:54Z urn:sha1:3e288e623846fab91d923dd651b263d4696fd814 DPCPU_DEFINE and VNET_DEFINE macros, as these cause problems for various people working on the affected files. A better long-term solution is still being considered. This reversal may give some modules empty set_pcpu or set_vnet sections, but these are harmless. Changes reverted: ------------------------------------------------------------------------ r215318 | dim | 2010-11-14 21:40:55 +0100 (Sun, 14 Nov 2010) | 4 lines Instead of unconditionally emitting .globl's for the __start_set_xxx and __stop_set_xxx symbols, only emit them when the set_vnet or set_pcpu sections are actually defined. ------------------------------------------------------------------------ r215317 | dim | 2010-11-14 21:38:11 +0100 (Sun, 14 Nov 2010) | 3 lines Apply the STATIC_VNET_DEFINE and STATIC_DPCPU_DEFINE macros throughout the tree. ------------------------------------------------------------------------ r215316 | dim | 2010-11-14 21:23:02 +0100 (Sun, 14 Nov 2010) | 2 lines Add macros to define static instances of VNET_DEFINE and DPCPU_DEFINE.