in ti_rxeof() instead. This doesn't really seem to provide much in the
way of a performance boost, and I'm pretty sure it can cause mbuf leakage
in some extreme cases.
dynamicly linked binaries to run in a chroot'd environment with "emul_path"
as the new root. The new behavior of loading interpreters is identical to the
principle of overlaying.
PR: 10145
Grammar and Spelling Reviewed by: mpp
While mpp kindly checked grammar and spelling, any technical errors
remaining in the man pages are entirely of mine.
into uipc_mbuf.c. This reduces three sets of identical tunable code to
one set, and puts the initialisation with the mbuf code proper.
Make NMBUFs tunable as well.
Move the nmbclusters sysctl here as well.
Move the initialisation of maxsockets from param.c to uipc_socket2.c,
next to its corresponding sysctl.
Use the new tunable macros for the kern.vm.kmem.size tunable (this should have
been in a separate commit, whoops).
print_AMD_info(), L2 internal cache is shown, as are AMD's special CPUID
infos:
CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping=12
Features=0x8021bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX>
AMD Features=0x808029bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SYSCALL,PGE,MMX,3DNow!>
PR: kern/12512
Submitted by: Louis A. Mamakos <louie@TransSys.COM>
Cache discarded default thread stacks for use in subsequent thread creations.
Create a red zone at the end of each stack (including the initial thread
stack), with the hope of causing a segfault if a stack overflows.
To activate these modifications, add -D_PTHREAD_GSTACK to CFLAGS in
src/lib/libc_r/Makefile. Since the modifications depend on the VM_STACK
kernel option, I'm not sure how to safely use growable stacks by default.
Testing, as well as algorithmic and stylistic comments are welcome.
returns 0 after ptrace() attach and/or detach doesn't quite quite
deliver a signal. Perhaps the process shouldn't be woken in this
case, but avoiding the problem is easy.
PR: 12247
Fixed a couple of places where mechanical fixing of compiler warnings
caused misspelling of NOLOCKF as NULL.
frames (or just insane received packet lengths generated due to errors
reading from the NIC's internal buffers). Anything too large to fit
safely into an mbuf cluster buffer is discarded and an error logged.
I have not observed this problem with my own cards, but on user has
reported it and adding the sanity test seems reasonable in any case.
Problem noted and patch provided by: Per Andersson <per@cdg.chalmers.se>
