256 bytes) caused it to break on many devices.
The SCSI spec says that for commands with 8-bit length fields, a value of 0
means 256 bytes. As it turns out, many devices don't deal with that
properly. Some interpret the 0 as 0, and return no data. Others return
more than 256 bytes of data, and cause an overrun.
The fix is to tell the device we've only allocated SHORT_INQUIRY_LENGTH (36
bytes) of inquiry data, instead of sizeof(struct scsi_inquiry_data).
camcontrol.c: Change inq_len in the call to scsi_inquiry() to
SHORT_INQUIRY_LENGTH, and add a long comment
explaining the reason for the change.
scsi_all.h: Add a comment above the definitinon of
SHORT_INQUIRY_LENGTH alerting people that it is
both the initial probe inquiry length, and the
minimum amount of data needed for scsi_print_inquiry()
to function.
scsi_all.c: Add a comment about SHORT_INQUIRY_LENGTH being the
minimum amount of data needed for
scsi_print_inquiry() to function.
Reviewed by: gibbs
Approved by: jkh
Reported by: "John W. DeBoskey" <jwd@unx.sas.com>
full size. Define a SHORT_INQUIRY_LENGTH for use during initial
probing (covers the size used previously). Define some SPC-2 related
fields (and define the revision code for SPC-2) which includes some
further SPI-3 defines. Don't go all the way (256 bytes) for the structure-
stop 4 bytes short- because we haven't auditted the source base to find
any u_int8_t potential overflow issues. Add RBC (single byte device)
and OCR (Optical Character Reader) device type codes.
Approved by JKH.
Reviewed by: gibbs@freebsd.org, ken@freebsd.org
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
code in all initiator type peripheral drivers.
scsi_target.c:
Release ATIO structures that wind up in the 'unkown command queue'
for consumption by our userland counterpart, back to the controller
when the exception for that command is cleared.
If the client requests that the error recovery code retry a selection
timeout, it will be retried after half a second. The delay is to give the
device time to recover.
For most of these drivers, I only added selection timeout retries where
they were also retrying unit attention type errors. The sa(4) driver calls
saerror() in a number of places, but most of them don't request retrying
unit attentions.
Also, bump the default minimum CD changer timeout from 2 to 5 seconds and
the maximum timeout from 10 to 15 seconds. Some Pioneer changers seem to
have trouble with the shorter timeout.
Reviewed by: gibbs
tested both in the kernel and in userland. Also, fix a couple of printf
warnings that show up when CAMDEBUG is defined.
Reviewed by: imp
Partially submitted by: imp
block descriptors enabled on mode sense commands.
Basically, we try sending a mode sense with block descriptors disabled (the
previous default), and if it fails, we try sending the mode sense with
block descriptors enabled. If that works, we note that in a runtime quirk
entry, so we don't bother disabling block descriptors again for the device.
This problem was first reported by Chris Jones <cjones@honors.montana.edu>
on one of the NetBSD lists, but I'd imagine that some FreeBSD users would
have run into it eventually as well, since our changer driver is derived
form the NetBSD changer driver.
Also, change some of the probe logic so that we do the right thing in the
case of a failure to attach.
Fix a memory leak in chgetparams().
Add a couple of inline helper functions to scsi_all.h to correctly return
the start of a mode page.
NetBSD PR: kern/6214
Reviewed by: gibbs
without the DA driver.
The problem was that the CD driver depended on scsi_read_write() and
scsi_start_stop(), which were defined in scsi_da.c.
I moved both functions, and their associated data structures and defines
from scsi_da.* to scsi_all.*. This is technically the "wrong" thing to do
since those commands are really only for direct-access type devices, not
for all SCSI devices. I think, though, that the advantage (allowing people
to compile kernels without the disk driver) outweighs any architectural
purity arguments.
PR: kern/7969
Reviewed by: gibbs
