From the PR:
Certain MTA configurations mean that the notifications from
virecover keep bouncing; so here's a patch to allow administrators
to turn them off.
PR: conf/54910
Reminded by: ru
always expects to be running on some MS OS. A survey of ASL shows that
this is the 2nd most common expected OS value. (1st is Win98 and we don't
emulate its buggy ACPI support.) Our ACPI support is similar to Win2k,
also. Put this behavior under ACPICA_PEDANTIC so we can get back to our
previous behavior for OSV testing.
even though the spec mandates this. Some have a value of 5 to indicate
throttling + C2 and some have 7 to indicate an extra C3 state. Support
throttling if the value is >= 4, C2 for >= 5, and C3 for >= 6.
routines to guard against problems caused by (possibly) buggy drivers.
The RealTek 8180 wireless driver calls NdisFreeBuffer() to release
some of its buffers _after_ it's already called NdisFreeBufferPool()
to destroy the pool to which the buffers belong. In our implementation,
this error causes NdisFreeBuffer() to touch stale heap memory.
If you are running a release kernel, and hence have INVARIANTS et al
turned off, it turns out nothing happens. But if you're using a
development kernel config with INVARIANTS on, the malloc()/free()
sanity checks will scribble over the pool memory with 0xdeadc0de
once it's released so that any attempts to touch it will cause a
trap, and indeed this is what happens. It happens that I run 5.2-RELEASE
on my laptop, so when I tested the rtl8180.sys driver, it worked fine
for me, but people trying to run it with development systems checked
out or cvsupped from -current would get a page fault on driver load.
I can't find any reason why the NDISulator would cause the RealTek
driver to do the NdisFreeBufferPool() prematurely, and the same driver
obviously works with Windows -- or at least, it doesn't cause a crash:
the Microsoft documentation for NdisFreeBufferPool() says that failing
to return all buffers to the pool before calling NdisFreeBufferPool()
causes a memory leak.
I've written to my contacts at RealTek asking them to check if this
is indeed a bug in their driver. In the meantime, these new sanity checks
will catch this problem and issue a warning rather than causing a trap.
The trick is to keep a count of outstanding buffers for each buffer pool,
and if the driver tries to call NdisFreeBufferPool() while there are still
buffers outstanding, we mark the pool for deletion and then defer
destroying it until after the last buffer has been reclaimed.
Also note that these three files are intended to be short-term aids for
making this specific transition. They will probably disappear after
5.3-release (although the installworld_*k scripts do include some
general-purpose ideas that we might want to consider at a later date).
from a 32-bit value to a 64-bit value. This commit does not actually
change anything. It merely provides instructions, scripts, and a safety
measure in Makefile.inc1 for people who want to make the change.
The real change to 64-bit time_t's on sparc64 is scheduled to happen
on March 10th, assuming that so major problems are found between now
and then by early-adopters.
Reviewed by: freebsd-sparc64
is set, since some drivers with debug info can be very chatty.
Also implement DbgBreakPoint(), which is the Windows equivalent of
Debugger(). Unfortunately, this forces subr_ntoskrnl.c to include
opt_ddb.h.
they exit. Sometimes they simply can't (core-dump, for example).
So, when searching for a running program send standard error
output from ps(1) to never-never land.
# This should quite those
# ps: kvm_getprocs: No such user
# errors. Since ports use a duplicate rc.subr(8) you might
# still see this error from ports startup scripts.
Certain MTA configurations mean that the notifications from
virecover keep bouncing; so here's a patch to allow administrators
to turn them off.
PR: conf/54910
Submitted by: bms (with a minor cleanup)
