Commit Graph

16 Commits

Author SHA1 Message Date
Kenneth D. Merry
b0f62f0c1c Add quirk entries from Andre Albsmeier to disable the sync cache command
for the Quantum "MAVERICK 540S" and "LPS525S".

Also, add common string variables, since we seem to have a few Quantum and
Micropolis drives in here.

Fix the 'quantum' variable usage in scsi_all.c that likely got broken when
someone staticized things in cam_xpt.c.  (That particular problem would
cause Quantum Fireball ST drives to not get spun up if they were not
already spinning.)

Submitted by:	Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
2000-08-29 22:09:23 +00:00
Justin T. Gibbs
d4e2be3050 scsi_all.c:
Clean up the comments related to the high speed
	sync rate table for SPI.

scsi_message.h:
	Bring in some SCSI3 message terminology.  All SCSI2 names
	are still preserved for backwards compatibility.
2000-07-18 19:48:58 +00:00
Kenneth D. Merry
955f7e7474 Fix 'camcontrol inquiry'. The inquiry data structure changes (increased to
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>
2000-02-20 04:42:44 +00:00
Matt Jacob
366f55288e Go for the gusto and do the full 256 bytes for inquiry data.
Obtained from:gibbs@freebsd.org
2000-01-25 17:37:02 +00:00
Peter Wemm
664a31e496 Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL"
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.
1999-12-29 04:46:21 +00:00
David E. O'Brien
a5a299e5d7 Add FAST-80 timing to the scsi syncrates table.
Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1999-12-16 16:04:54 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Justin T. Gibbs
a0f37f55ee Do not attempt to retry commands that fail with ILLEGAL REQUEST status. 1998-12-11 03:53:05 +00:00
Matt Jacob
373524d467 print the appropriate SCSI revision (with CCS as a proper name for the announce message 1998-12-06 00:05:47 +00:00
Archie Cobbs
2127f26023 Examine all occurrences of sprintf(), strcat(), and str[n]cpy()
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.

These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.

Reviewed by:	Bruce Evans <bde@zeta.org.au>
Reviewed by:	Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by:	Mike Spengler <mks@networkcs.com>
1998-12-04 22:54:57 +00:00
Kenneth D. Merry
50642f180c Fix several potential buffer overrun conditions. These changes have been
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
1998-10-15 19:08:58 +00:00
Kenneth D. Merry
d05caa00c5 Add a new CAM debugging mode, CAM_DEBUG_CDB. This causes the kernel to
print out a one line description/dump of every SCSI CDB sent to a
particular debugging target or targets.

This is a good bit more useful than the other debugging modes, I think.

Change some things in LINT to note the availability of this new option.

Fix an erroneous argument to scsi_cdb_string() in scsi_all.c

Reviewed by:	gibbs
1998-10-02 21:00:58 +00:00
Kenneth D. Merry
e5b118dd3d In the bootverbose case, print out error messages for all errors that will
not be retried again, even if the SF_NO_PRINT flag is set.

Reviewed by:	gibbs
1998-09-29 22:11:30 +00:00
Kenneth D. Merry
66411419a6 Fix error recovery in scsi_interpret_sense(). It turns out that ERESTART
wasn't getting sent back for most errors, even if there were retries left
on the command.  I'm not sure how I ever let this slip by before...

In any case, we now send back ERESTART if there are retries left for the
command, and send back the default error code when there are no retries
left.

Reviewed by:	gibbs
1998-09-19 01:23:04 +00:00
Kenneth D. Merry
37b9efd37b Fix the CAM code so that people can compile kernels with the CD driver but
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
1998-09-18 22:33:59 +00:00
Justin T. Gibbs
76babe507b SCSI Peripheral drivers for CAM:
da	- Direct Access Devices (disks, optical devices, SS disks)
	cd	- CDROM (or devices that can act like them, WORM, CD-RW, etc)
	ch	- Medium Changer devices.
	sa	- Sequential Access Devices (tape drives)
	pass	- Application pass-thru driver
	targ	- Target Mode "Processor Target" Emulator
	pt	- Processor Target Devices (scanners, cpus, etc.)

Submitted by:	The CAM Team
1998-09-15 06:36:34 +00:00