work in unusual situations.
Also slightly optimize the command.
Submitted by: Jeremy Chadwick jdc@koitsu.org
Approved by: cperciva (implicit)
MFC after: 1 week
must be recalculated. The blk_check pass of suj checker explicitely marks
inodes which owned such blocks as needing block count adjustment. But
ino_adjblks() is only called by cg_trunc pass, which is performed before
blk_check. As result, the block use count for such inodes is left wrong.
This causes full fsck run after journaled run to still find inconsistencies
like 'INCORRECT BLOCK COUNT I=14557 (328 should be 0)' in phase 1.
Fix this issue by running additional adj_blk pass after blk_check, which
updates the field.
Reviewed by: jeff, mckusick
MFC after: 1 week
which was inadvertently caused by r236185: if SHLIBDIR is set using the
?= operator, it must be done *before* bsd.own.mk is included, otherwise
the default value is still used.
Note, bsd.lib.mk will take care of removing the copy in /usr/lib upon
installation, so no addition to ObsoleteFiles.inc is needed.
X-MFC-With: r236185
thing it was still used for was to set the "global default" password
hash. Since the stock auth.conf contained nothing but comments, the
global default was actually the first algorithm in crypt(3)'s list,
which happens to be DES; I take the fact that nobody noticed as proof
that it was not used outside of crypt(3).
The only other use in our tree was in the Kerberos support code in
in tinyware's passwd(1). I removed that code in an earlier commit;
it would not have compiled anyway, as it only supported Kerberos IV.
The auth_getval() function is now a stub that always returns NULL,
which has the same effect as a functional auth_getval() with an
empty auth.conf.
MFC after: 3 weeks
Initial support for the AMD barcelona chipsets has been available in the
gcc43 branch under GPLv2 but was not included when the Core 2 support
was brought to the system gcc.
AMD and some linux distributions (OpenSUSE) did a backport of the amdfam10
support and made them available. Unfortunately this is still experimental
and while it can improve performance, enabling the CPUTYPE may break some
C++ ports (like clang).
Special care was taken to make sure that the patches predate the GPLv3
switch upstream.
Tested by: Vladimir Kushnir
Reviewed by: mm
Approved by: jhb (mentor)
MFC after: 2 weeks
packets a cmsg of type IP_RECVTOS which contains the TOS byte.
Much like IP_RECVTTL does for TTL. This allows to implement a
protocol on top of UDP and implementing ECN.
MFC after: 3 days
There is no mac_addr in the mbuf for BSD.. cheat like
we are supposed to and use the csum field since our friend
the gif tunnel itself will never use offload.
then solves because of cache coherency issues. This fixes periodic error
messages on console and command timeouts.
- Patch SATA PHY configuration for 65nm SoCs to improve SNR same as
Linux does.
MFC after: 2 weeks
- Use CLOCK_MONOTONIC instead of CLOCK_REALTIME, because CLOCK_MONOTONIC
does not wrap into negative in near future. This fixes any potential
problems using "pthread_cond_timedwait()".
- Fix a bug where the "libusb_wait_for_event()" function computes an
absolute timeout instead of a relative timeout. USB transfers do
not depend on this timeout value.
- Add dependency towards LibPthread to Makefile, because LibUSB v1.0
needs this library to function correctly.
MFC after: 1 week
and bmsafemap dependency structures in inodedep_lookup() and
bmsafemap_lookup() respectively. The setup of these structures must
be done while holding the soft-dependency mutex. If the inodedep is
allocated first, it may be freed in the I/O completion callback when
the mutex is released to allocate the bmsafemap. If the bmsafemap is
allocated first, it may be freed in the I/O completion callback when
the mutex is released to allocate the inodedep.
To resolve this problem, bmsafemap_lookup has had a parameter added
that allows a pre-malloc'ed bmsafemap to be passed in so that it does
not need to release the mutex to create a new bmsafemap. The
softdep_setup_inomapdep() routine pre-malloc's a bmsafemap dependency
before acquiring the mutex and starting to build the inodedep with a
call to inodedep_lookup(). The subsequent call to bmsafemap_lookup()
is passed this pre-allocated bmsafemap entry so that it need not
release the mutex if it needs to create a new one.
Reported by: Peter Holm
Tested by: Peter Holm
MFC after: 1 week
code duplication in kern_close() and do_dup().
This is committed separately from the actual removal of the duplicated
code, as the combined diff was very hard to read.
Discussed with: kib
Tested by: pho
MFC after: 1 month
