Poor ZFS send / receive performance due to snapshot
hold / release processing (by smh@)
Illumos ZFS issues:
3740 Poor ZFS send / receive performance due to snapshot
hold / release processing
MFV r252215:
Restore a previous behavior before r251646, where when destructing
ZFS snapshot, the ioctl would return ENOENT when it hit any of
them in the errlist (the new behavior was only return ENOENT when
all returns error).
Illumos ZFS issues:
3829 fix for 3740 changed behavior of zfs destroy/hold/release ioctl
MFC r251636: illumos #3749 zfs event processing should work on R/O root
filesystems
This log is a modified version of the original one written by gibbs@,
to account for changes made during the illumos RTI process.
Allow ZFS asynchronous event handling to proceed even if the root file
system is mounted read-only. This restriction appears to have been put
in place to avoid errors with updating the configuration cache file.
However:
o The majority of asynchronous event handling does not involve
configuration cache file updates.
o The configuration cache file need not be on the root file system,
so the check was not complete.
o Other classes of errors (e.g. file system full) can also prevent
a successful update yet do not prevent asynchronous event processing.
o Configurations such as NanoBSD never have a read-write root,
so ZFS event processing is permanently disabled in these systems.
o Failure to handle asynchronous events promptly can extend the
window of time that a pool is in a critical state.
At worst, a missed configuration cache update will force the operator to
perform a manual "zfs import" (note -f is not required) to inform the
system about a newly created pool. To minimize the likelihood of this
rare occurrence, configuration cache write failures now emit FMA events
(via devctl) so the operator can take corrective action, and the write
is retried every 5 minutes. The retry interval, in seconds, is tunable
via the sysctl "vfs.zfs.ccw_retry_interval".
As a side effect of reporting configuration cache events, other sysevents,
such as re-silver start/stop, are now also reported via devctl.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:
o As is done in zfs_fm.c, provide a manual declaration for
devctl_notify(). Both declarations could be combined
into spa_impl.h, but the declaration is fault management
related, not spa specific. sys/fm/fs/zfs.h would be ideal
if it weren't so public and reserved for FMA string
definitions. I'm open to suggestions on how to improve
this nit while minimizing our divergence from Solaris.
o Use devctl_notify() to implement sysevent support in
spa_event_notify(). The subsystem is EC_ZFS so that
these events can never collide with those emitted in
zfs_fm.c.
o Add the sysctl "vfs.zfs.ccw_retry_interval". The value
defaults to 5 minutes and is used to rate limit, on a
per-pool basis, configuration cache file write attempts.
o Modify spa_async_dispatch to honor configuration cache
write limiting. If other events are pending, a configuration
cache write will be attempted at the same time, so the
rate limiting only applies when the asynchronous dispatch
system is otherwise idle. Async events should be rare
(e.g. device arrival/departure) and configuration cache
writes rarer, so a more complicated system to strictly
honor the retry limit seems unwarranted.
o Remove check in spa_async_dispatch() for the root file
system being read-write.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c:
Instead of silently ignoring configuration cache write
failures, report them via a new FMA event as well as
to the console. The current zfs_ereport_post() doesn't
allow arbitrary name=value pairs to be appended to the
report, so the configuration cache file name is only
available on the console output. This limitation should
be addressed in a future update.
Note: This error report is only posted once per incident,
to avoid spamming.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h:
Add a hrtime_t to the spa data structure to track the
time (via gethrtime()) of the last configuration cache file
write failure. This is referenced in spa_async_dispatch()
to effect the rate limiting.
sys/cddl/contrib/opensolaris/uts/common/sys/fm/fs/zfs.h:
Add FM_EREPORT_ZFS_CONFIG_CACHE_WRITE as an ereport class.
Submitted by: gibbs
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
Eric Schrock <eric.schrock@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
MFC r251635: illumos #3747 txg commit callbacks don't work
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:
Fix commit callbacks by moving them to the task's list.
Previously, list_move_tail() returned without doing anything because
the task list was passed as the source rather than destination.
cddl/contrib/opensolaris/cmd/ztest/ztest.c:
Check the commit callback threshold correctly.
Submitted by: will
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
MFC r251634: illumos #3745 zpool create should treat -O mountpoint and -m the same
cddl/contrib/opensolaris/cmd/zpool/zpool_main.c: (change 644608)
This allows specifying a mountpoint using the latter form and having
its value checked and used as it would be using the former form.
As a consequence of this change:
1. The mountpoint property is set in the fsprops nvlist prior
to creating the pool, rather than being set after creating
the pool. To me, this is the proper approach, since it
avoids creating the pool if the mountpoint setting would
cause the command to fail.
2. The mountpoint property, unlike all others, can be specified
more than once. Only the last setting takes effect. This
is to avoid breaking potential existing users that specify
-m more than once.
Submitted by: will
cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c
Fix "zpool create -R <whatever> -m <whatever>". Ever since
change 644608, this has been broken. The problem is that some
old code in libzfs_pool.c would force a pool's mountpoint to
"/" when creating a pool with an altroot. That probably
implemented some old policy decision regarding altroots, but it
conflicts with the current manpage. It also had no effect
until 644608, because the zpool command would _always_ change
the pool's mountpoint after creating it. The solution is to
delete the old code from libzfs_pool.c.
Submitted by: asomers
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
MFC r251632: illumos #3743 zfs needs a refcount audit
Audit zap cursor usage and correct missing calls to zap_cursor_fini().
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:
Correct early exit handling of several functions that
previously failed to close a cursor prior to returning.
Submitted by: gibbs
Audit holders of dmu_bufs and correct missing calls to dmu_buf_rele().
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:
Correct early exit handling of several functions that
previously failed to release a dmu_buf prior to returning.
Submitted by: will
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
Eric Schrock <eric.schrock@delphix.com>,
George Wilson <george.wilson@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
MFC r251631: illumos #3742 zfs comments need cleaner, more consistent style
- Make more of ZFS's comments use a natural English writing flow.
- Break up long paragraphs, fix various typos and spelling errors.
- Don't prefix a function description with its name when the function
definition immediately follows.
- Remove useless comments.
- Add extra whitespace where it makes the comments more readable.
New comments were separated from this change and added in r251629.
Submitted by: asomers, gibbs, will
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
George Wilson <george.wilson@delphix.com>,
Eric Schrock <eric.schrock@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
Embellish the comments in various components of ZFS. Move some comments
around closer to what they describe. Specifically, answer the questions:
- What are some of the edge cases of the dbuf state machine?
- What does a txg quiesce do?
- When does the DMU notify threads waiting on txg's that they may
proceed?
- How do the calculations for RAIDZ map allocations work?
- What process do the RAIDZ I/O start and done callbacks follow?
While here, adjust the function prototype of dmu_zfetch.c:dmu_zfetch_colinear()
to match its comment which describes its return as a boolean.
Submitted by: asomers, gibbs, will
Reviewed by: Matthew Ahrens <mahrens@delphix.com>,
Eric Schrock <eric.schrock@delphix.com>,
Christopher Siden <christopher.siden@delphix.com>
Sponsored by: Spectra Logic
Not only this is a bit cleaner, it allows multiple instances of hostapd to be
running on the system host, useful for simultaneous dual-band WiFi.
This is similar to ifconfig_wlanX="WPA" but it uses /etc/hostapd-wlanX.conf.
Compatibility with hostapd_enable=YES/NO was kept.
MFC: r252067
Since some NFSv4 servers enforce the requirement for a reserved port#,
enable use of the (no)resvport mount option for NFSv4. I had thought
that the RFC required that non-reserved port #s be allowed, but I couldn't
find it in the RFC.
MFC r241214 (by jkim):
Do not install incomplete unwind.h from clang. This header file was meant
to be a wrapper for the canonical system header file. Unfortunately, we do
not have one (yet) and some times it is causing weird failures when clang
is used for building ports. More complete and correct file will come from
libcxxrt in the future.
Discussed with: dim, kib, theraven
MFC r246705 (by andrew):
Allow us to build clang for ARM EABI. Clang and llvm use the
arm-gnueabi-freebsd10.0 triple for EABI. Use this when we are on arm or
armv6 and are building for EABI.
Reviewed by: dim
MFC r248548 (by andrew):
Pull in r177252 from upstream clang trunk:
Make sure to use same EABI version for external assembler as for
integrated as.
This allows us to use gcc on a world built with clang on ARM.
MFC r249423:
Upgrade our copy of llvm/clang to trunk r178860, in preparation of the
upcoming 3.3 release (branching and freezing expected in a few weeks).
Preliminary release notes can be found at the usual location:
<http://llvm.org/docs/ReleaseNotes.html>
An MFC is planned once the actual 3.3 release is finished.
MFC r249817:
Pull in r180121 from upstream llvm trunk:
LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make
sure that the order in which the elements are scalarized is the same
as the original order.
This fixes a miscompilation in FreeBSD's regex library.
This should fix lib/libc/regex/regcomp.c at -O3 with clang 3.3 r178860
on CPUs with SSE. Before this change, the vectorizer could incorrectly
rearrange the second loop in computejumps(), leading to possibly invalid
entries in the re_gets::charjump table.
The net result was that for example "sed s/@CC@/foo/" failed to work
correctly, leading to trouble with many configure scripts.
MFC r250217:
Allow building clang on older FreeBSD releases, where log2() does not
exist yet. With this change, I have verified that building head on
8.1-RELEASE works.
Noticed by: Ryan Stone <rysto32@gmail.com>
MFC r250593:
Pull in r181286 from upstream llvm trunk:
LoopVectorize: getConsecutiveVector must respect signed arithmetic
We were passing an i32 to ConstantInt::get where an i64 was needed and we must
also pass the sign if we pass negatives numbers. The start index passed to
getConsecutiveVector must also be signed.
Should fix PR15882.
This should fix Firefox crashes some people have been reporting, when it
is compiled with -O3.
MFC r250616:
Use an ugly hack to get around bootstrapping problems when building
clang on head between r239347 and r245428.
The former revision introduced CLOCK_PROCESS_CPUTIME_ID as a clock id
for the clock_gettime() function and friends, but it was only added in
<sys/time.h>, not in <time.h>. Any program including <time.h> would
therefore not be able to use CLOCK_PROCESS_CPUTIME_ID, even though the
value of _POSIX_CPUTIME indicates its existence. The latter revision
synchronized the defines again.
Work around this problem by defining the id on the command line for the
particular .cpp file that needs it. If the id ever changes value, this
hack will need to be updated.
MFC r250997:
Pull in r182656 from upstream llvm trunk:
LoopVectorize: LoopSimplify can't canonicalize loops with an
indirectbr in it, don't assert on those cases.
Fixes PR16139.
This should fix clang assertion failures when optimizing at -O3, similar
to:
Assertion failed: (TheLoop->getLoopPreheader() && "No preheader!!"),
function canVectorize, file
contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp, line 2171.
Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de>
PR: ports/178332, ports/178977
MFC r251216 (by ed):
Pull in r183033 and r183036 from LLVM trunk:
Add support for optimized (non-generic) atomic libcalls.
For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc)
provide atomic functions that pass parameters by value and return
results directly.
libgcc and libcompiler-rt only provide optimized libcalls for
__atomic_fetch_*, as generic libcalls on non-integer types would make
little sense. This means that we can finally make __atomic_fetch_*
work
on architectures for which we don't provide these operations as
builtins
(e.g. ARM).
This should fix the dreaded "cannot compile this atomic library call
yet" error that would pop up once every while.
This should make it possible for me to get C11 atomics working on all of
our platforms.
MFC r251662:
Upgrade our copy of llvm/clang to 3.3 release.
Release notes are still in the works, these will follow soon.
MFC r251761:
Pull in r181620 from llvm trunk:
[ms-inline asm] Fix a crasher when we fail on a direct match.
The issue was that the MatchingInlineAsm and VariantID args to the
MatchInstructionImpl function weren't being set properly. Specifically, when
parsing intel syntax, the parser thought it was parsing inline assembly in the
at&t dialect; that will never be the case.
The crash was caused when the emitter tried to emit the instruction, but the
operands weren't set. When parsing inline assembly we only set the opcode, not
the operands, which is used to lookup the instruction descriptor.
rdar://13854391 and PR15945
Also, this commit reverts r176036. Now that we're correctly parsing the intel
syntax the pushad/popad don't match properly. I've reimplemented that fix using
a MnemonicAlias.
Pull in r183907 from llvm trunk:
X86: Make the cmov aliases work with intel syntax too.
These commits make a number of Intel-style inline assembly mnemonics
aliases (occurring in several ports) work properly, which could cause
assertions otherwise.
Reported by: kwm, bapt
MFC r251785 (by ed)
Pull in r184040 from upstream clang trunk:
Emit native implementations of atomic operations on FreeBSD/armv6.
Just like on Linux, FreeBSD/armv6 assumes the system supports
ldrex/strex unconditionally. It is also used by the kernel. We can
therefore enable support for it, like we do on Linux.
While there, change one of the unit tests to explicitly test against
armv5 instead of armv7, as it actually tests whether libcalls are
emitted.
MFC r251790 (by andrew):
Pull in r183926 from LLVM trunk:
Allow clang to build __clear_cache on ARM.
__clear_cache is special. It needs no signature, but is a real function in
compiler_rt or libgcc.
Patch by Andrew Turner.
This allows us to build the __clear_cache function in compiler-rt.
MFC r252039:
Pull in r183984 from llvm trunk:
Make PrologEpilogInserter save/restore all callee saved registers in
functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has
this effect, and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
This obsoletes the ugly hack to libgcc's unwind code from r245272, and
should also work for other arches, so revert the hack too.
MFC r240780, r252468:
Make nfs_readdir() more careful about using response data, cached in global
buffer. For now it fixes bug when following `ls` command will return data
from previous one aborted by pager. Also it should allow to read several
directories same time, for example, for recursive tracerse.
Don't set IN_CHANGE and IN_UPDATE on inodes for potentially suspended
file systems.
Only set i_offset in the parent directory's i-node during a lookup for
non-LOOKUP operations.
Relax a VOP assertion for a DELETE lookup.
Move the code from ufs_lookup.c used to do dotdot lookup, into
the helper function. It is supposed to be useful for any filesystem
that has to unlock dvp to walk to the ".." entry in lookup routine.
MFC: r252483
Document that NFSv4 mounts won't work if hostid_enable="NO" is set
in /etc/rc.conf because the host uuid is used to uniquely identify
the client to the server.
This is a content change.
MFC: r252138
Add a new "-o" option to the gssd which forces gss_init_sec_context()
to use DES and the associated old style GSS initialization token.
This appears to be required for some non-FreeBSD servers to
get a kerberized NFS mount to work. Also, ignore some signals when daemonized,
which might fix the gssd from "disappearing" without leaving a core dump.
Given the tight timeframe for the FreeBSD9.2 release, I have
committed this while waiting for code review. I will commit
changes recommended by the review in a separate commit.
Add firmware replacement and activation support to nvmecontrol(8) through
a new firmware command.
NVMe controllers may support up to 7 firmware slots for storing of
different firmware revisions. This new firmware command supports
firmware replacement (i.e. firmware download) with or without immediate
activation, or activation of a previously stored firmware image. It
also supports selection of the firmware slot during replacement
operations, using IDENTIFY information from the controller to
check that the specified slot is valid.
Newly activated firmware does not take effect until the new controller
reset, either via a reboot or separate 'nvmecontrol reset' command to the
same controller.
Add log page support to nvmecontrol(8) through a new logpage command.
This includes pretty printers for all of the standard NVMe log pages
(Error, SMART/Health, Firmware), as well as hex output for non-standard
or vendor-specific log pages.
Also add missing static keyword that glebius@ fixed as part of r252302.
Fail any passthrough command whose transfer size exceeds the controller's
max transfer size. This guards against rogue commands coming in from
userspace.
Also add KASSERTS for the virtual address and unmapped bio cases, if the
transfer size exceeds the controller's max transfer size.
Use MAXPHYS to specify the maximum I/O size for nvme(4).
Also allow admin commands to transfer up to this maximum I/O size, rather
than the artificial limit previously imposed. The larger I/O size is very
beneficial for upcoming firmware download support. This has the added
benefit of simplifying the code since both admin and I/O commands now use
the same maximum I/O size.
Create #defines for NVME_CTRLR_PREFIX and NVME_NS_PREFIX for the "nvme"
and "ns" strings, rather than hardcoding the string values throughout the
nvmecontrol code base.
Add an nvme_function structure array, defining the name, C function and
usage message for each nvmecontrol command. This helps reduce some code
clutter both now and for future commits which will add logpage and
firmware support to nvmecontrol(8).
Also move helper function prototypes to the end of the header file, after
the per-command functions.
Also add missing static keyword that glebius@ fixed as part of r252302.
For ATA_PASSTHROUGH commands, pretend isci(4) supports multiword DMA
by treating it as UDMA.
This fixes a problem introduced in r249933/r249939, where CAM sends
ATA_DSM_TRIM to SATA devices using ATA_PASSTHROUGH_16. scsi_ata_trim()
sets protocol as DMA (not UDMA) which is for multi-word DMA, even
though no such mode is selected for the device. isci(4) would fail
these commands which is the correct behavior but not consistent with
other HBAs, namely LSI's.
smh@ did some further testing on an LSI controller, which rejected
ATA_PASSTHROUGH_16 commands with mode=UDMA_OUT, even though only
a UDMA mode was selected on the device. So this precludes adding
any kind of mode detection in CAM to determine which mode to use on
a per-device basis.
MFC r248774: accept(2): Mention inheritance of O_ASYNC and signal
destination.
While almost nobody uses O_ASYNC, and rightly so, the inheritance of the
related properties across accept() is a portability issue like the
inheritance of O_NONBLOCK.
MFC r248349: sh: Recognize "--" and explicitly reject options in wait
builtin.
If syntactically invalid job identifiers are to be taken as jobs that exited
with status 127, this should not apply to options, so that we can add
options later if need be.
MFC r248692: sh(1): Mention possible ambiguities with $(( and ((.
In some other shells, things like $((a);(b)) are command substitutions.
Also, there are shells that have an extension ((ARITH)) that evaluates an
arithmetic expression and returns status 1 if the result is zero, 0
otherwise. This extension may lead to ambiguity with two subshells starting
in sequence.
MFC/backport core kernel and userspace parts of r237263 (TCP_OFFLOAD
rework). MFC r237563, r239511, r243603, r245915, r245916, r245919,
r245921, r245922, r245924, r245925, r245932, r245934 too.
Build tested with make universe.
r237263:
- Updated TOE support in the kernel.
...
r237563:
Fix clang warning when compiling iw_cxgb.
r239511:
Correctly handle the case where an inp has already been dropped by the time
the TOE driver reports that an active open failed. toe_connect_failed is
supposed to handle this but it should be provided the inpcb instead of the
tcpcb which may no longer be around.
r243603:
Make sure that tcp_timer_activate() correctly sees TCP_OFFLOAD (or not).
r245915:
Heed SO_NO_OFFLOAD.
r245916:
Teach toe_4tuple_check() to deal with IPv6 4-tuples too.
r245919:
Add TCP_OFFLOAD hook in syncache_respond for IPv6 too, just like the one
that exists for IPv4.
r245921:
There is no need to call into the TOE driver twice in pru_rcvd (tod_rcvd
and then tod_output right after that).
r245922:
Avoid NULL dereference in nd6_storelladdr when no mbuf is provided. It
is called this way from a couple of places in the OFED code. (toecore
calls it too but that's going to change shortly).
r245924:
Move lle_event to if_llatbl.h
lle_event replaced arp_update_event after the ARP rewrite and ended up
in if_ether.h simply because arp_update_event used to be there too.
IPv6 neighbor discovery is going to grow lle_event support and this is a
good time to move it to if_llatbl.h.
The two in-tree consumers of this event - OFED and toecore - are not
affected.
r245925:
Generate lle_event in the IPv6 neighbor discovery code too.
r245932:
Teach toe_l2_resolve to resolve IPv6 destinations too.
r245934:
Add checks for SO_NO_OFFLOAD in a couple of places that I missed earlier
in r245915.
MFC r252471:
Remove forced timeout of in-flight commands from mfi_timeout.
While this prevents commands getting stuck forever there is no way to guarantee
that data from the command hasn't been committed to the device.
In addition older mfi firmware has a bug that would cause the controller to
frequently stall IO for over our timeout value, which when combined with
a forced timeout often resulted in panics in UFS; which would otherwise be
avoided when the command eventually completed if left alone.
For reference this timeout issue is resolved in Dell FW package 21.2.1-0000.
Fixed FW package version for none Dell controller will likely vary.
Now that the necessary infrastructure is in place to ensure hhook points which
register after a khelp module will get hooked, move khelp module initialisation
to the earlier SI_SUB_KLD stage.
Move hhook's per-vnet initialisation to an earlier SYSINIT SI_SUB stage to
ensure all per-vnet related hhook initialisation is completed prior to any
virtualised hhook points attempting registration.
vnet_register_sysinit() requires that a stage later than SI_SUB_VNET be chosen.
There are no per-vnet initialisors in the source tree at this time which run
earlier than SI_SUB_INIT_IF. A quick audit of non-virtualised SYSINITs indicates
there are no subsystems pre SI_SUB_MBUF that would likely be interested in
registering a virtualised hhook point.
Settle on SI_SUB_MBUF as hhook's per-vnet initialisation stage as it's the first
overtly network-related initilisation stage to run after SI_SUB_VNET. If a
subsystem that initialises earlier than SI_SUB_MBUF ends up wanting to register
virtualised hhook points in future, hhook's use of SI_SUB_MBUF will need to be
revisited and would probably warrant creating a dedicated SI_SUB_HHOOK which
runs immediately after SI_SUB_VNET.
Add a private KPI between hhook and khelp that allows khelp modules to insert
hook functions into hhook points which register after the modules were loaded -
potentially useful during boot or if hhook points are dynamically registered.
Internalise handling of virtualised hook points inside
hhook_{add|remove}_hook_lookup() so that khelp (and other potential API
consumers) do not have to care when they attempt to (un)hook a particular hook
point identified by id and type.
Add support for non-virtualised hhook points, which are uniquely identified by
type and id, as compared to virtualised hook points which are now uniquely
identified by type, id and a vid (which for vimage is the pointer to the vnet
that the hhook resides in).
All hhook_head structs for both virtualised and non-virtualised hook points
coexist in hhook_head_list, and a separate list is maintained for hhook points
within each vnet to simplify some vimage-related housekeeping.
When a previous call to sbsndptr() leaves sb->sb_sndptroff at the start of an
mbuf that was fully consumed by the previous call, the mbuf ptr returned by the
current call ends up being the previous mbuf in the sb chain to the one that
contains the data we want.
This does not cause any observable issues because the mbuf copy routines happily
walk the mbuf chain to get to the data at the moff offset, which in this case
means they effectively skip over the mbuf returned by sbsndptr().
We can't adjust sb->sb_sndptr during the previous call for this case because the
next mbuf in the chain may not exist yet. We therefore need to detect the
condition and make the adjustment during the current call.
Fix by detecting the special case of moff being at the start of the next mbuf in
the chain and adjust the required accounting variables accordingly.
MFC r251960:
Since the gem pagefault handler relocks the vm object lock, other
thread might fault on the same GTT offset meantime and instantiate the
mapping. Recheck that the mgt device object still does not have a
page at the current offset after relocking, and return a possibly
installed page.
r249393:
Add pciids of the T5 based cards. The ones that I haven't tested with
cxgbe(4) are disabled for now. This will change.
r249627:
cxgbe/tom: Update the CLIP table on the chip when there are changes
to the list of IPv6 addresses on the system. The table is used for
TOE+IPv6 only.
r249629:
cxgbe(4): Refuse to install T5 firmwares on a T4 card (and vice versa).
r250090:
cxgbe(4): Some updates to shared code.
r250092:
- Provide accurate ifmedia information so that 40G ports/transceivers are
displayed properly in ifconfig, etc.
- Use the same number of tx and rx queues for a 40G port as for a 10G port.
r250093:
Attach to the T580 (2 x 40G) card.
r250117:
Fix DDP breakage introduced in r248925. Bitwise OR has higher
precedence than ternary conditional.
r250218:
cxgbe/tom: Do not use M_PROTO1 to mark rx zero-copy mbufs as special.
All the M_PROTOn flags are clobbered when an mbuf is appended to the
socket buffer.
r250221:
cxgbe: Switch to a better way to install firmware.
r250614:
Deal correctly with 40G ports that don't have any transceiver plugged
in. Do not claim that they have unknown tranceivers.
r251213:
cxgbe(4): Some more debug sysctls. These work on both T4 and T5 based
cards.
r251317:
cxgbe(4): t4fw_cfg must be explicitly loaded if the driver is being
loaded via loader.conf.
r251358:
cxgbe(4): Provide accurate hit count for filters on T5 cards. The
location within the TCB and the size have both changed.
r251434:
cxgbe(4): Never install a firmware if hw.cxgbe.fw_install is 0.
r251518:
cxgbe/tom: Fix bad signed/unsigned mixup in the stid allocator. This
fixes a panic when allocating a mixture of IPv6 and IPv4 stids.
r251638:
cxgbe/tom: Allow caller to select the queue (control or data) used to
send the CPL_SET_TCB_FIELD request in t4_set_tcb_field().
r252312:
Update T5 register ranges. This is so that regdump skips over registers
with read side-effects.
r252469:
Add a sysctl to get the number of filters available.
Return ENETDOWN instead of ENOENT when all lagg(4) links are
inactive when upper layer tries to transmit packet. This
gives better feedback and meaningful errors for applications.
Call sshd_precmd instead of sshd_configtest when the operator
requests reload or restart, which, in addition of testing the
configuration, will also generate host keys when they are not
present (previous behavior).
MFC r251482,251733:
r251482:
Correct setting TX random backoff register. This register is
implemented as a 10 bits linear feedback shift register so only
lower 10 bits are valid.
Because this register is used to initialize random backoff interval
register only when resolved duplex is half-duplex, it wouldn't have
caused issues in these days.
r251733:
Fix a typo introduced in r213280. IFM_OPTIONS macro should see
current media word.
MFC r251481:
Do not report current link status if driver is not running.
Reporting link status in driver has a side-effect that makes mii(4)
check current link status. mii(4) will call link status change
callback when it sees link state change. Normally this wouldn't
have problems. However, ASF/IPMI firmware can actively access PHY
regardless of driver's running state such that reporting link
status for not-running interface can generate meaningless link
UP/DOWN messages.
This change also makes dhclient think driver got a valid link
regardless of link establishment so it will bypass dhclient's
initial link status check. I think that wouldn't be issue
though.
MFC r252143:
When RX checksum offloading is active, AX88772B will prepend a
checksum header. The header contains a received frame length but
the defined length for AX88772B is different with other ASIX
controllers. When the RX checksum is off, AX88772B controller does
not prepend a checksum header so driver has to use normal header
length mask.
This change should fix RX errors when RX checksum offloading is
off.
lstewart [Sat, 29 Jun 2013 04:25:40 +0000 (04:25 +0000)]
MFC r251887:
Add new FOREACH_FROM variants of the queue(3) FOREACH macros which can
optionally start the traversal from a previously found element by passing the
element in as "var". Passing a NULL "var" retains the same semantics as the
regular FOREACH macros.
jhb [Fri, 28 Jun 2013 18:25:04 +0000 (18:25 +0000)]
MFC 252205:
If daily_status_security_inline is set, the rc value needs to be
forced to 3 so that the output of this script is always displayed.
In fact, setting this flag is identical to setting
daily_status_security_output to an empty string. To make the logic
less confusing, change the behavior of daily_status_security_inline
such that it just forces daily_status_security_output to an empty
string and then applies the normal logic.
jhb [Fri, 28 Jun 2013 16:07:20 +0000 (16:07 +0000)]
MFC 246120,246148,246206,246587,247411,247415:
Add fmemopen(3), open_memstream(3), and open_wmemstream(3) which provide
stdio FILE objects for memory buffers.
lstewart [Fri, 28 Jun 2013 03:39:54 +0000 (03:39 +0000)]
MFC r251725:
Fix a potential NULL-pointer dereference that would trigger if the hhook
registration site did not provide storage for a copy of the hhook_head struct.
jhb [Thu, 27 Jun 2013 20:35:39 +0000 (20:35 +0000)]
MFC 250418,252166:
Revision 233677 broke certain machines. Specifically, if the firmware/BIOS
assigned conflicting ranges to BARs then leaving the BARs alone could
result in one device stealing mmio accesses intended to go to a second
device. Prior to 233677 the PCI bus driver attempted to handle this case
by clearing the BAR to 0 depending on BARs based at 0 not decoding (which
is not guaranteed to be true). Now when a conflicting BAR is detected the
following steps are taken:
1) If hw.pci.realloc_bars (a new tunable) is enabled (default is disabled),
then ignore the current BAR setting from the firmware and attempt to
allocate a fresh resource range for the BAR.
2) If 1) failed (or was disabled), disable decoding for the relevant
BAR type (e.g. disable mem decoding for a memory BAR) and emit a
warning if booting verbose.
delphij [Thu, 27 Jun 2013 17:33:04 +0000 (17:33 +0000)]
Fix build: in a recent pf refactor (head@240233), pf_var.h was modified
to not include netinet/tcp_fsm.h, and HEAD tcpdump rely on this change
as the tcp_fsm.h will only be processed once.
Solve this by defining TCPSTATES earlier. This wouldn't cause breakage
should pf be merged in the future.
Noticed by: tinderbox via many
Pointy hat to: delphij
gjb [Thu, 27 Jun 2013 13:03:19 +0000 (13:03 +0000)]
MFC r230786, r246283, r251084, r251085, r251086:
r230786 (imp):
- Allow specification of build shell for the buildenv target.
r246283 (hrs) (partial):
- Add {WORLD,KERNEL}_FLAGS to [BTWK]MAKE.
r251084:
- r245757 introduced warning output if update method is set to
CVS_UPDATE or SUP_UPDATE.
- CVS exporter for stable/9/ is turned off for nearly one month
now.
- It is finally time to swing the ax at these update methods.
r251085:
- Fix typo introduced in r251084.
r251086:
- Remove references to CVS_UPDATE and SUP_UPDATE to catch up
with r251084.
marius [Thu, 27 Jun 2013 09:30:09 +0000 (09:30 +0000)]
MFC: r252180
Flag mpt(4) as supporting unmapped I/O; all necessary conversion actually
already has been done as part of r246713 (MFCed to stable/9 in r251874)
except for a comment update.
marius [Thu, 27 Jun 2013 09:23:53 +0000 (09:23 +0000)]
MFC: r251715
All of Oxford/PLX OX16PCI954, OXm16PCI954 and OXu16PCI954 share the
exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS
EX-41098-2 equipped with these), while at least the OX16PCI954 defaults
to a 1.8432 MHz one. According to the datasheets of these chips, the
only difference in PCI configuration space is that OXu16PCI954 have
a revision ID of 1 while the other two are at 0. So employ the latter
for determining the default clock rates of this family.
projects / FreeBSD / stable / 9.git / log