a regular basis. Adjust our linux emulation to conform. This will
cause more dirty pages to be left for the pagedaemon to deal with,
but our new low-memory handling code can deal with it. The linux
way appears to be a trend, and we may very well make MAP_NOSYNC the
default for FreeBSD as well (once we have reasonable sequential
write-behind heuristics for random faults).
(will be MFC'd prior to 4.3 freeze)
Suggested by: Andrew Gallatin
make sure that PG_NOSYNC is properly set. Previously we only set it
for a write-fault, but this can occur on a read-fault too.
(will be MFCd prior to 4.3 freeze)
hit on the client side and prevent the server side from retiring writes.
Pipeline operations turned off for all READs (no big loss since reads are
usually synchronous) and for NFS writes, and left on for the default bwrite().
(MFC expected prior to 4.3 freeze)
Testing by: mjacob, dillon
update native priority, it is diffcult to get right and likely
to end up horribly wrong. Use an honestly wrong fixed value
that seems to work; PUSER for user threads, and the interrupt
priority for ithreads. Set it once when the process is created
and forget about it.
Suggested by: bde
Pointy hat: me
1) blackholes.mail-abuse.org is the same as FEATURE(dnsbl), so specifying
it in the "Other DNS based black hole lists" section leads to confusion of
specifying it twice.
2) Formatting issues. If error diagnostic not enclosed in double quotes,
varius visual artefacts appearse like 1) no space after ; and 2) redundant
space after ? (in CGI request), so I add quotes where needed.
3) FEATURE(dnsbl) directly use error code 550 by default, so I made other
dnsbl variants use the same error code too.
4) Comment relays.* list as "open relays" list, just "other" word is not
explain enough.
Submitted by: ache
if an arriving packet belongs to us, also check that the packet arrived
through the correct interface. Skip this check if the packet was locally
generated.
fscale is a (64-bit) long. So just use a struct loadavg.
This fixes the recent failure of top on alphas:
top: sysctl(vm.loadavg...) failed: Cannot allocate memory
- use size_t for sizeof() so as to fix a few int/long warnings on alpha
Reviewed by: Thomas Moestl <tmoestl@gmx.net>
CVSrepo deletion of the previous attempt will be requested:
--original message--
Add the 'virtual nulmodem driver'
Particularly useful for debuging kernels using vmware.
If your name is Bruce evans and you are a WIZ at tty interfaces,
then you should probably rip this to shreds and offer lots of suggestions and
patches. I've been using this since 4.0-CURRENT and it's never caused
problems but I'm sure I got something wrong. This is similar to the pty/cty
device driver except that both sides are ttys. Even minor numbers
are side A and odd minor numbers are side B.
Work needs to be done regarding what happens to the other side when you
close a node.
to use with vmware, configure vmware to redirect COM2 out to side A of one
of these and boot a kernel with teh gdb remote port set to sio1.
AFTER dropping into the gdb kernel debugger in your test kernel,
fire up gdb with it's remote port pointing at the appropriate side B.
To catch all console output, you can boot the vmware kernel with a serial
console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it.
This is practically unaltered since pre 4.0 days except for
changes made along the way needed to make it compile, so any suggestions
or offers of total rewrites will be listenned to :-)
Even better formula from random() could not be intetgrated because rand_r()
supposed to store its state in the single variable (but table needed for
random() algorithm integration).
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate. In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.
Reviewed by: peter
When we recieve a fragmented TCP packet (other than the first) we can't
extract header information (we don't have state to reference). In a rather
unelegant fashion we just move on and assume a non-match.
Recent additions to the TCP header-specific section of the code neglected
to add the logic to the fragment code so in those cases the match was
assumed to be positive and those parts of the rule (which should have
resulted in a non-match/continue) were instead skipped (which means
the processing of the rule continued even though it had already not
matched).
Fault can be spread out over Rich Steenbergen (tcpoptions) and myself
(tcp{seq,ack,win}).
rwatson sent me a patch that got me thinking about this whole situation
(but what I'm committing / this description is mine so don't blame him).
