this makes it possible to attach to linux process with linux gdb and
see top-most function on traceback; lower functions are not available,
probably due to bad frame setup
it's not possible to setup breakpoints - Linux gdb uses hw breakpoints,
so support for them would need to be written
- when pcb_onfault is set, allow UVM to attempt to resolve permission faults
as well as translation faults (rather than immediately invoking the
onfault handler for permission faults). this is needed for UBC since
it will be normal for uiomove() to fault on read-only mappings which
will be made writable by the pager.
- clear pcb_onfault before calling uvm_fault() and restore it afterward.
if the fault handler generates a pagefault, we'd like to panic rather
than invoking the onfault handler.
- allow entry of the same mapping that's already there.
this can happen with UBC.
- if PMAP_CANFAIL, return failure rather than sleeping
when we fail to allocate a ptp.
* move all exec-type specific information from struct emul to execsw[] and
provide single struct emul per emulation
* elf:
- kern/exec_elf32.c:probe_funcs[] is gone, execsw[] how has one entry
per emulation and contains pointer to respective probe function
- interp is allocated via MALLOC() rather than on stack
- elf_args structure is allocated via MALLOC() rather than malloc()
* ecoff: the per-emulation hooks moved from alpha and mips specific code
to OSF1 and Ultrix compat code as appropriate, execsw[] has one entry per
emulation supporting ecoff with appropriate probe function
* the makecmds/probe functions don't set emulation, pointer to emulation is
part of appropriate execsw[] entry
* constify couple of structures
as normal device interrupts. Because of this, we won't get IPIs while
servicing such interrupts. This can lead to the following deadlock
scenario as reported by Bill Sommerfeld:
- Process runs on cpu1, but has FP state on cpu0.
- Process executes FP-using insn, causing an FP trap, which causes
the kernel lock to be acquired.
- At roughly the same time, cpu0 receives a device interrupt, and attempts
to acquire the kernel lock, which blocks since cpu1 already has it.
- cpu1 sends cpu0 a SYNCH FPU IPI, and waits for cpu0 to release its
FP state.
- Since cpu0 cannot notice the IPI until it has processed the device
interrupt, which it cannot do because it cannot acquire the kernel
lock, we have deadlock.
Solve the problem by adding a spinlock interlock release hook which
checks for pending IPIs and processes them.
Idea from Bill Sommerfeld.
This was not added also to other config files primarily because the
driver is not properly tested yet; this entry is primarily meant as an example
for those brave souls who want to try moxa.
CPU support taken from a combination of NetBSD/amiga and NetBSD/x68k.
At this time, MVME-172 works but MVME-177 is untested. Since the '177
is otherwise identical to the MVME-167, this should *just work*.
Still use memcpy in receiving because we must use buffer fill mode
and many packets may share single receive buffer.
XXX: Workaround(?) for CXD3222: it fails to DMA for selfid packet according
to code placement. I'm not sure about the reason (cache? timing? bug?).
Fixed the bug: transmitter sometimes stop and OACTIVE bit of if_fw
never be cleared.
Fixed the bug: freeing free buffer.
Enable ieee1394_drain and ieee1394_watchdog for loss of fragment.
rather than assigning to the whole field, set or clear individual flags,
which implies that the B_BUSY and B_INVAL flags will remain set.
this allows us to make the assertion in brelse() that B_BUSY is set,
which is the purpose of all this.
CPU to handle interrupts, but prevents a whole slew of things
from working properly on the second CPU. It is no longer
necessary now that several other bugs have been fixed.
on it, and make sure to deactivate the old process's address space,
as this will not otherwise be done by cpu_switch() later once we're
on the idle PCB.
Also, update some comments related to when s0 (i.e. the old process)
is NULL in the context switching code.
thorpej