no as a default. Sysinstall should be both less dangerous and less
annoying as a result of this change, though that's just my opinion
(since they're the defaults which annoy ME the least :).
present questinos with a different default answer. Somebody submitted
a patch to me once which did something this but I lost it (my bad) so
I'm just going to re-implement it with thanks to whomever it was who
gave me the idea.
aicasm is run on the build machine and therefore needs to be
compiled and linked against the headers and libraries (resp)
of the build machine. Since normally the default include
directories are search after any specified on the command
line, make sure we don't accidentally pick up machine
dependent headers from the kernel compile directory by
specifying /usr/include first.
This solves the (cross) build problem for ia64.
Approved by: gibbs
functions. If this flag is set, then no KTR log messages are issued.
This is useful for blocking excessive logging, such as with the internal
mutex used by the witness code.
- Use MTX_QUIET on all of the mtx_enter/exit operations on the internal
mutex used by the witness code.
- If we are in a panic, don't do witness checks in witness_enter(),
witness_exit(), and witness_try_enter(), just return.
Generate a version string that looks just like a real Linux one - almost :)
Use sbufs everywhere instead of sprintf(). Note that this is still imperfect,
as the code does not check whether the sbuf overflowed - but it'll still
work better than before, since if the sbuf overflows, the code now simply
copies out 0 bytes instead of causing a trap (or worse, corrupting kernel
structures)
vm86_trap() to return to the calling program directly. vm86_trap()
doesn't return, thus it was never returning to trap() to release
Giant. Thus, release Giant before calling vm86_trap().
from "PCMCIA SCSI MBH1040" to "PCMCIA SCSI MBH10401" "01". They are
based on the spc driver.
This will fix the conflicts of entry with REX-5536AM, REX-9836A,
and ICM PSC-2401 ("MBH10404" ones) which are based on stg driver.
The problem was pointed out in bsd-nomads several times since PAO2 days.
-Comment out the entry for "MBH10401" ones. The spc driver is
not supported yet.
-Add more comment about cards which has broken CIS
(some cards which has tuple of "PCMCIA SCSI MBH10404" "01").
Reported by: takachan@running-dog.net, y-nakaga@nwsl.mesh.ad.jp,
yuki@dayo.ne.jp
Obtained from: discussion in bsd-nomads mailing list
struct swblock entries by dividing the number of the entries by 2
until the swap metadata fits.
- Reject swapon(2) upon failure of swap_zone allocation.
This is just a temporary fix. Better solutions include:
(suggested by: dillon)
o reserving swap in SWAP_META_PAGES chunks, and
o swapping the swblock structures themselves.
Reviewed by: alfred, dillon
variables from i386 assembly language. The syntax is PCPU(member)
where member is the capitalized name of the per-cpu variable, without
the gd_ prefix. Example: movl %eax,PCPU(CURPROC). The capitalization
is due to using the offsets generated by genassym rather than the symbols
provided by linking with globals.o. asmacros.h is the wrong place for
this but it seemed as good a place as any for now. The old implementation
in asnames.h has not been removed because it is still used to de-mangle
the symbols used by the C variables for the UP case.
Previously, the syncer process was the only process in the
system that could process the soft updates background work
list. If enough other processes were adding requests to that
list, it would eventually grow without bound. Because some of
the work list requests require vnodes to be locked, it was
not generally safe to let random processes process the work
list while they already held vnodes locked. By adding a flag
to the work list queue processing function to indicate whether
the calling process could safely lock vnodes, it becomes possible
to co-opt other processes into helping out with the work list.
Now when the worklist gets too large, other processes can safely
help out by picking off those work requests that can be handled
without locking a vnode, leaving only the small number of
requests requiring a vnode lock for the syncer process. With
this change, it appears possible to keep even the nastiest
workloads under control.
Submitted by: Paul Saab <ps@yahoo-inc.com>
