and upgrade to using 10 byte cdbs.
As far as I tested, this works efficiently for most of the
SBP-II/Firewire devices but most of the umass devices still need
ad-hoc work around because umass-sim doesn't return any SCSI errors.
A sysctl nob is also added for the last resort.
I hope we don't need DA_Q_NO_6_BYTE quirks anymore.
Reviewed by: gibbs
MFC after: 1 week
deprecated in favor of the POSIX-defined lowercase variants.
o Change all occurrences of NTOHL() and associated marcros in the
source tree to use the lowercase function variants.
o Add missing license bits to sparc64's <machine/endian.h>.
Approved by: jake
o Clean up <machine/endian.h> files.
o Remove unused __uint16_swap_uint32() from i386's <machine/endian.h>.
o Remove prototypes for non-existent bswapXX() functions.
o Include <machine/endian.h> in <arpa/inet.h> to define the
POSIX-required ntohl() family of functions.
o Do similar things to expose the ntohl() family in libstand, <netinet/in.h>,
and <sys/param.h>.
o Prepend underscores to the ntohl() family to help deal with
complexities associated with having MD (asm and inline) versions, and
having to prevent exposure of these functions in other headers that
happen to make use of endian-specific defines.
o Create weak aliases to the canonical function name to help deal with
third-party software forgetting to include an appropriate header.
o Remove some now unneeded pollution from <sys/types.h>.
o Add missing <arpa/inet.h> includes in userland.
Tested on: alpha, i386
Reviewed by: bde, jake, tmm
time in the cases where it really sends the drive out to lunch, but it also
allows us to catch very wierd edge cases of strange drives that might take
a very long time (emulated disk drives over a network, e.g.).
quirk regarding the C- series makes me suspect that all Olympus models have
the same quirks, but I cannot prove it.
Submitted by: Bernd Walter <ticso@cicely8.cicely.de>
attempts to set buffered mode was printing out "unable to set buffered
mode" no matter what. Oops.
Spotted by: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
MFC after: 3 weeks
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
Clear residual counts after a successful samount (the user doesn't
care that we got an N-kbyte residual on our test read).
Change a lot of error handling code.
1. If we end up in saerror, check more carefully about the kind of
error. If it is a CAM_SCSI_STATUS_ERROR and it is a read/write
command, we'll be handling this in saerror. If it isn't a read/write
command, check to see whether this is just an EOM/EOP check condition-
if it is, just set residual and return normally. A residual and
then a NO SENSE check condiftion with the ASC of 0 and ASCQ of
between 1 and 4 are normal 'signifying' events, not errors per se,
and we shouldn't give the command to cam_periph_error to do something
relatively unpredictable with.
2. If we get a Bus Reset, had a BDR sent, or get the cam status of
CAM_REQUEUE_REQ, check the retry count on the command. The default
error handler, cam_periph_error, doesn't honor retry count in these
cases. This may change in the future, but for now, make sure we
set EIO and return without calling cam_periph_error if the retry
count for the command with an error is zero.
3. Clean up the pending error case goop and handle cases more
sensibly.
The rules are:
If command was a Write:
If we got a SSD_KEY_VOLUME_OVERFLOW, the resid is
propagated and we set ENOSPC as the error.
Else if we got an EOM condition- just mark EOM pending.
And set a residual of zero. For the longest time I was just
propagating residual from the sense data- but my tape
comparison tests were always failing because all drives I
tested with actually *do* write the data anyway- the EOM
(early warning) condition occurred *prior* to all of the
data going out to media- that is, it was still buffered by
the drive. This case is described in SCSI-2, 10.2.14,
paragraph #d for the meaning of 'information field'. A
better fix for this would be to issue a WFM command of zero
to cause the drive to flush any buffered data, but this
would require a fairly extensive rewrite.
Else if the command was a READ:
If we got a SSD_KEY_BLANK_CHECK-
If we have a One Filemark EOT model- mark EOM as pending,
otherwise set EIO as the erorr.
Else if we found a Filemark-
If we're in Fixed Block mode- mark EOF pending.
If we had an ILI (Incorrect Length Indicator)-
If the residual is less than zero, whine about tape record
being too big for user's buffer, otherwise if we were in
Fixed Block mode, mark EIO as pending.
All 'pending' conditions mean that the command in question completes
without error indication. It had succeeded, but a signifying event
occurred during its execution which will apply to the *next* command
that would be exexcuted. Except for the one EOM case above, we always
propagate residual.
Now, way back in sastart- if we notice any of the PENDING bits set,
we don't run the command we've just pulled off the wait queue. Instead,
we then figure out it's disposition based upon a previous command's
association with a signifying event.
If SA_FLAG_EOM_PENDING is set, we don't set an error. We just complete
the command with residual set to the request count (not data moved,
but no error). We continue on.
If SA_FLAG_EOF_PENDING- if we have this, it's only because we're in
Fixed Block mode- in which case we traverse all waiting buffers (which
we can get in fixed block mode because physio has split things up) and
mark them all as no error, but no data moved and complete them.
If SA_FLAG_EIO_PENDING, just mark the buffer with an EIO error
and complete it.
Then we clear all of the pending state bits- we're done.
MFC after: 4 weeks
