what's going on in cases where the "state engine" doesn't act as
expected, e.g. in the case of a list not being closed in the manual
page being parsed.
- Bump copyright year.
MFC after: 1 week
This confused the manual page -> hardware notes perl script somewhat and
resulted in part of the output for the stge(4) entry not to be present
in the hardware notes.
Noticed by: brueffer
mark system calls as being MPSAFE:
- Stop conditionally acquiring Giant around system call invocations.
- Remove all of the 'M' prefixes from the master system call files.
- Remove support for the 'M' prefix from the script that generates the
syscall-related files from the master system call files.
- Don't explicitly set SYF_MPSAFE when registering nfssvc.
- fix "No sound in KDE":
The problem is related to the implementation of Envy24(1712) hardware
mixer support in the driver. Envy24(1712) has very precise 36bit wide
hardware mixer, which is superior that vchans (software sound mixer in
the kernel). The driver supports Envy24(1712) hardware mixer, so up to
10 channels (5 stereo pairs) can be playback simultaneously.
However, there are problems with the implementation of Envy24(1712)
hardware mixer support in the driver, one of them is the problem with
"no sound in KDE":
When playing back several channels simultaneously and
stoping one of the channels, sound starts to stutter and
plays at very low speed.
Another problem is:
Playing back simultaneously more than one 24bit/32bit
sound file or 16bit sound file and 24bit/32bit sound
file doesn't work as expected.
Submitted by: "Konstantin Dimitrov" <kosio.dimitrov@gmail.com>
except for s_family (which is read-only once after it is set when the
structure is created).
- Mark svr4_sys_ioctl(), svr4_sys_getmsg(), and svr4_sys_putmsg() MPSAFE.
including to printf(). Using uintmax_t is also robust to further
extensions in both the C language and the bitwidth of kernel counters.
Tested on: i386 amd64 ia64
It is by no means expected to perform a complete test of the library
for correctness, but is meant to test the API to make sure libmp (or
libcrypto) updates don't totally break the library.
In the Heimdal distro, only kerberized telnet refers to INET6,
but we don't build it, we use contrib/telnet linked with the
Kerberos libs instead.
Tested with: cmp(1)
- Unicode 4.1 related changes:
- Add definitions for a new range of code points
U+1DC0..U+1DFF "Combining Diacritical Marks Supplement".
- Add U+04F6 and U+04F7 to the Cyrillic range.
- Mark U+034F "Combining Grapheme Joiner" as non-printable.
- Add new combining characters in the range U+0350..U+035F
to the section "Combining Diacritical Marks".
PR: misc/100212 [1]
Submitted by: "J.R. Oldroyd" <<fbsd AT opal.com>>
Reviewed by: "J.R. Oldroyd" <<fbsd AT opal.com>> (revised patch)
implementations and adjust some of the checks while I'm here:
- Add a new check to make sure we don't return from a syscall in a critical
section.
- Add a new explicit check before userret() to make sure we don't return
with any locks held. The advantage here is that we can include the
syscall number and name in syscall() whereas that info is not available
in userret().
- Drop the mtx_assert()'s of sched_lock and Giant. They are replaced by
the more general checks just added.
MFC after: 2 weeks
a count of all non-spin locks, not just lockmgr locks. This can give us a
much cheaper way to see if we have any locks held (such as when returning
to userland via userret()) without requiring WITNESS.
MFC after: 1 week
poll (i.e. call read_char() method) slave keyboards.
This workaround should fix problem with kbdmux(4) and
atkbd(4) not working in ddb(4) and mid-boot.
MFC after: 1 week
kern_fstatfs() so that it is still held when prison_enforce_statfs() is
called (since that function likes to poke and prod at the mountpoint
structure).
MFC after: 3 days
all other mtx_lock() operations to block. Previously, when the mutex was
destroyed, it would still have a valid value in mtx_lock(): either the
unowned cookie, which would allow a subsequent mtx_lock() to succeed, or a
pointer to the thread who destroyed the mutex if the mutex was locked when
it was destroyed.
MFC after: 3 days
kern_accept() and accept1(). If another thread closed the new file
descriptor and the first thread later got an error trying to copyout the
socket address, then it would attempt to close the wrong file object. To
fix, add a struct file ** argument to kern_accept(). If it is non-NULL,
then on success kern_accept() will store a pointer to the new file object
there and not release any of the references. It is up to the calling code
to drop the references appropriately (including a call to fdclose() in case
of error to safely handle the aforementioned race). While I'm at it, go
ahead and fix the svr4 streams code to not leak the accept fd if it gets an
error trying to copyout the streams structures.
map was obtained from the SMAP. SMAP is trustworthy, and the memory
extending feature is a band-aid for older systems where FreeBSD's methods
of detecting memory were not always trustworthy. This fixes the issue
where using hw.physmem could result in the ACPI tables getting trashed
breaking ACPI.
MFC after: 3 days
Tested on: i386
"feature" doesn't seem to be in the standards or elsewhere, and
it is against what we are used to in C and sh(1), so put the
paragraph under BUGS.
Pointed out by: dougb
MFC after: 3 days
code independent of the macro. This utility is just omitted
from the build as a whole by ../Makefile if MK_INET6 is set to false.
Pointed out by: ume
Tested with: cmp(1)
Move INET6 out of the RELEASE_CRUNCH conditional block
because it saves as little as 2% of the binary size and
IPv6 is rather popular today. (Some other binaries, e.g.,
telnetd, include INET6 for RELEASE_CRUNCH already.)
