at attachment time. Though this information is optional,
it allows to override our fixed timeouts with device
provided timeouts. These timeouts will override the
hardcoded values if the device provided timeouts
exceed the hardcoded values and are less than a day.
Using the device provided timeouts avoids premature
device resets and unreliable operation due to
inadequate timeouts.
Due to the limited implementations of USB
umass devices this feature is disabled for all
umass attached devices.
Do not shift (through integer promotion) a signed value in an operation
than can change the bit of signedness.
sys/dev/scsipi/scsipiconf.h:808:17, left shift of 255 by 24 places cannot be represented in type 'int'
Detected with Kernel Undefined Behavior Sanitizer.
Reported by <Harry Pantazis>
Data structures are now protected by a per-adapter mutex at IPL_BIO
that is created by the scsibus or atapibus instance when the adapter
is configured.
The enable reference counter and the channel freeze counter which are
currently used by HBA code before the adapter is configured, are made
atomic.
The target drivers are now all tagged as D_MPSAFE.
Almost all HBA drivers still require the kernel lock to present,
so all callbacks into HBA code are still protected by kernel lock
unless the driver is tagged as SCSIPI_ADAPT_MPSAFE.
TODO: refactor sd and cd to use dksubr.
be NULL), so that transport-specific details of transfer mode setting/printing
can be handled more easily.
Move scsipi_async_event_xfer_mode() and scsipi_print_xfer_mode() to
scsi_base.c and split in parallel scsi and FC/SAS parts.
size of struct scsipi_bustype has changed, welcome to 6.99.5
pass more informations about the bus:
- bustype_type has 2 different bytes, one holding the existing
SCSIPI_BUSTYPE_* (scsi, atapi, ata), and one for a per-SCSIPI_BUSTYPE_*
subtype. Introduce macros to build or extract bustype_type.
- for SCSIPI_BUSTYPE_SCSI, define subtypes for parallel SCSI, Fibre Channel,
SAS and USB, to specify the transport method. SCSIPI_BUSTYPE_SCSI_PSCSI
is 0 so that bustype_type value doesn't change for existing code
- for non-SCSIPI_BUSTYPE_SCSI busses there's no defined subtype yet,
so the bustype_type value doesn't change.
- provide scsi_fc_bustype, scsi_sas_bustype and scsi_usb_bustype
along with scsi_bustype to be used by bus driver where appropriate
- scsipi_print_xfer_mode(): more existing code under a
(SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_PSCSI) case, as
sync/wide parameters only make sense for parallel SCSI.
For (SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_FC) and
(SCSIPI_BUSTYPE_SCSI, SCSIPI_BUSTYPE_SCSI_SAS), only print
tagged queing status if enabled. Just be silent for other
bustypes.
This change is prompted by this problem:
right now, FC (e.g. isp(4)) and SAS (e.g. mfi(4)) don't
do anything for ADAPTER_REQ_SET_XFER_MODE, and especially never
call scsipi_async_event(ASYNC_EVENT_XFER_MODE), so sd(4) always
runs untagged. Doing a scsipi_async_event(ASYNC_EVENT_XFER_MODE) with
appropriate parameters is enough to enable tagged queuing,
but then scsipi will print:
sd0: async, 8-bit transfers, tagged queueing
which is harmless (async, 8-bit transfers doens't make sense on SAS anyway)
but will confuse users. With this change scsipi will only print:
sd0: tagged queueing
which is correct.
In the long run, knowning the underlying transport in scsipi will
allow better handling of device which are not parallel SCSI.
Another change adding an extra callback to struct scsipi_bustype {}
will come (so that scsipi_print_xfer_mode(), which is SCSI-specific,
can be moved out of scsipi_base, and split into per-subtype callback),
but this will break kernel ABI and so is not suitable for
netbsd-6, so will be commmited later. The above is enough to get
tagged queuing on FC and SAS in netbsd-6.
by defining 'options SCSIVERBOSE' in the kernel config file (no change
from current behavior), or it can be loaded at boot time on those
architectures that support the boot loader's "load" command.
The module is built for all architectures, whether or not SCSI or
atapi support exists.
- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
Use Request Sense only if Read Capacity succeeded and did not return
valid block size.
Discussed on tech-kern.
Fix the easier part of NetBSD PR kern/26537.
(The harder part is the device hangs on large (>= 8KB) transfer.
Possibly umass BBB problem?)
Remove scsipi_size() and scsipi_validate_secsize() from scsipi_base.c
and add their functions to sd.c since they are used only by sd.c.
Use SCSI term `block' instead of `sector' where applicable.
simply return zero for logical block size. In either case, use the sector
length reported by READ_CAPACITY instead of defaulting to 512 bytes.
This partially addresses the problems reported in PR port-i386/34707 and
PR kern/34737. Namely the incorrectly reported drive geometry and the
'hanging' issue.
However, since the device in question reports 2048-byte physical sectors
it will remain unusable until DEV_BSIZE is banished.
everything "scsi_*", since we really are talking about the SCSI command
set, ATAPI transport not withstanding. Improve the names of many structures,
and prepend "SCSI_" onto all SCSI command opcodes. Place items described
by the SCSI Primary Commands document into scsi_spc.h.
If the number of logical blocks exceeds the maximum value that is able to be
specified in the RETURNED LOGICAL BLOCK ADDRESS field, the device server
shall set the RETURNED LOGICAL BLOCK ADDRESS field to FFFFFFFFh. The
application client should then issue a READ CAPACITY (16) command (see 5.11)
to retrieve the READ CAPACITY (16) parameter data.
Implement this in scsipi_size().
First issue in kern/28514.
calling scsipi_make_xs() and scsipi_execute_xs(), instead push these into
scsipi_command. Make bustype_cmd and PHOLD/PRELE be called from
scsipi_execute_xs(). This allows us to create a xfer structure -- possibly on
the stack -- and call scsipi_execute_xs() directly.
scsipi_done() from their scsipi_request().
For this, add a struct scsipi_xfer * argument to scsipi_command().
If not NULL scsipi_command() will use this to enqueue this xfer, otherwise
it'll try to allocate a new one. This scsipi_xfer has to be allocated
and initialised by scsipi_make_xs() or equivalent.
In xxstart(), allocate a scsipi_xfer using scsipi_make_xs(), and if not NULL,
dequeue the buffer before calling scsipi_command(). This makes sure that
scsipi_command() will not fail, and also makes sure that xxstart() won't
be called again between the BUFQ_PEEK() and BUFQ_GET().
Fix "dequeued wrong buf" panics reported by Juergen Hannken-Illjes in
private mail and Andreas Wrede on current-users@.
Thanks to Jason Thorpe and Chuck Silver for review, and Andreas Wrede for
testing the patch.
OS needs such a hack, and the same drive works fine on Suns -- and is much
more likely to be a bug in the host adapter driver (which is corroborated by
the PQUIRK_NOLUNS).
kardel