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.
in the queue -- do not attempt to requeue it. We only poll in two cases:
1) We have a non-interrupting controller. In this case, execution of the
previous command should have left the queue empty. (Perhaps there should be
a KASSERT() to this effect.)
2) We're in the shutdown path, either doing a cache sync or a dump. In these
cases, the retry behavior is useless, because we will no longer get
interrupts to notify us that the earlier commands completed. Instead we
just spin for a few seconds and fail anyway. (XXX We should probably clear
the queue explicitly so that the shutdown/dump will succeed.)
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.
sd3(mpt0:0:1:0): unable to allocate scsipi_xfer
sd3: not queued, error 12
Havard Eidnes's analysis of this problem is that the scsipi_xfer pool is
competing for resources with other pools, including the the inode and vnode
pools which can grow quite large.
*_scsipi_cmd(): don't biodone the buffer if scsipi_make_xs() fails, let the
caller deal with the problem
start function of block devices drivers: dequeue the buffer after the
scsipi_command() call. If scsipi_command() fails with ENOMEM don't dequeue
the buffer, and schedule a callout to call the start function after
some delay.
scsipi_init(): prime the scsipi_xfer_pool with one page. This ensure that
there is always some scsipi_xfer to play with. If scsipi_command() fails
because of pool_get(), we're sure there will be resources available later,
when the pending commands have completed.
Reviewed by Jason Thorpe and Havard Eidnes.
Todo: remove the "unable to allocate scsipi_xfer" and "not queued, error %d"
printfs, but I choose to keep them for now, to help make sure the code does
what it should.
- only call periph_switch->psw_start() if the device is active; if it is not
psw_start() may try to access invalid data.
- remove the TAILQ_FIRST(&periph->periph_xferq) != NULL diagnostic in
scsipi_kill_pending(). This can't be true at this point (unless the device
was idle at the time of the detach), because the scsipi channel kernel
thread has to run for the queue to be flushed.
There are still other problems to be fixed here ...
Don't decrease/check xs_retries when the device report "Power On, Reset, or
Bus Device Reset" sense condition, just retry the command. The initial bus
reset would cause the first TEST_UNIT_READY to report this condition,
and as xs_retries is set to 0 when XS_CTL_DISCOVERY is set, it would report an
error instead of being retried, causing the disk probe to report "drive
offline" instead of the geometry and capacity. Checking/decreasing
xs_retries on the bus reset reported by the adapter is enouth to avoid the
problem reported by rev 1.102.
Problem analysed by Paul Kranenburg, fix confirmed by Anders Hjalmars,
and explaination as to why the INQUIRY wasn't affected by this provided by
Bill Studenmund.
itohy