and attach it at mainbus since it depends both PCCChip2 and VMEChip2
(or the VMEChip2 interrupter) starting first.
We can finally enable, detect and log DRAM ECC errors.
(The PROM disabled ECC checks by default)
and with the comment '4.2BSD TCP/IP bug compat. Not recommended'
Add commented out 'TCP_DEBUG # Record last TCP_NDEBUG packets with SO_DEBUG'
(All hail amiga and atari which make some attempt to automate the
multiplicity of config files...)
hardware-assisted soft interrupts on all boards.
(Note: VMEChip2-less 162/172 not yet tested)
This greatly simplifies the `rei' path and allows
interrupt nesting to be tracked somewhat more easily.
As a result we now have a working CLKF_INTR() macro
and can detect uvm_fault() being called from an interrupt
(although there may still be a very short race detecting
the latter; need to investigate further).
the jumper which tells 1xx-Bug where to locate its scratch data.
Instead, print a message informing the user to RTFM (which needs to
be updated to include this info. ;-)
Basically, bus_dmamap_sync() `PREREAD' needs to flush the cache
for the start and end of the region if it is not aligned to
a cacheline boundary, otherwise a subsequent POSTREAD can *purge*
valid data which was in the cacheline but *outside* the region
passed to bus_dmamap_sync().
Bus snooping doesn't always help here because osiop(4) calls
bus_dmamap_sync() with POSTREAD even if no data was actually
transferred! (And we can't rely on snooping on the 68060 models anyway).
each vm_page structure. Add a VM_MDPAGE_INIT() macro to init this
data when pages are initialized by UVM. These macros are mandatory,
but ports may #define them to nothing if they are not needed/used.
This deprecates struct pmap_physseg. As a transitional measure,
allow a port to #define PMAP_PHYSSEG so that it can continue to
use it until its pmap is converted to use VM_MDPAGE_MEMBERS.
Use all this stuff to eliminate a lot of extra work in the Alpha
pmap module (it's smaller and faster now). Changes to other pmap
modules will follow.
This is a completely rewritten scsipi_xfer execution engine, and the
associated changes to HBA drivers. Overview of changes & features:
- All xfers are queued in the mid-layer, rather than doing so in an
ad-hoc fashion in individual adapter drivers.
- Adapter/channel resource management in the mid-layer, avoids even trying
to start running an xfer if the adapter/channel doesn't have the resources.
- Better communication between the mid-layer and the adapters.
- Asynchronous event notification mechanism from adapter to mid-layer and
peripherals.
- Better peripheral queue management: freeze/thaw, sorted requeueing during
recovery, etc.
- Clean separation of peripherals, adapters, and adapter channels (no more
scsipi_link).
- Kernel thread for each scsipi_channel makes error recovery much easier
(no more dealing with interrupt context when recovering from an error).
- Mid-layer support for tagged queueing: commands can have the tag type
set explicitly, tag IDs are allocated in the mid-layer (thus eliminating
the need to use buggy tag ID allocation schemes in many adapter drivers).
- support for QUEUE FULL and CHECK CONDITION status in mid-layer; the command
will be requeued, or a REQUEST SENSE will be sent as appropriate.
Just before the merge syssrc has been tagged with thorpej_scsipi_beforemerge
- pmap_enter()
- pmap_remove()
- pmap_protect()
- pmap_kenter_pa()
- pmap_kremove()
as described in pmap(9).
These calls are relatively conservative. It may be possible to
optimize these a little more.
call overhead is incurred as we start sprinkling pmap_update() calls
throughout the source tree (no pmaps currently defer operations, but
we are adding the infrastructure to allow them to do so).
This adds support for EtherExpress/16 cards with 16k of RAM, and in the
process adds general support for PIO mode on these cards. This entails
changing the way the i82586 driver handles bus barriers, since it doesn't
allow for strange cases like this.
This has been tested on the i386 port with the 'ix' driver in both
16KB (which was the source of the problem) and 32KB modes, as well
as with the 'ef' driver. I've tested it (briefly) with 'ei' on arm26
as well. In theory, drivers other than 'ix' should follow precisely the
same code paths as before.
and place the definition in <machine/types.h>. This can now be used
as a flag to indicate whether or not <machine/intr.h> can be included
to get the generic soft interrupt API.
only signal handler array sharable between threads
move other random signal stuff from struct proc to struct sigctx
This addresses kern/10981 by Matthew Orgass.
XXX I wish m68k ports would share trap.c
o Avoid checking cputype when the kernel is built for one cpu variant only.
o In writeback(), don't use bcopy() to write a mere 16 bytes of 16-byte
aligned data; it's much quicker to copy it inline.
. use a structure for the tag instead of an integer constant,
. add bus_space_{peek,poke}_N() (and G/C `badaddr()'),
. fix a few drivers which have dependencies on the implementation.
* 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
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*.
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.
maps standard boot flags to corresponding RB_* values
use BOOT_FLAG() in port's MD code as appropriate
as discussed on tech-kern, add new boot flags -v, -q for booting
verbosely or quietly, and corresponding AB_VERBOSE/AB_QUIET
boot flags; also add FreeBSD-compatible bootverbose macro and
NetBSD-specific bootquiet macro
for hpcmips, use new bootverbose instead of it's own hpcmips_verbose
Tested on i386, and to limited extend (compile of affected files) also for
mvme68k, hp300, luna68k, sun3.
backend.
The VME2chip can use this to translate a VMEbus irq to a cpu irq.
The VMEchip (on mvme147) can't deal with the VMEbus irq and cpu irq
being different so we just panic in that case for now.
routine. Works similarly fto pmap_prefer(), but allows callers
to specify a minimum power-of-two alignment of the region.
How we ever got along without this for so long is beyond me.
Currently, the major onboard devices are supported (disk, network,
rs232 and VMEbus). However, work is still need to support the remaining
devices (eg. IndustryPack sites).
These boards are available with a dazzling array of build options. At
this time, the following options are *required*:
o Real floating point hardware (the 68LC040 model isn't tested),
o The VMEchip2 must be present,
o If offboard VMEbus RAM is not present, at least 8MB of onboard
RAM is required.
o Even if offboard VMEbus RAM *is* present, at least 4MB of onboard
RAM is required. (Boards with 1 or 2MB onboard RAM *can* be
supported with offboard RAM, but not without some funky values in
the VMEbus Master mapping registers.)
There is no support for boards other than those in the -LX 200/300 series.
treated as just another available VMEbus slave image as far as
bus_dma(9) is concerned.
To preserve faster onboard memory, mvmebus_dmamem_alloc() will
allocate first from the offboard VMEbus RAM slave image if present,
and assuming its address modifier matches the caller's constraints.
This can be overidden by specifying the BUS_DMA_ONBOARD_RAM flag.
deal with dynamic address modifier generation based on the CPU's
function code pins.
Also implement VMEbus slave mode for mvme147. (Not yet 100% working.)
in the non-MULTIPROCESSOR case (LOCKDEBUG requires it). Scheduler
lock is held upon entry to mi_switch() and cpu_switch(), and
cpu_switch() releases the lock before returning.
Largely from Bill Sommerfeld, with some minor bug fixes and
machine-dependent code hacking from me.
vme_dmamem*.
This is still a work in progress, but seems to DTRT on mvme167 so far.
TODO:
. Get VMEbus slave mode going on mvme147. This should be easy.
. Fix up the A16 slave mappings.
. Bounce buffer support. (Messy, but pretty much a `must have'.)
. Figure out how to deal with `location monitor' interrupts
within the framework. (Useful for Busnet, among other things.)
. It would be nice to make use of the VMEchip2's DMA facilities...
Debugger(). Use db_printf() instead.
This fixes a problem whereby it was impossible to enter the debugger
if the CPU was spinning in lockmgr() for the proclist lock, because
printf() calls logwakeup(), which eventually calls proclist_lock_read(),
which then spins in lockmgr() yet again...
[Note: This change was prematurely committed to the 1.5 branch by
mistake. Since it would've been pulled up anyway, I won't
be sending a pullup request.]
scw