| Age | Commit message (Collapse) | Author |
|---|
|
Move calling ether_ioctl() from the top of the ioctl function, which
at the moment does absolutely nothing, to the default switch case.
Thus allowing drivers to define their own ioctl handlers and then
falling back on ether_ioctl(). The only functional change this results
in at the moment is having all Ethernet drivers returning the proper
errno of ENOTTY instead of EINVAL/ENXIO when encountering unknown
ioctl's.
Shrinks the i386 kernels by..
RAMDISK - 1024 bytes
RAMDISKB - 1120 bytes
RAMDISKC - 832 bytes
Tested by martin@/jsing@/todd@/brad@
Build tested on almost all archs by todd@/brad@
ok jsing@
|
|
|
|
addition to the kernel, and unconditionnaly handle all busswitch revision 1
based boards as horribly broken, even with 50MHz clocks.
Based on an report of an early 50MHz 197LE board being unable to boot,
due to memory corruption.
|
|
prints it. These should be the last offenders.
|
|
ok marco@ no objection miod@ need this for regress djm@ no objection krw@
|
|
|
|
Not sure what's more surprising: how long it took for NetBSD to
catch up to the rest of the BSDs (including UCB), or the amount of
code that NetBSD has claimed for itself without attributing to the
actual authors.
OK deraadt@
|
|
ok thib beck art
|
|
file copies to nfsv2 causes the system to eventually peg the console.
On the console ^T indicates that the load is increasing rapidly, ddb
indicates many calls to getbuf, there is some very slow nfs traffic
making none (or extremely slow) progress. Eventually some machines
seize up entirely.
|
|
biowait() reads that do *not* come from the buffer cache - we use the
B_RAW flag to identify these at art's suggestion - since it makes sense
and the flag was not being used. this just flags all these buffers with
B_RAW - biodone already ignores returned buffers marked B_RAW.
ok art@
|
|
|
|
|
|
sgi.
|
|
|
|
|
|
bpf(4) are different enough so that the split makes sense -- this is necessary
to make bpf(4) cloneable.
requested deraadt@, OK thib@
|
|
them (especially the netboot ones) will now self-relocate, which makes
BUG configuration much simpler.
WARNING: for disk-based systems, you need to update bootxx and bootsd at the
same time. New bootsd will not run when loaded from an older bootxx.
This doesn't matter much since you need both with installboot.
|
|
|
|
|
|
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.
|
