| Age | Commit message (Collapse) | Author |
|---|
|
for RB_DFLTROOT; ok miod
|
|
the hp300 related ones currently in use. CN_NORMAL becomes CN_LOWPRI,
CN_INTERNAL becomes CN_MIDPRI and CN_REMOTE becomes CN_HIGHPRI.
ok miod@
|
|
1 for 88110), for userland to have an easy way to figure out.
|
|
|
|
this. Might help before someone sets his disks on fire. Especially with
boards where not all channels are of the same type.
|
|
SCSI commands length correct (it's a length in 16 bit words, not in 8 bit
bytes).
|
|
probably due either to an error in the cpu-to-88410 communication protocol,
or to a bug in the '410 (but since I do not know how to get its revision,
I can't tell whether this is the obscure v1 bug or not).
This allows osiop-connected devices to work correctly on 197SP/DP boards.
|
|
wide Cougars, use one command queue per target and disable lun support, so
that we do not overflow the board's memory; and since we are behaving as
a Jaguar, do not do tagged queuing or synchronous transfer negotiation.
Tested on two MVME328XT-2 (4220 and second revision artwork 4220) narrow
Cougar-I (but wide external connectors), but probes fail with select timeout
so far; I could not get various Motorola BUG to probe devices on these boards
either, so we're even (and maybe both my boards are toast, but I won't bet
money on this).
|
|
- switch back to a fixed queue number allocation, but keep the rotating
command queue entries. Force openings to 1 because of this.
- make sure to mark the queue as ready before invoking scsi_done(), which
could trigger a request for the same target.
- allocate a command queue and an IOPB at the same time, instead of using two
routines and ugly queue pointer arithmetic.
This makes the daughterboard work, as long as the first scsi chain is not
empty.
|
|
|
|
DCAM2 boards in a different way.
|
|
non-VME syscon interrupt sources will now use their own intrhand array,
and interrupt sources will be enabled in the arbiter as interrupt handlers
are registered. This allows VME devices to use the whole 256 interrupts range.
|
|
we never disable it, it is not necessary to check for D$ to be enabled
before acting. That's a few more cycles spared.
|
|
instructions to be serialized (this defeats the purpose of having a superscalar
processor, and accesses to volatile variables are done with explicit memory
barriers anyway).
This brings a HUGE speedup: openssl speed -elapsed shows AES is 90% faster,
blowfish is 75% faster, and sha1 is 50% faster. Not so bad!
However, doing this increases the pressure on the processor bus, so it is
necessary to increase the processor bus timeout on 40MHz boards again (to 256
usec). ``black cat'' 50MHz boards seem to be unaffected, so they remain at
64 usec.
|
|
memory but a memory controller limited to 32MB.
Not tested for lack of such crippled hardware, just the average
once-per-leap-year act of niceness from me (a bit early though).
|
|
|
|
This lets 40MHz MVME197LE boards run with instruction cache enabled, and also
fixes random instruction faults occuring on the early 50MHz models.
|
|
it five times.
|
|
workaround errata #1 differently on these models.
|
|
of offsets / sizeof(register_t), and nuke the REG_OFF macro. No functional
change.
|
|
|
|
|
|
|
|
so that they run stably. Definitely overkill and causing a severe performance
hit (they now run about as fast as a 25MHz board with I$ enabled would), but
sometimes you can't fight silicon bugs.
Other boards (i.e. 50MHz ones) are not affected.
|
|
preserved across BUG calls, but on the other hand the last 16 traps need to
be restored to BUG values, not only trap #496.
|
|
invalidate tlb ipis, and turn them into simple ``handle once'' ipis.
|
|
MVME197DP to serialize 88410 operations.
|
|
should do this for us, but better play safe.
|
|
out-of-order (superscalar) execution on these processors.
Since OoO brings a nice 50% to 250% speedup (as shown by ``openssl speed''),
it is definitely worth enabling.
|
|
|
|
more work in progress to handle these exceptions correctly, and document
a new undocumented and evil chip bug while there.
|
|
field from the processor identification register; this allows .S code which
needs to decide on the cpu type at runtime to check quicker, without needing
to access memory. No functional change.
|
|
IPIs.
|
|
an IPI facility, for MVME197DP.
It's still missing a few remote cache IPIs and IPI do not seem to be reliably
triggered on remote processors at the moment (but this could be a problem
on the board I am currently testing on), at least it will boot multiuser
using only cpu0 to schedule processes.
|
|
of its initialization stack. Oops.
|
|
flushing the whole secondary cache.
This does not work around the snooping errata yet, I'm trying to get
something not too ugly first.
|
|
|
|
until cmmu_set_sapr(). Also, do not enable snooping on MVME197LE, so that
we don't have to add workarounds for snooping problems later.
|
|
|
|
|
|
existing code to enable TCFP was broken, as it was not setting the TCFP bit
in the right register.
So far, the exception handler will deliver SIGFPE in all cases. It will
eventually do the necessary rounding, and handle the odd-numbered register
pair operation, as I get time to write this (or see how much can be lifted
from the 88100 floating-point exception code).
|
|
needs it includes <machine/param.h> already.
|
|
|
|
x86 __mp_lock changes, but keeping the internal __cpu_simplelock_t to
guarantee atomic access to the __mp_lock fields.
|
|
|
|
sys/dev/pci/pciide.c from naddy@
|
|
code. At this moment all architectures get the copy of the old code
except i386 which gets a new shiny implementation that doesn't spin
at splhigh (doh!) and doesn't try to grab the biglock when releasing
the biglock (double doh!).
Shaves 10% of system time during kernel compile and might solve a few
bugs as a bonus.
Other architectures coming shortly.
miod@ deraadt@ ok
|
|
|
|
|
|
directive can select between MI and MD versions of these files. At
the same time, adjust the boot programs to pick exactly what they need,
instead of the 7 or 8 mechanisms previously used.
There will be some fallout from this, but testing it all by myself is a
ridiculously slow process; it will be finished in-tree.
Various developers were very nice and avoided making fun of me when I
was gibbering in the corner..
|
