| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ok krw@
|
|
is causing problems when trying to boot sparc64 from an isp(4).
Verified to fix the sparc64/isp(4) regression by krw@; ok deraadt@
|
|
These will be used to replace scsi_link's adapter_buswidth and luns
fields, but for now we stay compatible with existing SCSI adapter
driver conventions while I update them to set the scsibus_attach_args
fields directly.
ok dlg@
|
|
needs either of them.
ok krw@
|
|
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.
ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago
|
|
remove two of the remaining three uses of it. (softraid(4) still uses
it at the moment, so the field and its assignment in scsibusattach()
stay for now...)
ok krw@; feedback and "tenteiramen rejid"(!?) miod@
|
|
whitespace into one. Written after Mitja showed a particularly unwieldy
attach line:
sd0 at scsibus0 targ 2 lun 0: <ATA, HTS721010G9SA00, MCZI> SCSI3 0/direct fixed t10.ATA_____HTS721010G9SA00_______________________________blahblahblah
ok/incorporating a suggestion from matthew@, krw@ likes it, dlg@ doesn't
feel strongly either way.
|
|
by copying the adapters scsi_link. this way devices wont inherit the
adapters addresses on fc fabrics.
|
|
it up by using the usb devices iSerial thing.
ok deraadt@
|
|
enabled so people can get used to it.
ok deraadt@
|
|
found by marco@
ok and tweaks deraadt@ krw@
|
|
the big change is how paths between mpath capable devices and the
kernel are managed.
originally the midlayer would steal the links to the devices and
hide them behind mpath. all the changes an adapter made to a link
(eg activate or detach), the midlayer had to test if it was an mpath
link and then call special mpath code to handle it.
the original code also assumed that all paths behaved the same, but
the reality is that different devices have different command sets
and behaviours. figuring out which behaviour to pick and prioritising
them is basically the same job autoconf does with match and attach.
rather than special casing mpath in the midlayer and reimplimenting
autoconf, this turns paths into actual device drivers with match
and attach routines. after they figure out if the path is active,
they then give it to mpath(4) to use as a backend.
i have written drivers for symmetric access devices (sym(4)) where
all paths to the same logical unit are as good as each other,
lsi/engenio arrays (rdac(4), and emc arrays (emc(4)).
the rdac and emc drivers only detect active paths at attach time,
the do not cope if the controller changes state unless you unplug
the path and plug it in again to retest the active state. they also
do not have support for directing array failover.
operating and hoplugging has been tested with mpii(4), fc and sas
mpi(4), and iscsi via vscsi (claudio did this too).
ok krw@ deraadt@
|
|
ok krw@
|
|
to be in the right address space.
help from matthew and krw
|
|
than 1 i/o active at once. This reduces the chances that concurrent
i/o's for such devices will confuse the device or the adapter code.
It also eliminates a reason for adapter code to maintain its own
queues.
Tweak all drivers that fake INQUIRY results to set the SID_CmdQue
flag, thus continuing to claim to be able to do tagged i/o.
Positive feedback from matthew@ and marco@ for an earlier version.
ok dlg@
|
|
all from deraadt@
tested by me with hotplugged disks on mpi(4)
|
|
ok krw@ marco@ matthew@
|
|
DVACT_SUSPEND, therefore DVACT_QUIECE can do standard sleeping operations
to get ready.
Discussed quite a while back with kettenis and jakemsr, oga suddenly needed
it as well and wrote half of it, so it was time to finish it.
proofread by miod.
|
|
device are going away, this will walk the pool and link queues and
wake up processes that are sleeping while waiting for an io or xs.
they will return NULL to the scsi_{xs,io}_get callers, which should
then check if they device is still alive. all other handlers that
are registered on the queues should be removed by their owners
before the destroy/shutdown funcs are called.
lots of help and discussion with matthew@
ok matthew@
|
|
initialization strategy, rather than pretending to do user reference
counting. Previously, we would re-initialize the SCSI pool(9)s, which
had the fun consequence of causing sysctl(kern.pool.npools) to
infinite loop at IPL_VM.
ok krw@
|
|
to interpret sense errors. This is initialized to the basic
interpretation routine, and specific scsi drivers (sd/st/cd) can
replace this with their own. While here kill EJUSTRETURN dance and
make more specialized interpretation routines directly call the
basic routine if desired.
Fixes by matthew@ to my first diff. Most original work by dlg@.
ok matthew@ marco@ dlg@
|
|
sparsely populated buses.
ok dlg@, krw@
|
|
they are supposed to do, or be silent.
ok mlarkin
|
|
ok krw@, marco@
|
|
since it is time to start transitioning away from the no-op behaviour.
ok oga kettenis
|
|
runqueue. less is more sometimes.
|
|
instead of optimistically trying to use a resource by executing an
xs and then failing when there's no room for it, this puts things
that want to use the hardware on a runqueue. as resources become
available on the bus then consumers on the runqueue are popped off
and guaranteed access to the resource.
the resources are generally "ccbs" in adapter drivers, so this
abstracts a way for the midlayer to get access to them into something
called iopools.
it also provides a callback api for consumers of resources to use:
the scsi_ioh api for things that want direct access to the ccbs,
and the scsi_xsh api for things that want to issue a scsi_xfer on
the bus. these apis have been modelled on the timeout api.
scsi_xs_get and therefore scsi_scs_cmd have been cut over to using these
apis internally, so if they are allowed to sleep then can wait on the
runqueue for a resource to become available and therefore guarantee that
when executed on an adapter providing an iopool that they will succeed.
ok krw@ beck@ marco@
tested by many including krw@ beck@ mk@ okan@ todd@
|
|
of relying upon other headers bringing it in for you.
|
|
runtime out into a separate state variable. only operate on the state bits
with atomic ops. introduce the DYING state so things that sleep can figure
out if they should keep going or not.
|
|
the two issues affecting it last time are gone. the first, mishandling of
TRY_AGAIN_LATER is not relevant now that krw got rid of TRY_AGAIN_LATER.
the second, the misbehaving IBM disk was found to be a problem with siop
using ordered tags on most ops combined with the speed of the new code.
putting this in so we can move forward.
ok krw@ "commit please" marco@
|
|
causing a weird problems on an alpha and also appears responsible for
isp(4) weirdness i havent had a chance to examine yet.
sigh, this makes me sad.
|
|
DEVID_CMP now evaluates to false if the devids are NULL.
some stupid devices dont understand luns, so we have code that
detects when the device at lun 0 also appears at luns 1, 2, 3, and
so on. this check is short circuited if the devices report different
devids. no devids isnt the same as different devids though.
found by okan@ on ciss (which currently ignores luns).
tested by krw@ marco@ johan@ okan@
ok krw@ marco@
|
|
the fix for the NO_CCB breakage will follow shortly.
tested by krw@ marco@ johan@
ok krw@ marco@
|
|
TRY_AGAIN_LATER. NO_CCB is a timer based mechanism that can trivially
be made to fail by running IO to two or more disks simultaneously. The
TRY_AGAIN_LATER thing is more subtle because it now is a permanent
failure instead of transient however this is much harder to hit because
something must have gone wrong before it hits.
ok deraadt krw miod
|
|
many luns, or the entire bus), dont report ENXIO as an error to the
caller. this broke autoconf when it tried to forcefully remove a
bus such as umass and it thought there was a failure.
this introduces a way for scsi hbas to call activate/deactivate on
a device based on its target/lun address via a call to scsi_activate().
they can then schedule the actual detach/attach in a thread later via
scsi_req_probe/detach.
the mpi changes tweak the sas event handling code to use these apis
to properly handle attaches and detaches of disks. event handling
is still disabled till i can make it less chatty.
umass breakage reported by form@
|
|
scsibusdetach wasnt doign it properly, so we would be leaking on detach in
some cases.
now, with the introduction of mpath, the scsi_link structures can
represent a path to a mpath node as well as normal devices. this
intercepts the device activate entrypoints and sends them to mpath
if it it in use rather than assuming a device is always there. the
scsibusdetach change ensures that detach always ends up handling
the mpath node case too.
hotplug bus functionality (eg, usb) tested by form@
|
|
previously a devid was a structure containing its type, length, and
a pointer to the actual devid value. this has been changed so a
devid is a header followed immediately by the memory making up the
id value. this allows the header and its value to be allocated
together.
devids are now reference counted, so multiple things (eg, the mpath
node handlers and the various scsi_link structures) can share the
same allocation safely. this also frees devids when scsi_links go
away, which was previously not done.
if mpath is enabled, then print the devids out as part of the devices
attach line.
|
|
This is needed for the addition of further suspend/resume actions.
Okay deraadt@, marco@.
|
|
with it which became extremely annoying with what mpath wants to
do.
the major change is a new interface for submitting scsi commands.
previously the only way for drivers like sd, cd, st, etc to push
commands onto the hardware was via scsi_scsi_cmd(). the problem
with scsi_scsi_cmd is that it doesnt tell the caller if the command
failed, was queued, or completed unless you shoved a buf down with
it. this is important for mpath which wants to know what the physical
path to the device did so it can report it back to the midlayer
which called it.
this provides a new api which lets drivers like cd/sd/st/mpath etc
allocate an xs, fill it in, and provide a completion routine which
the midlayer will call with the state of the command when it is
finished with it. the caller is then responsible for freeing the
xs.
from the hba side of thing, the return code from the scsi_cmd
entrypoint is largely ignored now, and it is now always the
responsibility of the hba driver to call scsi_done when it has
completed the io, rather than returning COMPLETE and expecting the
midlayer to do it for you.
i have emulated scsi_scsi_cmd on top of this new api so existing
users of it will continue to work. sd(4) has been reworked to use
the new api directly to both demonstrate its use and test that the
new api actually does work.
this diff was mostly written in a day at f2k9. thanks to miod for poking
through hba drivers to help mitigate against fallout from the change to
the COMPLETE semantic. this has been reviewed by krw who didnt spot
anything wrong.
thanks to dave del debbio for testing.
ok deraadt@
|
|
shows the physical topology of your system.
|
|
structures by things other than autoconf.
|
|
thinks they could be available via multiple paths. those stolen
devices are then made available via mpath(4).
this is the minimum amount of code to implement the stealing. it
is generally broken and very brittle, so it is currently disabled.
it is going in so i can work on it in the tree.
|
|
we need this to get some clue as to which ports are which on an fc fabric.
requested by and ok deraadt@
|
|
as additional argument. This will allow intermediate layers between
scsi devices such as sd and scsi host adapters to take appropriate
action if necessary.
|
|
use to identify devices of interest.
ok deraadt@
|
|
anything. we represent that in the midlayre by moving the initiator id out
of the buswidth. let's not print it in that case.
ok deraadt@ kettenis@ krw@ marco@
|
|
a vpd page that uniquely identifies a device no matter what bus topology or
addressing was used to find it.
we have a workaround for old school scsi devices that do not differentiate
between luns. if the inq data for high luns is the same as the inq data
for lun 0, we assume it is one of these buggy devices.
the problem with this is that things like SANs present multiple
volumes as luns and they all have the same inq data. if you wanted
to present more than one volume to openbsd you would only ever see
the first one.
devices give us a mechanism to differentiate between luns, so now
i do get all my volumes attached in openbsde.
review and feedback by krw@ marco@ testing by todd@
|
|
|
|
keeps it on the stack till we attach a driver to it. then it copies
the inquiry data int the scsi_link struct.
this diff uses the scsi_link struct instead of the stack for that data,
which makes the inq data for users of the scsi_link struct available much
earlier during device probe.
review and feedback from both krw@ and marco@
|
