These are largely syntactic sugar. However, they improve code
readability where an RB_FOREACH() or RB_FOREACH_REVERSE()
traversal has been interrupted and must be resumed. Performance
is improved by avoiding unnecessary traversal from the head node.
every time. The purpose of that register is unlikely output queue overflow
detection, so read it only when its last known (and probably stale now)
value signals overflow.
This reduces CPU load and lock congestion and rises bottleneck in CTL
while doing target mode via two 8Gbps ports from 100K to 120K IOPS.
- Fix LOR and possible lock recursion when handling high-power commands.
Introduce new lock to protect left power quota and list of frozen devices.
- Correct locking around xpt periph creation.
- Remove seems never used XPT_FLAG_OPEN xpt periph flag.
_KERNEL braces. Struct mount is only defined for the kernel build.
Reported and tested by: andreast
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
The hang occurred in nfsv4_setsequence() when it couldn't find an
available session slot and is fixed by checking for a forced dismount
in progress and just returning for this case.
MFC after: 1 month
shared vnode lock for VOP_PUTPAGES() as well. The only such
filesystem in the tree is ZFS, and it uses
vnode_pager_generic_putpages(), which performs the pageout with
VOP_WRITE().
Reviewed by: alc
Discussed with: avg
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
holding the vnode lock; vp->v_mount is checked first for NULL
equiality, and then dereferenced if not NULL. If vnode is reclaimed
meantime, second dereference would still give NULL. Change
VFS_PROLOGUE() to evaluate the mp once, convert MNTK_SHARED_WRITES and
MNTK_EXTENDED_SHARED tests into inline functions.
Reviewed by: alc
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
There were two bugs:
* If the initial lowest rate didn't go through the loop at least once,
the AMRR rate index would be the highest rate in the table
(eg the rix mapping to MCS15) but rate would stay at the default
value, namely 0.
This meant that the initial rate selection would be MCS15 _but_ the
node ni_txrate value would be MCS0.
* If the node is 11n, then break out of the loop correctly. Beforehand,
my initial 11n AMRR commit would immediately exit out as it would
fail the 11n check, then it would always fall through to the non-11n
rate which would then see if it was < 36mbit (ie, "72"), which would
always match. Hence, it'd always return MCS15.
Tested:
* Intel Centrino 2230 STA (local changes), STA mode
* Intel Wifi 5100, STA
This is a no-op for now!
* Add a new flag value for "there are no extra bits" for some random
field;
* Add a definition for the maximum number of calibration entries in
the calibration data cache in iwn_softc. It's not yet used.
* Add regulatory bands for the 2030 NIC.
Submitted by: Cedric Gross <cg@cgross.info>
and INDEX-NEW and compare them, not generate the same list of directories
from INDEX-OLD twice...
Pointy hats to: cperciva & everybody who didn't proofread EN-13:04 enough
to ILP32. Otherwise dtrace -G will attempt to use it on amd64 if it can't
determine which data model to use, which happens when -64 is omitted and
no object files are provided, e.g. with
# dtrace -G -n BEGIN
This would result in a linker error, but now works properly.
Also remove an unnecessary #ifdef.
MFC after: 2 weeks
makes FreeBSD halt but not poweroff (as expected when issuing a
shutdown from the VM manager). Fix this by using the same handler
for both "halt" and "poweroff".
NB: The "halt" signal seems to be used on XenServer only. The OSS
Xen toolstack (xl) uses "poweroff" instead.
Submitted by: Roger Pau Monné
Sponsored by: Citrix Systems R&D
Reviewed by: gibbs
MFC after: 2 days
the kernel itself: If building for the same architecture as the build host,
the kernel build assumes that the host toolchain is capable of building the
kernel. If it's not, "make kernel-toolchain" will bootstrap a new set of
tools that will work.
With this change the same assumptions are made for building kernel tools,
and the existing host toolchain is used to do the build (notably, the build
doesn't link the tools with the legacy libraries, which may not even exist).
If ever for some reason the host toolchain isn't capable of building the
kernel tools, then doing a "make kernel-toolchain" will bootstrap newer
tools to get the job done.
So when built as part of buildworld or kernel-toolchain, the kernel tools
are built using the XMAKE (via BMAKE) commands and environment. When built
as part of building just the kernel on a same-target host, the tools are
built using the new KTMAKE commands and environment. What doesn't jump
out at you in the diffs is that the difference between BMAKE and KTMAKE
is that BMAKE contains this magic line which changes how the build is done
because it changes what files get included for .include <bsd.prog.mk> and
other standard includes:
MAKEFLAGS="-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}"
and KTMAKE doesn't, and contains this instead:
TOOLS_PREFIX=${WORLDTMP}
Hopefully this brings the "how to build aicasm with the right toolchain"
saga to a conclusion that works in all usage scenarios that have
historically been supported.
The release.sh (based heavily on generate-release.sh) has been
used for the 9.2-RELEASE and 10.0-RELEASE cycles, so make sure
there is no confusion on what is currently being used by having
two similar scripts.
A big "thank you" to Nathan Whitehorn, the author of the
generate-release.sh script, for writing this utility.
No objection: nwhitehorn
MFC after: never
Sponsored by: The FreeBSD Foundation
