| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
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@
|
|
|
|
ok miod@ marco@ deraadt@
|
|
With a few prototype declarations shuffling, this finally allows
<machine/locore.h> to die.
|
|
|
|
cyclic search of the first unused work queue.
|
|
|
|
did not notice.
|
|
we can't send more commands simultaneously - instead of using MALLOC/FREE
for every scsi command we send.
|
|
to set xs->error to XS_BUSY. So it is pointless and misleading to
set xs->error to XS_TIMEOUT, XS_DRIVER_STUFFUP or XS_BUSY just before
returning TRY_AGAIN_LATER.
No functional change.
ok miod@
|
|
range in the current process, using trap #451.
This is necessary for proper gcc trampolines operation, and, later, ld.so...
|
|
|
|
- do not leak memory when polling;
- bring LUN support back - Motorola documentation says LUNs are not
supported, but it's a SysV/m88k limitation, not a hardware one.
- honour request timeout while polling (instead of using a fixed value)
- do not program the scsi command length if the hardware knows it from
the scsi command group (as advised in the manual)
- various minor fixes, especially better error recovery.
tested by nick@ and I; ok deraadt@.
|
|
gives us more counters in the process.
Also clean up intrhand structures and usage, especially move them to SLISTs.
|
|
|
|
|
|
second scsi bus if a SCSI daughterboard is present, and is supposed to know
about this and send scsi commands to the appropriate bus.
Unfortunately probing the second bus does not report any device at the
moment (though you can boot off it), but I can't see the issue at the moment.
Thanks to tdeval@ for lending a few boards equipped with daughterboards
for testing.
|
|
|
|
|
|
do not keep setting the A.A. bit in further queue control operations, as
advised by the manual.
|
|
|
|
target zero. This makes targets other than zero working now...
Spotted by nick@
|
|
|
|
|
|
|
|
|
|
controller ID jumpers, instead of reprogramming the board to 7 every time.
|
|
|
|
|
|
|
|
Also fix an arithmetic bug which caused almost no harm by luck.
|
|
chunk of code. It was never executed unless you were debugging a
mvmex8k 'vs' device.
ok miod@ (mvmex8k bits) marco@ deraadt@
|
|
|
|
|
|
converted yet, and they rely upon some linear mappings provided by bus_space.
In order to not impact performance, almost all the bus_space accesses go
through macros and inline functions. This currently restricts us to D16 and
D32 access modes, which are selected at compilation time. Since there are no
plans to support D8 vme devices in the future, this is acceptable for now.
This makes the "len" locator for vme devices go away, and allows to simplify
some code which was using the pcctwo device, and will now directly access
hardware which is known to exist, rather than wait until the device is
attached.
While there, try to enforce more interrupt vector number checks, since these
changes pointed out that dart(4) had been working correctly so far by sheer
luck only.
|
|
actually use two distinct vectors, rather than twice the same.
Because of this, print vector last in vmeprint() so that dmesg remains pretty
in the multi-vector case.
|
|
|
|
fails. Unfortunately, in this case, do_vspoll() would invoke the reset
function ad nauseum.
Allow the flow to exit this infernal loop, attach() will correctly fail.
This is temporary band-aid until a stronger reset sequence is found.
|
|
necessary. No functional change.
|
|
moreluns field in scsi_link structure. Instead, treat an INQUIRY
result that duplicates the INQUIRY result of LUN 0 as proof the LUN
does not exist. Compensate for lack of SDEV_NOLUNS where necessary by
setting sc_link->luns to 1, which has the same effect. From Marco
Peereboom.
Don't issue Test Unit Ready command before INQUIRY command - not
necessary and potentially harmful to devices with ADEV_NOTUR quirk
since quirks have not been set yet. From mycroft@NetBSD
ok deraadt@, mvme* changes by miod@.
|
|
For now, the result is the same as the hard-coded constant it used to be, due
to a pessimistic NUM_IOPB value. This will change.
|
|
one file per driver.
|
|
rolling their own.
Use them more cleverly in vx, in order to get the driver to at least attach
and frob chips. Not tested besides multiuser boot (hence ttyflags -a), and
checking cu(1) connects. More testing to come once I remember where I have
hidden the 332XT transition module...
|
|
(mvme68k/mvme88k) vs.c and (vax) if_le.c ok miod@
isakmpd ones ok ho@
|
|
|
