o expect the disk's start routine to return an int. If the
int is non-zero, we enqueue the request and try again
later.
o have a dk_start() routine which runs the request queue.
o have a dk_iodone() function which should be called by the
driver using the framwork from its iodone. dk_iodone will
retry the queue since presumably further progress may be
possible once a request is complete. It is required that
the underlying driver have the resources to keep at least
one transaction in flight at any time.
Modified cgd to:
o be able to keep one transaction in flight at any time
(almost) by keeping a buffer of size MAXPHYS in its softc
and use it.
We still need to make the cgd_cbufpool per device rather than global
and provide a low water mark for it.
Addresses PR: kern/24715
(at least according to the submitter.)
(tightly scoped) reason for recording the node address by recording
the assigned number. Dink pci/if_bge.c to match, since ic/ath.c was
used as the archetype.
yesterday's sys/dev/ic/ath.c) to match today's ath.c driver.
Commit now in the hope that Andrew Brown will pick up this file for
any more pending changes.
commit. The rate adaptation code expects them. Usually wi gets
lucky, and an Rx/Alloc/Info event triggers the interrupt handler,
but I had not intended for wi to count on it.
Without Tx/TxExc interrupts enabled, wi will sometimes exhaust all
its rssdescs and cease transmitting. Usually it sets IFF_OACTIVE
in that situation.
(c) TNF
line from 4-clause UCB to 3-clause UCB license; in other words,
remove UCB's ad clause from the license TNF grants.
There is no point in TNF demanding that UCB's ad clause be followed
when even UCB doesn't demand it any longer.
Ok'd by board@ and agc@.
RAID5 sets with more than 3 drives. Still need to figure out why
the original changes were losing, but need the version in tree reliable
first!
Huge THANKS to Juergen Hannken-Illjes for helping track down
the changes that were causing the lossage.
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.
sufficient to clobber this nasty little bug. The behaviour observed
was a panic when doing a 'raidctl -f' on a component when DAGs were
in flight for the given RAID set. Unfortunatly, the faulty behaviour
was very intermittent, and it was difficult to not only reliably
reproduce the bug (nor determine when it was fixed!) but also to even
figure out what might be the cause of the problem.
The real issue was that ci_vp for the failed component was being
set to NULL in rf_FailDisk(), but with DAGs still in flight, some
of them were still expecting to use ci_vp to determine where to
read to/write from!
The fix is to call rf_SuspendNewRequestsAndWait() from rf_FailDisk()
to make sure the RAID set is quiet and all IOs have completed before
mucking with ci_vp and other data structures. rf_ResumeNewRequests()
is then used to continue on as usual.
If raidPtr->numFailures isn't initialized properly, then all sorts of
whacky things can happen, including incorrect DAGs being generated.
(Triggering this problem is a little esoteric, which is why this bug has
been in hiding for so long -- I only saw it after rebooting with a
degraded RAID 5 set that was autoconfigured, rebuilding the failed
componennt, and then failing the component while IO was happening to
the RAID set.)
