"poll" flag when called from ld_shutdown().
This is the infrastructure part of kern/38655 - in itself it doesn't
fix the panic referenced in that PR.
XXX: At least ld_twa.c and perhaps ld_iop.c and ld_icp.c need to
check for this new poll flag and do something useful.
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.
disk framework. This stops ld(4) from returning an error for various
ioctl() requests which actually *did* work. As a result fdisk(8) and
therefore also sysinst(8) work with ld(4) devices once again.
Based on a patch supplied by Todd Kover in PR kern/36244, successfully
tested with ld(4)@icp(4).
- rather than embedding bufq_state in driver softc,
have a pointer to the former.
- move bufq related functions from kern/subr_disk.c to kern/subr_bufq.c.
- rename method to strategy for consistency.
- move some definitions which don't need to be exposed to the rest of kernel
from sys/bufq.h to sys/bufq_impl.h.
(is it better to move it to kern/ or somewhere?)
- fix some obvious breakage in dev/qbus/ts.c. (not tested)
with the wedge support, which caused premature return and left dk_openlock
locked, leading to lockmgr() panic on close; newfs of ld disk now works again
ExtremeRAID with NV cache) and "dumb" (3ware 6410) ld providers.
Instead, use the default buffer queue policy.
With the 3ware adapter, using the read priority strategy instead of FCFS,
for three extractions of pkgsrc, took 329 seconds instead of 331 -- but
with a dramatic improvement in perceived system response (latency for
I/O outside the main stream).
With the Mylex adapter, the improvement was dramatic: using read priority
instead of FCFS yielded an improvement from 381 seconds to 135 seconds!
There was a less-noticeable improvement in perceived latency as well.
The other disk drivers currently hard-wired to FCFS or another policy
should probably be changed as well.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
Instead, wait when it's really needed, when detaching. Project
draining from spruious wakeups.
* Don't flush the controller's cache when detaching; we can't do it
reliably, as the controller probably things the array drive no
longer exists. The cache is already flushed in ldclose() so this
should be no problem.
