caching on for a page just because we are clearing the writable bit in
the PTE: this is incompatible with the way pmap_vac_me_harder works,
and the code in the modified emulation handler doesn't know about
recalculating the cachable attributes (nor should it, IMO).
Also, if we are invalidating a page, flush its TLB entry; for some
reason we were only doing this when clearing the Write or modified
bits.
These patches together seem to solve the random seg-faults that were
still occuring occasionally under heavy paging.
a non-_STANDALONE environment (e.g. installboot(8)): internalize and
externalize the exec, program, and section headers as necessary.
Reviewed and OK'd by Christos.
unset on unload), similarily to what i386/machdep.c does #ifdef
COMPAT_SVR4. This makes the svr4 LKM actually work on i386.
XXX kind of ugly, but doing this more generic way would be overkill
restore %fs/%gs appropriately.
Fixes kern/14275 - compat svr4 works on i386 again :)
Thanks to MOCHIDA Shuji for initial investigation on the issue, that helped
to find the bug a lot.
and non-standard inttype-like types, pull in <sys/types.h> if
_KERNEL or _STANDALONE and <inttypes.h> otherwise, and use standard
inttype types.
Discussed with and OK'd by Christos.
the system's byte-order:
- host to {big,little}-endian {16,32}
- {big,little}-endian {16,32} to host
These are not intended to be used in libsa directly, but are rather
intended to be used by host tools which may use libsa routines (such
as loadfile()) which need to use explicit byte-ordering.
(either the current protection or the max protection) that reference
vnodes associated with a file system mounted with the NOEXEC option.
uvm_mmap(): Don't allow PROT_EXEC mappings to be established of vnodes
which are associated with a file system mounted with the NOEXEC option.
executable mappings. Stop overloading VTEXT for this purpose (VTEXT
also has another meaning).
- Rename vn_marktext() to vn_markexec(), and use it when executable
mappings of a vnode are established.
- In places where we want to set VTEXT, set it in v_flag directly, rather
than making a function call to do this (it no longer makes sense to
use a function call, since we no longer overload VTEXT with VEXECMAP's
meaning).
VEXECMAP suggested by Chuq Silvers.
as discussed in tech-net several weeks ago. It turned out that
KAME had already added this functionality to the IPv6 stack, so
I followed their example in adding the sysctl variables
net.inet.icmp.rediraccept and net.inet.icmp.redirtimeout.
device drivers:
- Various native device entries in cdevsw/bdevsw.
- Rework the interrupt infrastructure to provide more flexibility to
the platform-dependent back-end. Rewrite the "ofwgen" simulated
interrupt routines to reflect the changes.
- Clear out the BAT registers and set the fixed battable entries before
calling the platform init routine. The platform init routine is allowed
to set entries in the battable.
- Don't call the platform cons_init routine until after translation is
enabled -- we might need translation to work in order to access bus
space.
- calculate the offset and length of the postbl before byteswapping.
problem noted by der Mouse.
- use offsetof() to determine # of fields to calculate in initial
loop, rather than hard-coding in `52 fields'
- improve comments.
THAT accurate and microtime(9) is painlessly slow on i386 currently.
This speeds up small transfers much. The gain for large transfers
is less significant, but notable too.
Bottleneck was found by Andreas Persson (Re: kern/14246).
Performance improvement with PIII on 661 Mhz according to hbench (with
PIPE_MINDIRECT=8192):
buffersize before after
512 17 49
1024 33 110
2048 52 143
4096 77 163
8192 142 190
64K 577 662
128K 372 392
on PAGE_SIZE. The overhead of setting up Page Loan is pretty much constant
irregardless of page size, so it makes more sense to use fixed constant.
According to hbench, the overhead of Page Loan setup is still significantly
bigger than the performance gain for 4096 byte buffers on i386
(PIII/600Mhz). The difference is smaller on 386DX, but Page Loan is
still not faster for this case.
Also, there is some other code out there which expects 4KB writes
to not block even for 'blocking' write, since it works this
way on some other operating systems.
Partially addresses kern/14246 by Andreas Persson.
and it introduced problems (EBUSY error when opening the driver for
writing in securelevel >= 1, plus manipulating some unitialized data at
the end of chrtoblktbl[])
Make sure the CPUCLASS_686 entry has really 17 (i.e. 16 + default)
name entries as it's supposed to, so that code won't crash when
run on Intel CPUCLASS_686 processor which doesn't have name entry
in the table.
Reported and fix provided by Naoto Morishima in kern/14380.
from sppp_attach.
When destroying the interface, call sppp_detach for proper cleanup.
This avoids a crash from the slow timeout handler for no longer existing
interfaces (spotted by Rémi Zara).
thorpej