in the non-_KERNEL case. This "fixes" applications that include
this "kernel-only" header and also include <strings.h> (or get
<strings.h> via the default _BSD_VISIBLE pollution in <string.h>.
In C++ there was a fatal error: the declaration specifies C linkage
but the implementation gives C++ linkage. In C there was only a
static/extern mismatch if the headers were included in a certain order
order, and a partially redundant declaration for all include orders;
gcc emits incomplete or wrong diagnostics for these, but only for
compiling with -Wsystem-headers and certain other warning options, so
the problem was usually not seen for C.
Ports breakage reported by: kris
Fixed a nearby bug. The "play it safe" code in dosysctl() was unsafe
because it overran the buffer by 1 if sysctl() filled all of the buffer.
Fixed a nearby style bug in output. Not just 1, but 2 extra newlines
were printed at the end by "vmstat -m" and "vmstat -z". Don't print
any newlines explicitly. This depends on 2 of the many formatting
bugs in the corresponding sysctls. First, the sysctls return an extra
newline at the end of the strings. This also messes up output from
sysctl(8). Second, the sysctls return an extra newline at the beginning
of the strings. This is good for separating the 2 tables output by
"vmstat -mz" and for starting the header on a new line in plain sysctl
output, but gives a bogus extra newline at the beginning for "vm -[m | z]"
and "sysctl -n [kern.malloc | vm.zone]".
Fixed some nearby style bugs in the source code:
- the same line that misspelled 0 as NULL also spelled NULL as 0.
- the size was doubled twice in the realloc loop.
- the "play it safe" comment was misleading. Terminating the buffer
is bogus because dosysctl() is only meant to work with sysctls that
return strings and the terminator is part of a string. However, the
kern.malloc sysctl has more than style bugs. It also doesn't return
a string. Termination is needed to work around this bug.
for Windows are deserialized miniports. Such drivers maintain their own
queues and do their own locking. This particular driver is not deserialized
though, and we need special support to handle it correctly.
Typically, in the ndis_rxeof() handler, we pass all incoming packets
directly to (*ifp->if_input)(). This in turn may cause another thread
to run and preempt us, and the packet may actually be processed and
then released before we even exit the ndis_rxeof() routine. The
problem with this is that releasing a packet calls the ndis_return_packet()
function, which hands the packet and its buffers back to the driver.
Calling ndis_return_packet() before ndis_rxeof() returns will screw
up the driver's internal queues since, not being deserialized,
it does no locking.
To avoid this problem, if we detect a serialized driver (by checking
the attribute flags passed to NdisSetAttributesEx(), we use an alternate
ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to
(*ifp->if_input)() on the NDIS SWI work queue. This guarantees the
packet won't be processed until after ndis_rxeof_serial() returns.
Note that another approach is to always copy the packet data into
another mbuf and just let the driver retain ownership of the ndis_packet
structure (ndis_return_packet() never needs to be called in this
case). I'm not sure which method is faster.
which have configuration files. This is just a cut-paste from newsyslog.8
with the following changes:
o Kill hard sentence breaks.
o Markup fixes.
o Wordsmithing.
based on the Madison core and targeting the low end of the spectrum.
Its clock frequency is 1Ghz, whereas Madison starts at 1.3Ghz. Since
the CPUID information is the same for Madison and Deerfield, we use
the clock frequency to identify the processor.
Supposedly the Deerfield only uses 62W, which seems to be less than
modern Xeon processors (about 70W) and about half what a Madison would
need.
the .for loop:
- Replaced four global variables in parse.c with one.
- Made Parse_FromString() accept the "lineno" as an argument.
- Fixed line numbering when there are escaped newlines in the
body of the .for loop.
Adopted from: NetBSD
On vnode backed md(4) devices over a certain, currently undetermined
size relative to the buffer cache our "lemming-syncer" can provoke
a buffer starvation which puts the md thread to sleep on wdrain.
This generally tends to grind the entire system to a stop because the
event that is supposed to wake up the thread will not happen until a fair
bit of the piled up I/O requests in the system finish, and since a lot
of those are on a md(4) vnode backed device which is currently waiting
on wdrain until a fair amount of the piled up ... you get the picture.
The cure is to issue all VOP_WRITES on the vnode backing the device
with IO_SYNC.
In addition to more closely emulating a real disk device with a
non-lying write-cache, this makes the writes exempt from rate-limited
(there to avoid starving the buffer cache) and consequently prevents
the deadlock.
Unfortunately performance takes a hit.
Add "async" option to give people who know what they are doing the
old behaviour.
only. This is a MAJOR incompatible change for the sparc64 platform,
but will not effect FreeBSD on other architectures.
Reviewed by: imp for UPDATING, freebsd-sparc for the change itself.
Nanobsd should make it very simple for people to create (CF-)disk images
for embedded us of FreeBSD.
Currently only works for 256MB disks. More agrressive shaving of the
build image can reduce that much further.
This may not be a generally valid configuration, but neither is relying
on the PCI clock to be stable.
The only currently known and supported hardware is the VPN14x1 from
Soekris, and since it has external clock, we fail safe(r) by using
it.
Unfortunately there is no way to probe this reliably.
