way of doing business- modulo some startup spasms and peculiarities
of the way kthreads are started (*after* configuration, weird) and
some strangeness with the freeze/thaw code, what now happens is
that any of Loop Down, LIP, Loop Reset or Port Datbase or Name
Server Database Changed ASYNC events cause the queues to freeze
for this channel. The arrival of a Loop UP is not relevant.
What *is* relevant is that the Port Datbase or Name Server Changed
async event indicate that it's okay to go and (re)evaluate the
state of the FC link and (re)probe local loop and fabric membership.
We have a kthread do this because it's *sooooo* much nicer to be
able to sleep while doing the 130-250 mailbox commands it'll take
to re-evaluate things.
When the state is well known again, we can unfreeze the channel
queues. Then, as commands start arriving, we simply can start them
or bounce them with XS_SELTIMEOUT (if the device in question has
gone away). Previously, we did lazy evaluation, which meant that
if a change occurred, we would wait until the very *next* command
to go rebuild stuff.
The reason this is not sensible is:
a) Even with sleeping, you can hang up your system because you might be
making some poor stat(2) call pay the price of re-evaluating the whole
fabric.
b) If we ever really want to get to dynamic attachment/detachment, we
should find out sooner, rather than later, where things get to.
Split off ispminphys_1020 from ispminphys- a 1020 has a 24 bit limit-
not anything newer.
Re-enable LIPs and Loop Resets as async events- this allows the outer
layer to set policy about them.
Roll platform major && minor. Remove bogus waitq (no longer used).
Remove callout entry in softc (no longer used). Define some shorthands
for channels. Clean up a variety of cruft left over from the
thorpej_scsipi changeover.
The ISO C standard says in 6.10.3.3 that if the result of using the
'##' operator "is not a valid preprocessing token, the behaviour is
undefined." Gcc 3.0 warns about this.
Note that I've kept the existing quirk of still passing the irq to the next handler even if the irq handler returned 1. I need to investigate why we do this.
(and unlock) the other pmap's pte's before continuing to the next
pmap. Avoids pmap lock leaks (generates LOCKDEBUG warning, deadlocks
MULTIPROCESSOR).
(I have a nice 'install' target for cobalts here, but that only works there.
I guess I'll put that into htdocs now that the cobalt port uses Makefile.mips)
word32 pointers to access data stored in word8 arrays:
* align transformation tables on 32-bit boundaries,
* align key schedule on 32-bit boundary,
* align temporaries on 32-bit boundaries,
* align plaintext and ciphertext used in round transformations on 32-bit
boundaries.
Add SD_IO_TIMEOUT (an option in opt_scsi.h) also, which defaults to the
normal 60 * 1000 timeout for normal read/write commamds. This allows you
to shorten or lengthen the timeout as needed.
handler to clear hardware interrupt bit and schedule actual handlers
using soft interrupts registered with desired IPL.
XXX This slows down interrupt handling a bit (up to a few percent with
XXX ping -f or make-over-NFS benchmarks) in some cases.
bjh21