peter [Sat, 6 Mar 2004 00:44:59 +0000 (00:44 +0000)]
Add a missing part of jhb's previous commit. It looks like he had a
patch chunk rejected that he missed. This would manifest as a lock
assertion panic at boot (Giant not locked in kern_fork.c).
gad [Fri, 5 Mar 2004 23:10:49 +0000 (23:10 +0000)]
Have these instructions tell users to 'sh installworld_newk' instead
of './installworld_newk', because the scripts might not show up with
the +x bit set.
jhb [Fri, 5 Mar 2004 22:39:53 +0000 (22:39 +0000)]
- Push down Giant in exit() and wait().
- Push Giant down a bit in coredump() and call coredump() with the proc
lock already held rather than unlocking it only to turn around and
relock it.
jhb [Fri, 5 Mar 2004 22:37:32 +0000 (22:37 +0000)]
- Grab a share lock of the proctree lock while looking for a pid due to the
process group and session dereferences. Also, check that p_pgrp and
p_sesssion are NULL before dereferencing them.
- Push down Giant in fork1().
truckman [Fri, 5 Mar 2004 22:03:11 +0000 (22:03 +0000)]
Undo the merger of mlock()/vslock and munlock()/vsunlock() and the
introduction of kern_mlock() and kern_munlock() in
src/sys/kern/kern_sysctl.c 1.150
src/sys/vm/vm_extern.h 1.69
src/sys/vm/vm_glue.c 1.190
src/sys/vm/vm_mmap.c 1.179
because different resource limits are appropriate for transient and
"permanent" page wiring requests.
Retain the kern_mlock() and kern_munlock() API in the revived
vslock() and vsunlock() functions.
Combine the best parts of each of the original sets of implementations
with further code cleanup. Make the mclock() and vslock()
implementations as similar as possible.
Retain the RLIMIT_MEMLOCK check in mlock(). Move the most strigent
test, which can return EAGAIN, last so that requests that have no
hope of ever being satisfied will not be retried unnecessarily.
Disable the test that can return EAGAIN in the vslock() implementation
because it will cause the sysctl code to wedge.
Tested by: Cy Schubert <Cy.Schubert AT komquats.com>
njl [Fri, 5 Mar 2004 18:06:31 +0000 (18:06 +0000)]
A user can set tz_requested via the hw.acpi.thermal.tzX.active sysctl.
The previous logic meant that if a user sets it to a minimal cooling value
acpi_thermal will not use higher cooling levels. Reverse the logic so that
the user requesting a level (say, 2) also gets 0 - 1 also.
PR: kern/61592
Submitted by: Andrew Thompson <andy@fud.org.nz>
rwatson [Fri, 5 Mar 2004 17:35:28 +0000 (17:35 +0000)]
Put "failed to set signal flags properly for ast()" check under
DIAGNOSTIC instead of INVARIANTS. INVARIANTS is intended for tests
that don't substantially change code flow or behavior (passive), but
this test required locking both the proc lock and scheduler lock
in order to execute. It also appears to be a very advisory diagnostic
as opposed to an invariant violation.
bde [Fri, 5 Mar 2004 15:22:05 +0000 (15:22 +0000)]
Removed garbage:
- completely unused things
- all of rev.1.102 (C++ support). <sys/cdefs.h> is included by the
prerequisite <sys/types.h>. __BEGIN_DECLS/__END_DECLS has no effect
(except possibly if undefined behaviour is invoked using a hack like
defining away __inline) since this header doesn't really support any
extern functions.
markm [Fri, 5 Mar 2004 08:10:19 +0000 (08:10 +0000)]
Make NULL a (void*)0 whereever possible, and fix the warnings(-Werror)
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
mtm [Fri, 5 Mar 2004 08:03:04 +0000 (08:03 +0000)]
When this script included NetBSD specific logic, the NetBSD branch
included a start_precmd check for gated. The precommand was not
executed in the FreeBSD branch. When I did a mass removal of
NetBSD specific logic a while back this file apparently got only
a partial treatement. This bug did not have any functional consequences,
however, since the precommand was not declared to the rc.subr routines.
mtm [Fri, 5 Mar 2004 07:55:04 +0000 (07:55 +0000)]
The syslogd script should require that /var is cleaned before it runs.
Otherwise it could be in the situation where its log socket is removed
after it has started.
alc [Fri, 5 Mar 2004 04:46:32 +0000 (04:46 +0000)]
In the last revision, I introduced a physical contiguity check that is both
unnecessary and wrong. While it is necessary to verify that the page is
still free after dropping and reacquiring the free page queue lock, the
physical contiguity of the page can not change, making this check
unnecessary. This check was wrong in that it could cause an out-of-bounds
array access.
wpaul [Thu, 4 Mar 2004 23:04:02 +0000 (23:04 +0000)]
- Some older Atheros drivers want KeInitializeTimer(), so implement it,
along with KeInitializeTimerEx(), KeSetTimer(), KeSetTimerEx(),
KeCancelTimer(), KeReadStateTimer() and KeInitializeDpc(). I don't
know for certain that these will make the Atheros driver happy since
I don't have the card/driver combo needed to test it, but these are
fairly independent so they shouldn't break anything else.
- Debugger() is present even in kernels without options DDB, so no
conditional compilation is necessary (pointed out by bde).
- Remove the extra km_acquirecnt member that I added to struct kmutant
and embed it within an unused portion of the structure instead, so that
we don't make the structure larger than it's defined to be in Windows.
I don't know what crack I was smoking when I decided it was ok to do
this, but it's worn off now.
mtm [Thu, 4 Mar 2004 15:46:14 +0000 (15:46 +0000)]
Rev. 1.32 moved a comment to the wrong line. The hack refered to
in the comment applies to a decision that needs to be made in relation
to the year 2000.
In fact, that statement probably should be changed to be
more generic (getting the year from the current time perhaps). Otherwise,
starting in 2069 two digit year conversions in date(1) will start assuming
1900 instead of 2000. hehe.
bde [Thu, 4 Mar 2004 11:35:30 +0000 (11:35 +0000)]
Fixed the XXX'ed namespace pollution in rev.1.54 by using
<machine/limits.h> and __CHAR_BIT instead of <sys/limits.h> and CHAR_BIT.
some reason I didn't use the BSD spelling NBBY.
bde [Thu, 4 Mar 2004 11:20:02 +0000 (11:20 +0000)]
Don't manually optimize for 20 year old compilers by casting to u_int
to get a free check for negative ints. Rev.1.35 got my request to
remove the cast mostly backwards.
bde [Thu, 4 Mar 2004 10:56:29 +0000 (10:56 +0000)]
Fixed insertion sort errors in includes and prototypes. This was more
than a style bug for the includes -- queue.h is a prerequisite for
_lock.h and _mutex.h but was included after them.
Removed bogus prototype for fget_locked(). The prototype was originally
needed to support K&R but was bogotified by converting the function header
to new-style.
mtm [Thu, 4 Mar 2004 08:25:53 +0000 (08:25 +0000)]
Document the virecover_enable knob.
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.
njl [Thu, 4 Mar 2004 05:58:50 +0000 (05:58 +0000)]
Fix an off-by-one error and rework our EC space handler. Writing to address
0xFF would fail previously as AE_BAD_PARAMETER. It's unknown if this caused
any actual problems.
njl [Thu, 4 Mar 2004 05:57:41 +0000 (05:57 +0000)]
Part 2 of Project Evil: Pretend to be Windows 2000 for buggy ASL that
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.
njl [Thu, 4 Mar 2004 05:17:52 +0000 (05:17 +0000)]
Don't disable Cx support and throttling on machines with a P_BLK_LEN != 6
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.
njl [Thu, 4 Mar 2004 04:42:59 +0000 (04:42 +0000)]
Add a "quirks" value to disable quirks handling for a given boot.
Also, disable quirks if booting with a custom DSDT. Add a quirk
to disable loading ACPI so known bad systems can be completely
blacklisted.
bms [Thu, 4 Mar 2004 04:42:52 +0000 (04:42 +0000)]
Add a new option to mountd(8), -p <port>. This allows the user to specify
a known port for use in firewall rulesets; otherwise the port is chosen
at run-time by bindresvport().
wpaul [Thu, 4 Mar 2004 00:17:14 +0000 (00:17 +0000)]
Add sanity checks to the ndis_packet and ndis_buffer pool handling
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.
gad [Wed, 3 Mar 2004 22:56:41 +0000 (22:56 +0000)]
[this is just a forced commit to say:] The time_t-specific safety measure
added by the sparc64_installcheck target is mostly from Marcel, although
it includes some adjustments of my own...