Age | Commit message (Collapse) | Author |
|
should be safe to call the midlayer io path without the biglock now.
|
|
|
|
the kernel biglock. the plan is to have the midlayer assume its
running without the biglock, but that it cant call adapters or
devices without taking the biglock first.
this diff just wraps the calls to the adapter iopool get and put
handlers up in the biglock.
this is safe now because of kettenis' commit to src/sys/kern/init_main.c
r1.120. ive been running this in various places since early 2011.
|
|
ok dlg@
|
|
a whole bus, a target, or a specific lun on a target from the bioctl
and scsi_req paths.
i want to reuse this factored code for something claudio wants.
|
|
is to check xs->status on completion to make sure it worked.
|
|
ok dlg@
|
|
tested by jmatthew@
|
|
it rather than on attach. just need to implement a sense handler
to detect failover and this is done.
thanks to jmatthew@ for plugging this together again for me.
|
|
a paths status, rather than on attach. the status it returns depends
on the type of device you have. hds provides two types of arrays,
symmetric and asymmetric.
on a symmetric device you can shove io down any path to any port
on any controller and it will work. on symmetric devices we say all
paths are part of the same group, and unconditionally return active
path status to any check request.
on asymmetric devices we group paths by which controller in teh
array they connect to. the controllers return whether theyre providing
a preferred path via a couple of status bits in a hds specific vpd
page, so we query that and return the state of the bits.
unfortunately hds arrays dont report change of lun ownership in any
way, so we dont currently have any way of failing over at the moment.
ill have to think about the least worst way to handle that.
tested by deraadt@ on hppa
|
|
|
|
invalid request due to current lu ownership
|
|
driver re-probe for its capacity.
Allow to fully recognized Lexar JumpDrive S33 USB 3.0 sticks.
ok krw@, dlg@
|
|
dmesg, or write operations just fail with EACCES for no obvious reason
ok krw@ tedu@
|
|
identify them over multiple paths using their wwnn.
|
|
generate a devid. if its an fc device this is good enough.
|
|
|
|
use it should cause a fault.
based on discussion with miod@
|
|
outside scsi_base.c.
this will allow adapters to restrict access to iopool resources
based on some state, and then kick the pending requests on the pool
when the state comes good again.
ive been avoiding this for a long time, but it is the least worst
way to deal with some uses of XS_NO_CCB.
discussion with kettenis@ helped me decide this was right.
|
|
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op's in drivers
creating callback/threads themselves, but that has become too common,
indicating the need for a built-in mechanism.
ok dlg kettenis, tested by a sufficient amount of people
|
|
resurrection of the bad idiom in the tree.
sufficient review by miod, kettenis, tedu
|
|
|
|
variables. Some random whitespace/knf repairs encountered on the way.
ok miod@ on inspection, feedback & more suggestions from millert@
|
|
|
|
|
|
Ditto disksize field of sd_softc and a couple of local calculation
variables.
scsi/* now daddr_t clean except where they really are 512-byte
blocks.
|
|
to cd.c and call it cd_size(), like sd_size() lives in sd.c.
Tweak some daddr_t variables to u_int64_t on the way, when they are
for disk sector numbers, not 512-byte block numbers.
|
|
Prefer DL_ macros over handrolling. Fix the loop to allow for bigger
(highly unlikely) bunches of bits to be broken up into rw_10 sized
(<= UINT32_MAX sectors) chunks. Add check to make sure i/o request
starts at a sector address.
|
|
'secno'. This is what sddump() already does and consistant is good.
No function change.
|
|
repeated handrolling of same code. Use daddr_t variable to
calculate daddr_t return values, and u_int64_t variables to
calculate disk sector values.
No functional change.
|
|
paths are lost and groups become empty) we dont try and do stuff with it
that causes null derefs and awesome panics.
|
|
|
|
the wrappers around handling of pending work, theyre not semaphores.
names from tedu@
ok krw@ guenther@
|
|
than the real device drivers. ses returns 3 on some dells, which could be
confusing for autoconf if it has to decide between that and a path driver.
|
|
code that picks the next path. we assume roundrobin within a group
of paths now. the asym sym(4) devices work around this by putting
every path in its own group.
|
|
of devices. fixes compilation when theyre enabled.
how embarrassment.
|
|
other things scsi_sem_enter. the things protected by this do as
much work as they can, so they only need to be told to try again
once.
this isnt a semaphore anymore (and probably never was) so there's
a name change coming too.
|
|
if a controller sends sense data back, the path driver can tell
mpath that its indicating failover which kicks off an iteration
over all the groups until one says its active. if no groups claim
to be active, a timeout fires the process off again after a second.
you can start controller handover on rdac (well, an md3200i is all
i had to test with, others might need more work) and everything
keeps going. ill try to get to emc and hds working when i can poke
hardware again.
|
|
|
|
|
|
|
|
handler for the mpath midlayer to call. the status check is completely
event driven.
a group is considered active if the VOLACCESSCTL vpd page has some
bits set.
|
|
|
|
midlayer would be able to call things on paths to explicitely online
or offline them. turns out thats not how the Real World(tm) works,
instead its better to wait for failure and probe for the status of
paths, and pick the active group of paths from that. there's even
evidence that the mechanisms for forcing controllers into active/passive
roles from the scsi initiator are being deprecated. they expect
hosts to be able to cope with arbitrary controller role changes and
failover
accordingly.
this replaces the online and offline function pointers in the path_ops
structure with a status check function pointer. instead of returning a
state, the checker is expected to call mpath_path_status() when its
finished figuring out what the state is.
|
|
ascq 0x01, or skey unit attention + asc 0x8b + ascq 0x02 when i
tell it to change controller ownership of a volume. i wish i knew
what the numbers really meant, but alas, there's no doco cos this
is all magical and unique apparently.
anyway, empirically this can be used in rdac_checksense to return
MPATH_SENSE_FAILOVER.
|
|
(who can tell ive spent time in web servers) to say they decline
interpreting the sense data, or MPATH_SENSE_FAILOVER to say the
sense data is from the controller saying its failed over.
all path drivers currently decline handling sense data.
|
|
|
|
devices and paths. devices are what mpath presents as targets on
its scsibus, and paths are the things attached to hardware controllers
that are available to shove io down to the actual real target. all
paths were considered usable for handling io on behalf of a device.
this adds groups in between devices and paths. only paths on the
first group in the list will now be used to handle io now.
sym devices will only have one group. asym devices will treat each
path as a different group. rdac, emc, and hds will group paths based
on which controller in the array theyre connected to.
in the future we will intercept sense data from passive controllers
and use that to start running checks to pick a new primary group
so we can handle controller failover situations.
the group id in hds(4) is currently busted, everything else should
be correct.
|
|
use as the group id later on.
|
|
firstly, move the array of targets that mpath presents into the softc.
secondly, when paths call the mpath api we can simply check if the softc
global is not null rather than walk through autoconf data. mpath will either
have already attached or will never attach in the future.
|