versions derived from /usr/ports/audio/oss.
The particular headers used were taken from the
attic/drv/oss_allegro directory and are mostly identical
to the previous files.
The Maestro3 driver is now free from the GPL.
NOTE: due to lack of testers this driver is being
considered for deprecation and removal.
PR: kern/153920
Approved by: jhb (mentor)
MFC after: 2 weeks
profiling and kernel profiling. To enable kernel profiling one has to build
kgmon(8). I will enable the build once I managed to build and test powerpc
(32-bit) kernels with profiling support.
- add a powerpc64 PROF_PROLOGUE for _mcount.
- add macros to avoid adding the PROF_PROLOGUE in certain assembly entries.
- apply these macros where needed.
- add size information to the MCOUNT function.
MFC after: 3 weeks, together with r230291
entries on one client when a directory was renamed on another client. The
root cause for the stale entry being trusted is that each per-vnode nfsnode
structure has a single 'n_ctime' timestamp used to validate positive name
cache entries. However, if there are multiple entries for a single vnode,
they all share a single timestamp. To fix this, extend the name cache
to allow filesystems to optionally store a timestamp value in each name
cache entry. The NFS clients now fetch the timestamp associated with
each name cache entry and use that to validate cache hits instead of the
timestamps previously stored in the nfsnode. Another part of the fix is
that the NFS clients now use timestamps from the post-op attributes of
RPCs when adding name cache entries rather than pulling the timestamps out
of the file's attribute cache. The latter is subject to races with other
lookups updating the attribute cache concurrently. Some more details:
- Add a variant of nfsm_postop_attr() to the old NFS client that can return
a vattr structure with a copy of the post-op attributes.
- Handle lookups of "." as a special case in the NFS clients since the name
cache does not store name cache entries for ".", so we cannot get a
useful timestamp. It didn't really make much sense to recheck the
attributes on the the directory to validate the namecache hit for "."
anyway.
- ABI compat shims for the name cache routines are present in this commit
so that it is safe to MFC.
MFC after: 2 weeks
Make sure the non-SSE lowering for fences correctly clobbers EFLAGS.
PR11768.
In particular, this fixes segfaults during the build of devel/icu on
i386. The __sync_synchronize() builtin used for implementing icu's
internal barrier could lead to incorrect behaviour.
MFC after: 3 days
dhclient is no longer a real service, it is a helper script
for /etc/rc.d/netif and devd. Its direct invocation isn't
needed to bring the network up.
Approved by: jhb
NetBSD's rev 1.6 of this file, on !defined(SOFTFLOAT_FOR_GCC). These
functions are provided by libgcc, so we don't need them. This should
unbreak mips.
expressions properly. Some of the tests depend on the compiler
implementing C99's FENV_ACCESS pragma, and only commercial compilers
do; those tests are currently skipped. If any of the enabled tests
fail, then odds are the libm regression tests will fail also.
This should make it easier to diagnose reported problems on platforms
I don't have.
Currently, gcc passes all the tests that don't depend on FENV_ACCESS
on amd64 and sparc64. Clang fails a few on amd64 (see clang bug
11406). Both gcc and clang fare poorly on i386, which has well-known
issues.
the function bodies require only 2 to 10 instructions. However, it
leads to application binaries that refer to a private ABI, namely, the
softfloat innards in libc. This could complicate future changes in
the implementation of the floating-point emulation layer, so it seems
best to have programs refer to the official fe* entry points in libm.
original vendor, but we're using their heavily modified version.)
This brings in functions for long double emulation (both extended and
quad formats), which may be useful for testing, and also for replacing
libc/sparc64/fpu/.
error: variable 'clnt_stat' set but not used
Approved by: dim, cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC after: 3 days
error: variable 'parentrecnum' set but not used
Approved by: dim, cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC after: 3 days
error: variable 'temp' set but not used
Approved by: dim
Approved by: cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC after: 3 days
error: variable 'dirp' set but not used
error: variable 'dirplen' set but not used
Approved by: dim, cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC after: 3 days
error: variable 'current_cpu' set but not used
Approved by: dim, cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC after: 3 days
error: variable 'extra_async_bytes' set but not used
Approved by: dim, cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC After: 3 days
error: variable 'addrs' set but not used
Approved by: dim
Approved by: cperciva (mentor, blanket for pre-mentorship already-approved commits)
MFC After: 3 days
subject "Data corruption over NFS in -current". During investigation
of this, I came across an ugly bogusity in the new NFS client where
it replaced the cr_uid with the one used for the mount. This was
done so that "system operations" like the NFSv4 Renew would be
performed as the user that did the mount. However, if any other
thread shares the credential with the one doing this operation,
it could do an RPC (or just about anything else) as the wrong cr_uid.
This patch fixes the above, by using the mount credentials instead of
the one provided as an argument for this case. It appears
to have fixed Martin's problem.
This patch is needed for NFSv4 mounts and NFSv3 mounts against
some non-FreeBSD servers that do not put post operation attributes
in the NFSv3 Statfs RPC reply.
Tested by: Martin Cracauer (cracauer at cons.org)
Reviewed by: jhb
MFC after: 2 weeks
pci_get_vpd_readonly_method(). Previously the loop was always running
to completion and falling through to failing with ENXIO.
PR: kern/164313
Submitted by: Chuck Tuffli chuck tuffli net
MFC after: 1 week
