Age | Commit message (Collapse) | Author |
|
the SCSI part so far.
|
|
|
|
on MVME197DP boards running the MP kernel.
|
|
by anything, will eventually be used by the vx(4) MVME332 driver (once I
take the time to fix it) and the vsbic(4) MVME327 driver being worked on.
|
|
|
|
|
|
|
|
|
|
from the individual drivers now that ether_ioctl() handles this.
Shrinks the i386 kernels by..
RAMDISK - 2176 bytes
RAMDISKB - 1504 bytes
RAMDISKC - 736 bytes
Tested by naddy@/okan@/sthen@/brad@/todd@/jmc@ and lots of users.
Build tested on almost all archs by todd@/brad@
ok naddy@
|
|
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@
|
|
|
|
prints it. These should be the last offenders.
|
|
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@
|
|
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).
|
|
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.
|
|
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.
|
|
This lets 40MHz MVME197LE boards run with instruction cache enabled, and also
fixes random instruction faults occuring on the early 50MHz models.
|
|
|
|
preserved across BUG calls, but on the other hand the last 16 traps need to
be restored to BUG values, not only trap #496.
|
|
should do this for us, but better play safe.
|
|
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.
|
|
|
|
sys/dev/pci/pciide.c from naddy@
|
|
|
|
|
|
|
|
In ip_esp.c all allocated memory is now zero'd in the
"malloc(sizeof(*tc) + alen ..." case. The +alen memory was not
initialized by the bzero() call. Noticed by chl@.
"Looks good" art@ "seems ok" chl@
|
|
|
|
|
|
|
|
as no more than one interrupt is registered for a given level.
Then, if the VME interrupt vector reading cycle fails on the 188 interrupt
arbiter, we can use this table as a hint if it has a valid entry, since
we know on which ipl line the interrupt occured.
This basically silences the
m188_ext_int: timeout getting VME interrupt vector, level 3, mask 0x400<IRQ3>
occasional messages appearing when the MVME376 is overloaded.
|
|
the end of the address space; allows the A16D16 VME space to be mapped
correctly again on MVME197.
|
|
|
|
|
|
ok miod@ marco@ deraadt@
|
|
(spec wants 3 X1 clock cycles, thus 0.82 microsecond on mvme188)
|
|
|
|
|
|
|
|
off kernel_map whenever necessary.
|
|
so that things can use it; tested on all architectures; ok kettenis
|
|
With a few prototype declarations shuffling, this finally allows
<machine/locore.h> to die.
|
|
pmap_extract(), and do not bother creating regular page table mappings
for obio regions which are covered by these BATC entries.
|
|
|
|
Saves up to 12KB of no longer necessary page tables.
|
|
necessary; allow opening /dev/nvram0 on MVME188 again (but no mmap).
|
|
|
|
32 bit int. So map the right size, and fail open() until the uiomove() wrapper
is modified to cope with this.
|