available to the kernel (VM_KMEM_SIZE). The default (32 MB) is too low
when having 512 MB or more physical memory in a server environment. This is
relevant on systems where "panic: kmem_malloc: kmem_map too small" is a
problem.
value (200) is too low in some environments, causing a fatal
"panic: get_pv_entry: cannot get a pv_entry_t". The same panic might
still occur due to temporary shortage of free physical memory
(cf. PR i386/2431).
This eliminates a lot of #ifdef SMP type code. Things like _curproc reside
in a data page that is unique on each cpu, eliminating the expensive macros
like: #define curproc (SMPcurproc[cpunumber()])
There are some unresolved bootstrap and address space sharing issues at
present, but Steve is waiting on this for other work. There is still some
strictly temporary code present that isn't exactly pretty.
This is part of a larger change that has run into some bumps, this part is
standalone so it should be safe. The temporary code goes away when the
full idle cpu support is finished.
Reviewed by: fsmp, dyson
cost since it is only done in cpu_switch(), not for every exception.
The extra state is kept in the pcb, and handled much like the npx state,
with similar deficiencies (the state is not preserved across signal
handlers, and error handling loses state).
that I snuck in to our GDB last year. This allows you to debug headless
machines by sharing the console port between the debugger and the system
console. It's not 100% reliabile, but it works well. It's optional
and disabled by default.
Submitted by: Juniper Networks
bit 10 is the old bit for MTRR (presumably this changed, an older P5 I
have has got it, the newer cpus have the new MTRR bit set)
bit 11 is SEP (fast syscalls), bit 23 is MMX
Fill in the other reserved ones with a stub so that we can see them if
they turn up.
Obtained from: Intel AP-485 rev.06
top of the hardware interrupt handlers. Apparently this is slightly
faster with the bit scanning instruction that looks these up - this set of
changes reverts the original change.
Reviewed by: bde
CPU code-named `M2'.
- Use the result of cpuid instruction instead of DIR to identify
6x86MX cpu. DIR0 and DIR1 are not documented in the data sheet, and
cpuid instruction is enabled at reset time.
- Add a function, init_6x86MX() to initialize 6x86MX cpu. It supports
CPU_SUSP_HLT and CPU_IORT options. It always sets NC1 (640K - 1M is
not cached.), and enables L1 cache in write-back mode.
- Fix typo in the comment in identblue().
Changes to pmap.c for lapic_t lapic && ioapic_t ioapic pointers,
currently equal to apic_base && io_apic_base, will stand alone with the
private page mapping.
apic.h has defines like:
#define lapic__id lapic->id
Once private pages and "known virtual addr" mapping of the APICs is
ready all 'lapic__XXX' will be changed to 'lapic.XXX', and the defines
will be removed.
Changes to smp.h for lapic_t lapic && ioapic_t ioapic pointers,
currently equal to apic_base && io_apic_base, will stand alone with the
private page mapping.
Adjust the data port address by adding the two low order bits of
the register number. The address port takes only a word address
(i.e. ignores the two low order bits written to it).
mode 1. Omission of this bit makes all config register accesses fail in
on recent chip sets ...
(The problem was reported and debug output provided by: Steve Passe)
- vector.s <- stub called by i386/exception.s
- icu_vector.s <- UP
- apic_vector.s <- SMP
Split icu.s into UP and SMP specific files:
- ipl.s <- stub called by i386/exception.s (formerly icu.s)
- icu_ipl.s <- UP
- apic_ipl.s <- SMP
This was done in preparation for massive changes to the SMP INTerrupt
mechanisms. More fine tuning, such as merging ipl.s into exception.s,
may be appropriate.
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
be (eventually) architecture independent. It provides an emulation
of the ISA interrupt registration function register_intr(), but that
function does no longer manipulated the interrupt controller and
interrupt descriptor table, but calls the architecture dependent
function setup_icu() for that purpose.
After the ISA/EISA bus code has been modified to directly call the new
interrupt registartion functions (intr_create() and intr_connect()),
the emulation of register_intr() should be dropped.
The C level interrupt handler function should take a (void*) argument,
and the function pointer type (inthand2_t) should defined in some other
place than isa_device.h.
This commit is a pre-requisite for the removal of the PCI specific shared
interrupt code.
Reviewed by: dfr,bde
This is now the default, it delays most of the MP startup to the function
machdep.c:cpu_startup(). It should be possible to move the 2 functions
found there (mp_start() & mp_announce()) even further down the path once
we know exactly where that should be...
Help from: Peter Wemm <peter@spinner.dialix.com.au>
- The 1st (preparse_mp_table()) counts the number of cpus, busses, etc. and
records the LOCAL and IO APIC addresses.
- The 2nd pass (parse_mp_table()) does the actual parsing of info and recording
into the incore MP table.
This will allow us to defer the 2nd pass untill malloc() & private pages
are available (but thats for another day!).
panic( "xxxxx\n" );
to:
printf( "xxxxx\n" );
panic( "\n" );
For some as yet undetermined reason the argument to panic() is often NOT
printed, and the system sometimes hangs before reaching the panic printout.
So we hopefully at least print some useful info before the hang, as oppossed to
leaving the user clueless as to what has happened.
Remove "setdefs.h" and arrange to generate it automatically at
ELF kernel build time.
"gensetdefs.c" is a utility which scans a set of ELF object files
and outputs a line ``DEFINE_SET(name, length);'' for each linker
set that it finds. When generating an ELF kernel, this is run just
before the final link to generate "setdefs.h".
Remove the init_sets() function from "setdef0.c", and its call from
"machdep.c". Since "gensetdefs.c" calculates the length of each
set, it is no longer necessary in an ELF kernel to count the set
elements at kernel initialization time. Also remove "set_of_sets"
which was used for this purpose.
Link "setdef0" and "setdef1" into the kernel only if building for
ELF. Since init_sets() is no longer used, there is no need to link
them into an a.out kernel.
all uses of it with the equivalent calls to setbits().
This change incidentally eliminates a problem building ELF kernels
that was caused by SETBITS.
Reviewed by: fsmp, peter
Submitted by: bde
to fill in the nfs_diskless structure, at the cost of some kernel
bloat. The advantage is that this code works on a wider range of
network adapters than netboot. Several new kernel options are
documented in LINT.
Obtained from: parts of the code comes from NetBSD.
was stale.
Fixed initialization of gdt[] for the BDE_DEBUGGER case. APM entries
clobbered debugger entries if the debugger was loaded (APM is incompatible
with BDE_DEBUGGER) and unused entries were garbage if the debugger wasn't
loaded.
(eg: above 0xffc00000). Programs using /dev/kmem are implicitly racing
the kernel, and can get right up high in memory. I've been running
these for some time now, but with printfs. It's saved two panics at
least that I can remember.
md_regs being struct trapframe *. Do a npxsave() if needed and copy the
pcb rather than use the increasingly defunct savectx(). Copy %edi and
%ebp explicitly.
Submitted by: bde
XXX npxproc could be declared in npx.h so the externs with smp fruit
are not needed.
Remove TF_REGP() macro and use. The original reason (address space
problems due to having UPAGES in mapped into user space) is gone. It
looks cleaner without it.
- doesn't break my system.
- NOT yet verified on the affected motherboard.
Stifle an annoying dma_start busy message for the sound cards.
Submitted by: "John S. Dyson" <toor@dyson.iquest.net>
. It makes cd9660 root f/s working again.
. It makes CD9660 a new-style option.
. It adds support to mount an ISO9660 multi-session CD-ROM as the root
filesystem (the last session actually, but that's what is expected
behaviour).
Sigh. The CDIOREADTOCENTRYS did a copyout() of its own, and thus has
been unusable for me for this work. Too bad it didn't simply stuff
the max 100 entries into the struct ioc_read_toc_entry, but relied on
a user supplied data buffer instead. :-( I now had to reinvent the
wheel, and created a CDIOREADTOCENTRY ioctl command that can be used
in a kernel context.
While doing this, i noticed the following bogosities in existing CD-ROM
drivers:
wcd: This driver is likely to be totally bogus when someone tries
two succeeding CDIOREADTOCENTRYS (or now CDIOREADTOCENTRY)
commands with requesting MSF format, since it apparently
operates on an internal table.
scd: This driver apparently returns just a single TOC entry only for
the CDIOREADTOCENTRYS command.
I have only been able to test the CDIOREADTOCENTRY command with the
cd(4) driver. I hereby request the respective maintainers of the
other CD-ROM drivers to verify my code for their driver. When it
comes to merging this CD-ROM multisession stuff into RELENG_2_2 i will
only consider drivers where i've got a confirmation that it actually
works.
simplifies some assumptions and stops some code compile problems.
This should fix the compile hiccup in PR#3491, but smp kernel profiling
isn't likely to be fixed by this.
- one-liners all become inline.
- multi-liners become functions.
- FAST_IPI defines go away.
re-worked APICIPI_BANDAID code.
- now refered to as DETECT_DEADLOCK.
- on by default.
This code re-numbers PCI busses in the MP table to match PCI semantics
when the MP BIOS fails to do it properly.
Reviewed by: Peter Wemm <peter@spinner.DIALix.COM>
Peter Wemm <peter@spinner.DIALix.COM>, Steve Passe <smp@csn.net>
removed all the IPI_INTS code.
made the XFAST_IPI32 code default, renaming Xfastipi32 to Xinvltlb.
cleanup of i386/isa/isa_device.h to eliminate SMP dependancies:
made the id_irq member of struct isa_device an u_int.
made the id_drq member of struct isa_device an int.
removed all other '#ifdefs' concerning SMP & APIC_IO.
removed SMP/APIC_IO dependancies from if_ze.c.
Peter Wemm <peter@spinner.DIALix.COM>, Steve Passe <smp@csn.net>
removed all the IPI_INTS code.
made the XFAST_IPI32 code default, renaming Xfastipi32 to Xinvltlb.
There are various options documented in i386/conf/LINT, there is more to
come over the next few days.
The kernel should run pretty much "as before" without the options to
activate SMP mode.
There are a handful of known "loose ends" that need to be fixed, but
have been put off since the SMP kernel is in a moderately good condition
at the moment.
This commit is the result of the tinkering and testing over the last 14
months by many people. A special thanks to Steve Passe for implementing
the APIC code!
for syscalls, so one frame was lost in backtraces from syscalls.
This is handled better in the kernel by using a different mcount
entry point for profiling before the frame pointer is set up.
Expand RCSID().
Use .p2align instead of the ambiguous .align.
Added idempotency ifdef.
Removed unused macros ALTENTRY(), ALTASENTRY(), ASENTRY(), _MID_ENTRY.
Cleaned up formatting.
Reviewed by: jdp reviewed an old version
Obtained from: parts from NetBSD
have successfully built, booted, and run a number of different ELF
kernel configurations, including GENERIC. LINT also builds and
links cleanly, though I have not tried to boot it.
The impact on developers is virtually nil, except for two things.
All linker sets that might possibly be present in the kernel must be
listed in "sys/i386/i386/setdefs.h". And all C symbols that are
also referenced from assembly language code must be listed in
"sys/i386/include/asnames.h". It so happens that failure to do
these things will have no impact on the a.out kernel. But it will
break the build of the ELF kernel.
The ELF bootloader works, but it is not ready to commit quite yet.
were always in a tss; that tss just changed from the one in the
pcb to common_tss (who knows where it was when there was no curpcb?).
Not using the pcb also fixed the problem that there is no pcb in
idle(), so we now always get useful register values.
switching to a child for the first time was being counted twice. I think
this only affected unimportant statistics.
Simplified arg handling in fork_trampoline(). splz() doesn't actually
smash the registers of interest.
allow large systems to boot successfully with bounce buffers compiled
in. We are now limiting bounce space to 512K. The 8MB allocated for
a 512MB system is very bogus -- and that is now fixed.
the pv entries. This problem has become obvious due to the increase
in the size of the pv entries. We need to create a more intelligent
policy for pv entry management eventually.
Submitted by: David Greenman <dg@freebsd.org>
fork. (On my machine, fork is about 240usecs, vfork is 78usecs.)
Implement rfork(!RFPROC !RFMEM), which allows a thread to divorce its memory
from the other threads of a group.
Implement rfork(!RFPROC RFCFDG), which closes all file descriptors, eliminating
possible existing shares with other threads/processes.
Implement rfork(!RFPROC RFFDG), which divorces the file descriptors for a
thread from the rest of the group.
Fix the case where a thread does an exec. It is almost nonsense for a thread
to modify the other threads address space by an exec, so we
now automatically divorce the address space before modifying it.
nothing else will lower it until either much later, or never(?) for
kernel processes.
This basically re-fixes what Bruce fixed in rev 1.29 of kern_fork.c,
which was broken again now the child does not execute back up the fork()
calling tree.
Rename the PT* index KSTK* #defines to UMAX*, since we don't have a kernel
stack there any more..
These are used to calculate VM_MAXUSER_ADDRESS and USRSTACK, and really
do not want to be changed with UPAGES since BSD/OS 2.x binary compatability
depends on it.
space. (!)
Have each process use the kernel stack and pcb in the kvm space. Since
the stacks are at a different address, we cannot copy the stack at fork()
and allow the child to return up through the function call tree to return
to user mode - create a new execution context and have the new process
begin executing from cpu_switch() and go to user mode directly.
In theory this should speed up fork a bit.
Context switch the tss_esp0 pointer in the common tss. This is a lot
simpler since than swithching the gdt[GPROC0_SEL].sd.sd_base pointer
to each process's tss since the esp0 pointer is a 32 bit pointer, and the
sd_base setting is split into three different bit sections at non-aligned
boundaries and requires a lot of twiddling to reset.
The 8K of memory at the top of the process space is now empty, and unmapped
(and unmappable, it's higher than VM_MAXUSER_ADDRESS).
Simplity the pmap code to manage process contexts, we no longer have to
double map the UPAGES, this simplifies and should measuably speed up fork().
The following parts came from John Dyson:
Set PG_G on the UPAGES that are now in kernel context, and invalidate
them when swapping them out.
Move the upages object (upobj) from the vmspace to the proc structure.
Now that the UPAGES (pcb and kernel stack) are out of user space, make
rfork(..RFMEM..) do what was intended by sharing the vmspace
entirely via reference counting rather than simply inheriting the mappings.
convenient and makes life difficult for my next commit. We still need
an i386tss to point to for the tss slot in the gdt, so we use a common
tss shared between all processes.
Note that this is going to break debugging until this series of commits
is finished. core dumps will change again too. :-( we really need
a more modern core dump format that doesn't depend on the pcb/upages.
This change makes VM86 mode harder, but the following commits will remove
a lot of constraints for the VM86 system, including the possibility of
extending the pcb for an IO port map etc.
Obtained from: bde
by Alan Cox <alc@cs.rice.edu>, and his description of the problem.
The bug was primarily in procfs_mem, but the mistake likely happened
due to the lack of vm system support for the operation. I added
better support for selective marking of page dirty flags so that
vm_map_pageable(wiring) will not cause this problem again.
The code in procfs_mem is now less bogus (but maybe still a little
so.)
centric rather than VM-centric to fix a problem with errors not being
detectable when the header is read.
Killed exech_map as a result of these changes.
There appears to be no performance difference with this change.
Lookup isn't done every time the system goes idle now, but it can still
take > 1800 instructions in the worst case, so if cpu interrupts are kept
disabled then it might lose 20 characters of sio input at 115200 bps.
Fixed style in vm_page_zero_idle().
functions if DDB is available. The remaining occurences are usually
only inlined and thus not available in DDB.
I'm sure Bruce will have 23 additions to these 30 lines of code, but
at least it's a starting point. ;-)
address outside of the process's address space.
Now it matches its man page :-). Closes PR# 2682.
Discussed with: bde
Submitted by: Jonathan Lemon <jlemon@americantv.com>
print "at <not configured>" for iobase == -1 (autodetect not happens)
and not print anything for iobase == -2 (none)
Old code treat this two special config numbers as big port numbers.
supports All Cyrix CPUs, IBM Blue Lightning CPU and NexGen (now AMD)
Nx586 CPU, and initialize special registers of Cyrix CPU and msr of
IBM Blue Lightning CPU.
If revision of Cyrix 6x86 CPU < 2.7, CPU cache is enabled in
write-through mode. This can be disabled by kernel configuration
options.
Reviewed by: Bruce Evans <bde@freebsd.org> and
Jordan K. Hubbard <jkh@freebsd.org>
Print the stack pointer together with the frame pointer in the trap,
syscall and interrupt messages. The frame pointer is not very useful
for locating syscall args since syscall functions don't have a frame
pointer.
Print all the numbers in the trap, syscall and interrupt messages in
the default radix. The syscall number was confusing because it was
printed in decimal.
Use %#n format more and 0x%x less. 0x%x of course doesn't work with
a variable radix. ddb is now fairly consistent about using %+#n to
print all numbers. It omits the '+' for signed numbers the '#' in a
few cases (e.g., for function args) to save space.
at runtime.
etc/make.conf:
Nuked HAVE_FPU option.
lib/msun/Makefile:
Always build the i387 objects. Copy the i387 source files at build
time so that the i387 objects have different names. This is simpler
than renaming the files in the cvs repository or repeating half of
bsd.lib.mk to add explicit rules.
lib/msun/src/*.c:
Renamed all functions that have an i387-specific version by adding
`__generic_' to their names.
lib/msun/src/get_hw_float.c:
New file for getting machdep.hw_float from the kernel.
sys/i386/include/asmacros.h:
Abuse the ENTRY() macro to generate jump vectors and associated code.
This works much like PIC PLT dynamic initialization. The PIC case is
messy. The old i387 entry points are renamed. Renaming is easier
here because the names are given by macro expansions.
Changed it from 4 to 16 for i386's. It can be anything for i386's,
but compiler options limit it to a power of 2, and assembler and
linker deficiencies limit it to a small power of 2 (<= 16).
We use 16 in the kernel to get smaller tables (see Makefile.i386 and
<machine/asmacros.h>). We still use the default of 4 in user mode.
Use HISTCOUNTER instead of (*kcount) in the definition of KCOUNT()
for consistency with other macros.
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.
The system boots and can mount UFS filesystems.
Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.
Reviewed by: various people
Submitted by: Jeffery Hsu <hsu@freebsd.org>
complained so it cannot be entirely bad :-)
I include the email that probably explains it for people who already know:
> >Compiling with -O3 inlines functions. However the function that is being
> >inlined in makeinfo.c (add_word_args()) is a vararg function and must not be
> >inlined.
> >
> >The code in question is K&R style, and AFIK, there is no way for the compiler
> >to determine that the function uses vararg. Either change the code to use
> >prototypes, or use stdarg, or add a directive to prevent inlining.
>
> Not declaring a varargs function as varargs before it is used gives
> undefined behaviour.
>
> However, in practice the bug is probably in FreeBSD's <varargs.h>, which
> doesn't use gcc's __builtin_next_arg(). gcc should notice that it is
> used and not inline functions that have it. <stdarg.h.> uses it, but I
> think there's another gcc builtin that it should be using.
Patch attached. The ellipsis causes gcc to flag this as a varargs function,
and the name "__builtin_va_alist" is special cased in gcc to hide the last
argument in the arglist.
Reviewed by: bde & phk
Submitted by: jlemon@americantv.com (Jonathan Lemon)
I have code to calibrate the overhead fairly accurately, but there
is little point in using it since it is most accurate on machines
where an estimate of 0 works well. On slow machines, the accuracy
of DELAY() has a large variance since it is limited by the resolution
of getit() even if the initial delay is calibrated perfectly.
Use fixed point and long longs to speed up scaling in DELAY().
The old method slowed down a lot when the frequency became variable.
Assume the default frequency for short delays so that the fixed
point calculation can be exact.
Fast scaling is only important for small delays. Scaling is done
after looking at the counter and outside the loop, so it doesn't
decrease accuracy or resolution provided it completes before the
delay is up. The comment in the code is still confused about this.
Disabling npx0 works right now.
Don't reference `npxdriver' if npx0 is not configured. Not configuring
npx0 doesn't quite work yet.
Don't clear potential non-npx pcb flags in setregs().
not lazy-fault page table pages. Update the copyout support to take
that into account. This should fix some segfault problems on such
machines.
After a short test period, we'll move this into 2.2.
Submitted by: Stephen McKay <syssgm@devetir.qld.gov.au>
called early for console i/o. The timer is usually in BIOS mode
if it isn't explicitly initialized. Then it counts twice as fast
and has a max count of 65535 instead of 11932. The larger count
tended to cause infinite loops for delays of > 20 us. Such delays
are rare. For syscons and kbdio, DELAY() is only called early
enough to matter for ddb input after booting with -d, and the delay
is too small to matter (and too small to be correct) except in the
PC98 case. For pcvt, DELAY() is not used for small delays (pcvt
uses its own broken routine instead of the standard broken one),
but some versions call DELAY() with a large arg when they unnecessarily
initialize the keyboard for doing console output. The problem is
more serious for pcvt because there is always some early console
output.
Guard against the i8254 timer being partially or incorrectly
initialized. This would have prevented the endless loop.
Should be in 2.2.
I have no idea if this works since I don't have one of the cards to test.
I also don't know what the LINT and GENERIC entries should look like,
so I just made up some values for now and left them commented out.
Someone who knows the factory settings for a Pro/10, please contact me!
Submitted-By: Javier Martín Rueda <jmrueda@diatel.upm.es>
when allocating memory for network buffers at interrupt time. This is due
to inadequate checking for the new mcl_map. Fixed by merging mb_map and
mcl_map into a single mb_map.
Reviewed by: wollman
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
- the operands for bt, bts, arpl and `enter' were reversed.
- btr was reported as bts (with the correct operand order).
- cmpxchg was misplaced. It was misplaced differently in the
comments. It is misplaced differently again in the i486 manual.
I put it where the i586 manual and gas say it is.
- fucompp was misplaced.
- the rr table for(s) some versions of fstp, fcom and fcomp was non-null.
This caused some invalid opcodes to be reported as "" instead of as
"<bad instruction>".
- the word and long versions of the fi* instructions were reversed.
- aaa and daa were reversed.
Fixed bugs involving unusual operand sizes:
- 32-bit registers weren't always forced for bswap or for moves to and
from special registers.
- the operand sizes weren't reported for [l]call or [l]jmp.
- displacements weren't truncated mod 2^16 when the operand size was
16-bit.
- too-large displacements and offsets were fetched, and too-large
offsets were reported, when the operand size was 16-bit.
- sign extended immediate bytes were extended too far when the operand
size was 16-bit.
Fixed bugs involving usual operand sizes:
- 8-bit source registers weren't forced for mov[sz]b[wl].
- 16-bit source registers weren't forced for mov[sz]w[wl].
- immediate bytes were sometimes reported as sign extended even for
byte operations. Same for immediate words in word operations.
- the immediate byte was not reported as sign extended for `push'.
Finished Pentium support:
- cpuid, cmpxchg8b and rsm were missing.
Finished i287 support:
- fneni, fndisi and fsetpm were missing. These are harmless nops on
later FPUs.
Improvements:
- report invalid opcodes 0xd6 and 0xf1 using .byte. They are special
in not causing invalid operand exceptions when executed.
- report the immediate byte for unusual aam and aad instuctions.
Immediate bytes other than 0x0a always worked and are documented to
work on Pentiums.
This code was sent to me by Bruce Evans, and seems to fix some
possible kernel panic in case of an execution error. It did not
cause any problems on my system, but I did never observe the
problem this patch is supposed to fix, anyway.
This patch is a NOP, unless the kernel is built with "options
USER_LDT", and doesn't affect the GENERIC kernel for this reason.
I want to have it in 2.2: it fixes a bug ...
Submitted by: bde
also implies VM_PROT_EXEC. We support it that way for now,
since the break system call by default gives VM_PROT_ALL. Now
we have a better chance of coalesing map entries when mixing
mmap/break type operations. This was contributing to excessive
numbers of map entries on the modula-3 runtime system. The
problem is still not "solved", but the situation makes more
sense.
Eventually, when we work on architectures where VM_PROT_READ
is orthogonal to VM_PROT_EXEC, we will have to visit this
issue carefully (esp. regarding security issues.)
is still broken - it doesn't restore the floating point state.
2.2-BETA users should disable it using npx0 flags 0x04 the same as
2.2-ALPHA users should have.
This makes unexpected faults (in an interrupt handler) more likely
to crash properly. It could be done even better (more robustly and
more efficiently) using lazy fault handling.
