than only locking it if INVARIANTS is enabled. All the callers expect
smb_co_init() to return with the lock held.
Tested by: "Jiawei Ye" <leafy7382 at gmail>
for OpenSSL to load engines run-time, e.g. for using the opensc
engine port.
The OpenSSL Configure script enables DSO support on FreeBSD by
default, we just don't use the Configure script during OpenSSL builds
in the base system.
This is committed to -CURRENT now (before OpenSSL 0.9.8b import), so
it can be tested at bit in -CURRENT before being MFC'ed to 6-STABLE.
Prodded by: ale
PR: bin/79570
MFC after: 1 week
pointer: When vm_object_deallocate() sleeps because of a non-zero
paging in progress count on either object or object's shadow,
vm_object_deallocate() must ensure that object is still the shadow's
backing object when it reawakens. In fact, object may have been
deallocated while vm_object_deallocate() slept. If so, reacquiring
the lock on object can lead to a deadlock.
Submitted by: ups@
MFC after: 3 weeks
precedence uart. With my last change, it became a tie, and uart seems
to always win on my amd64. This was not my intention, so have sio be
just a tiny bit more preferred than uart.
Note: I'm not making any judgement on the merits of uart winning. I'm
just saying that if we want to change it, we do it on purpose.
pmap_remove_all() before rather than after the pmap is unlocked. At
present, the page queues lock provides sufficient sychronization. In the
future, the page queues lock may not always be held when free_pv_entry() is
called.
libmemstat(3) is used by vmstat (and friends) to produce more accurate
and more detailed statistics information in a machine-readable way,
and vmstat continues to provide the same text-based front-end.
This change should not be MFC'd.
Make three simplifications to pmap_ts_referenced():
Eliminate an initialized but otherwise unused variable.
Eliminate an unnecessary test.
Exit the loop in a shorter way.
FreeBSD repository and to clean up the license header so as to
not pollute the license with file function.
Zero all mailbox structures prior to use (just in case). Change
the outgoing mailbox count for INIT_FIRMWARE to be correct.
from a semantic point of view, but I notified the author of the driver
for confirmation. So far it at least fixes the build and should only
lead to not identifying or wrongly identifying a soundcard in the worst
case.
touch data outside the packet (previously we might touch 1 byte); it
also has the happy side effect of working around broken orinoco/agere
firmware that sends malformed association response frames
Help by: Vladimir Egorin
mark it as timed out. Don't try and free the config
request for read_cfg_header that times out because
it's still active. Put in code for the config reply
handler that will then free up timed out requests.
Fix the FC_PRIMITIVE_SEND completion to not try
and free a command twice. Dunno how this possibly
could have been working for awhile.
MFC after: 2 weeks
out ELS buffers but *don't* hang out commands,
we hang folks on the SAN because the LSI-Logic
f/w apparently sends back BUSY or QFULL or some
darn thing.
If we add command buffers, we have to respond to
them sensibly even if we don't have any upstream
listeners (scsi_targ or scsi_targ_bh), so put in
some local command reponse stuff.
MFC after: 2 weeks
sound cards with optional pseudo-multichannel playback.
It's based on snd_emu10k1 sound driver. Single channel version is available
from audio/emu10kx port since some time.
The two new ALSA header files (GPLed), which contain Audigy 2 ("p16v") and
Audigy 2 Value ("p17v") specific interfaces, are latest versions from ALSA
Mercurial repository.
This is not connected to the build yet.
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
latest version from Mercurial repository. It brings definition of some
additional Audigy 2 / Audigy 2 Value registers.
- Use new #defines from ALSA emu10k1.h
- Remove unused include files:
+ emu10k1-ac97.h was imported from ALSA and never used,
+ emu10k1.h was imported from Creative Linux emu10k1 driver, but only
AUDIGY_CODEBASE was used from it.
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
see which release you are installing (really which FreeBSD version the
installer is running, but that shouldn't matter in all normal cases).
PR: bin/100309
Submitted by: Joao Barros <joao.barros@gmail.com> (original version)
Idea from: FreeBSD ideas page
MFC after: 1 week
