rather than 10ths of ns. This is necessary in order to represent
Ultra320 SCSI.
* Add Ultra320 SCSI to the scsipi_syncparams[] table.
We're not going to bother bumping any version numbers with this change; only
the "hba" driver uses scsipi_sync_period_to_factor(), and the uses of
scsipi_sync_factor_to_period() are all internal to the scsipi code. Most
things just pass the factor around, which is unchanged by this.
Reviewed by Frank van der Linden.
This eliminates problems where the underlying interrupt handler isn't the
specific layer calling scsipi_complete() for a given scsi transaction.
This avoids deadlocks where the kthread that called the autoconf routines
to configure a scsibus shouldn't be the one put to sleep waiting on a
scsipi_complete (only the scsibus's kthread should be doing that).
To avoid jitter this will force the scsibus's to probe in the order they
run through autoconf (so machines with multiple bus's don't move sd* devices
around on every reboot).
XS_SELTIMEOUT and XS_TIMEOUT errors- but only do so if the device exists
already.
Devices that are being probed won't be found via periph_lookup, so we can
use that to find if a device exists for the purposes of honoring retries.
Set this to dv_xname for scsibus and atapibus.
Set the name of the kernel thread to chan_name instead of controller's
name:channel number (so that we can use this name for controller-specific
threads).
normal case, and in the polling or "no thread yet" cases:
don't return an error from scsipi_complete(), as the error should already have
been handled in scsipi_complete() and eventually periph driver callbacks.
Should fix kern/15190.
deal with shortages of the VM maps where the backing pages are mapped
(usually kmem_map). Try to deal with this:
* Group all information about the backend allocator for a pool in a
separate structure. The pool references this structure, rather than
the individual fields.
* Change the pool_init() API accordingly, and adjust all callers.
* Link all pools using the same backend allocator on a list.
* The backend allocator is responsible for waiting for physical memory
to become available, but will still fail if it cannot callocate KVA
space for the pages. If this happens, carefully drain all pools using
the same backend allocator, so that some KVA space can be freed.
* Change pool_reclaim() to indicate if it actually succeeded in freeing
some pages, and use that information to make draining easier and more
efficient.
* Get rid of PR_URGENT. There was only one use of it, and it could be
dealt with by the caller.
From art@openbsd.org.
using the ahc driver hang when probing scsi devices. The problem may be in
the ahc driver and not in this change, but back it out until this has been
fixed anyway.
called via a callout, kick the completion thread to run it for us (uses
a new flag, SCSIPI_CHAN_KICK).
If we've received BUSY status and we haven't started the completion
thread yet, don't freeze do a callout to scsipi_periph_timed_thaw which
then will try and kick the completion thread- instead treat the command
as if it were a polled command and just call delay for 1 second.
If DIAGNOSTIC is defined, and the periph qfreeze count is less than
zero, panic because some HBA has corrupted the periph structure's
accounting.
not present" don't print any message but still return ENODEV.
Use this in cd driver to allow open of character raw partition even if
the drive is empty (older drives fails at LOAD_UNLOAD time, newer
ones fail at TEST_UNIT_READY time).
some devices can't handle tag number larger than some values and always
reject commands with QUEUE FULL if the tag number is larger than this.
Under some circonstances the scsipi system may not decrease periph_openings
(as a workaround of other odd behavior) and we may end up requeuing the command
with a hight tag value again, and the driver could loop on this.
Workaround: in case of queue full, decrease periph_openings to
min(periph_active - 1, periph_openings - 1) so that, after some iteration,
periph_openings is less than the max tag value acceptable by the device.
Solves the problem with tagged queuing on ncr53c9x for me.
This is a completely rewritten scsipi_xfer execution engine, and the
associated changes to HBA drivers. Overview of changes & features:
- All xfers are queued in the mid-layer, rather than doing so in an
ad-hoc fashion in individual adapter drivers.
- Adapter/channel resource management in the mid-layer, avoids even trying
to start running an xfer if the adapter/channel doesn't have the resources.
- Better communication between the mid-layer and the adapters.
- Asynchronous event notification mechanism from adapter to mid-layer and
peripherals.
- Better peripheral queue management: freeze/thaw, sorted requeueing during
recovery, etc.
- Clean separation of peripherals, adapters, and adapter channels (no more
scsipi_link).
- Kernel thread for each scsipi_channel makes error recovery much easier
(no more dealing with interrupt context when recovering from an error).
- Mid-layer support for tagged queueing: commands can have the tag type
set explicitly, tag IDs are allocated in the mid-layer (thus eliminating
the need to use buggy tag ID allocation schemes in many adapter drivers).
- support for QUEUE FULL and CHECK CONDITION status in mid-layer; the command
will be requeued, or a REQUEST SENSE will be sent as appropriate.
Just before the merge syssrc has been tagged with thorpej_scsipi_beforemerge
fvdl