summaryrefslogtreecommitdiffstats
path: root/sys/cam
Commit message (Collapse)AuthorAgeFilesLines
* Make HP T4000S quirk to FIXED modemjacob1999-01-111-1/+5
|
* Add 'static' to the declaration, too.eivind1999-01-111-2/+2
|
* Like the problems just fixed in scsi_da.c, make suremjacob1999-01-071-6/+17
| | | | | | | to release the probe ccb before taking down the periph. Also, don't do cdscheduling if you're not going to attach the device after all. Reviewed by: ken@freebsd.org
* A better fix to avoid race conditions between failed probesmjacob1999-01-071-6/+15
| | | | | and peripheral removal. Obtained from:gibbs@freebsd.org
* The Quantum Atlas III evidently has an identical problem to the Atlas II.ken1999-01-071-1/+22
| | | | | | | | | | | It keeps returning queue full until we have reduced the number of tagged openings to the minimum. So, put in a quirk entry with the same work-around. This quirk entry is only for the 9G Atlas III, once someone comes up with inquiry information for the 18G version of that drive, we can quirk it as well. Submitted by: "Johan Granlund" <johan@granlund.nu>
* The Conner CFP2107 is a fixed-media drive, not removable media. This fixesken1999-01-051-2/+10
| | | | | | | | | | | | | the quirk that disables tagged queueing for those drives. Also, silence a warning by disabling xpt_for_all_targets() and xpt_for_all_periphs(). These two functions are not currently used, but they should not be removed. They're part of a set of functions that provide a way to execute a function for every {bus,target,device,periph} in the system. If anyone needs to use either function in the future, they can be un-#ifdefed.
* Add a quirk that disables SYNCHRONIZE CACHEmjacob1999-01-051-1/+10
| | | | | PR: 8882 Obtained from: Hellmuth Michaelis hm@kts.org
* Temporary workaround (bandaid) for case where you have READmjacob1999-01-031-3/+5
| | | | | | | | CAPACITY fail for a non-removable media device. There's a race condition where the device entry is removed and then xpt_release_ccb is called which attempts to give back the ccb to a device that's now gone. In this bandaid release the ccb early and then remember to not call xpt_release_ccb later.
* Force ARCHIVE Vipers to be FIXEDmjacob1998-12-281-1/+5
|
* a more correct change that should meet the sniff testmjacob1998-12-241-14/+10
|
* Unstaticize swi_camnet && swi_cambio so Alpha kernels can build again.mjacob1998-12-241-3/+3
|
* you can retry SYNC CACHE on UA errorsmjacob1998-12-231-2/+3
|
* Staticize.eivind1998-12-223-17/+17
| | | | Reviewed by: gibbs
* Add a quirk NORRLS (no reserve/release) which can (andmjacob1998-12-221-39/+84
| | | | | | | | | | | | | | | | | | | | | will) get set for the devices that don't actually support reserve/release (so we don't keep trying it). Add softc storage and manage storing last I/O and CTL commands that had errors (for correlative purposes). In saclose clear the 'MOUNTED' bit if we either rewind or unload (yes, this shouldn't be necessary since the next open should catch whether a tape change occurred, but I'm having some questions about that actually working so this is safer for the moment). Oh, forgot to mention in previous commit messages that some of the failures particularly at close time cause the tape to be ejected (for the sake of safety)- all this prior to redoing the state machine (which is in progress) which will try and handle this better. Complete the addition of the setmark support (from Martin.Birgmeier@aon.at).
* 1) Fix some serious bugs (1 botch on my part which caused a filemark to bemjacob1998-12-191-40/+89
| | | | | | | | | | written even it the tape was opened readonly- 2 botches in deferred error handling for FIXED LENGTH mode which caused panic && hand resp.). Fixed a memory leak in sa_mount. 2) Fixed an annoying bug when turning of compression to actually reflect this for future status calls. 3) Implement the MTIOCERRSTAT call where latched control and I/O residuals and sense data are returned to the application asking for them.
* Add in block position/block locate functions.mjacob1998-12-181-21/+141
|
* Add structures and function definitions pertinent for hardware locate support.mjacob1998-12-181-1/+51
|
* Correct the definition of the changer device capabilities page. Thegibbs1998-12-171-1/+1
| | | | previous definition confused some reserved bytes for exchange capabilities.
* Add some tape specific density codes- only enough of them here to recognizemjacob1998-12-171-1/+17
| | | | | some specific older units so we can choose 2FM@EOD or FIXED blocksize quirks.
* Several changes having to do blocksize- mostly to force variable as the default.mjacob1998-12-171-51/+268
| | | | | | | | | | Attempt to determine (at mount time if not done so already) via density code whether a device should default to fixed mode or not. Attempts to set to variable that fail will cause fixed to be selected. Similarly, the '2 filemarks at EOM' quirk is now determined (or attempted to be determined) via density code. Some as yet not entirely tested code for coping with 2FM@EOD position is now also in place.
* Correctly track allocated accept target I/O ccbs so that they can begibbs1998-12-171-15/+17
| | | | | | | aborted prior to disabling our lun. This requires a second set of links since we use the ones in the ccb_hdr during normal operations. Nuke some unused variables.
* At Justin's request, limit the size of buffers that can be mapped intoken1998-12-161-4/+4
| | | | | | | | | | and out of kernel address space (via the pass(4) and xpt(4) peripheral drivers) to 64K (DFLTPHYS). Some controllers, like the Adaptec 1542, don't support more than 64K transactions. We plan on eventually having the capability of limiting this size based on min(MAXPHYS, controller max), but since that capability isn't here yet, limit things to the lowest common denominator.
* Probable fix for the "cdda2wav" panics that various people have beenken1998-12-161-47/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reporting since this past summer. (I think Daniel O'Conner was the first.) The problem appears to have been something like this: - cdda2wav by default passes in a buffer that is close to the 128K MAXPHYS limit. - many times, the buffer is not page aligned - vmapbuf() truncates the address, so that it is page aligned - that causes the total size of the buffer to be greater than MAXPHYS, which of course is a bad thing. Here's a quote from the PR (kern/9067): ================== In particular, note bp->b_bufsize = 0x0001f950 and bp->b_data = 0xf2219960 (which does not start on a page boundary). vunmapbuf() loops through all the pages without any difficulty until addr reaches 0xf2239000, and then the panic occurs. This seems to indicate that we are exceeding MAXPHYS since we actually started from the middle of a page (the data is being transfered to a non page aligned location). To complete the description, note that the system call originates from ReadCddaMMC12() (in scsi_cmds.c of cdda2wav) with a request to read 55 audio sectors of 2352 bytes (which is calculated to fall under MAXPHYS). This in turn ends up calling scsi_send() (in scsi-bsd.c) which calls cam_fill_csio() and cam_send_ccb(). This results in a CAMIOCOMMAND ioctl with a ccb function code of XPT_SCSI_IO. ================== The fix is to change the size check in cam_periph_mapmem() so that it is like the one in minphys(). In particular, it is something like: if ((buffer_length + (buf_ptr & PAGE_MASK)) > MAXPHYS) buffer is too big My fix is based on the one in the PR, but I cleaned up a fair number of things in cam_periph_mapmem(). The checks for each buffer to be mapped are now in a separate loop from the actual mapping operation. With the new arrangement, we don't have to bother with unmapping any previously mapped buffers if one of the checks fails. Many thanks to James Liu for tracking this down. I'd appreciate it if some vm-savvy folks would look this over. I believe this fix is correct, but I could be wrong. PR: kern/9067 (also, kern/8112) Reviewed by: gibbs Submitted by: "James T. Liu" <jtliu@phlebas.rockefeller.edu>
* Enable/Disable our lun on open/close. Track resources kept at the controllergibbs1998-12-151-95/+190
| | | | | | level so they can be reclaimed before attempting to disable our lun. Correctly free descriptors. Add periph locking and spl protection around open and close.
* Wire up the XPT_ABORT and XPT_RESET_DEV ccb function codes so they cangibbs1998-12-151-5/+5
| | | | | | be delivered to controller drivers. Adjust for changes to the ccb_hdr list types in cam_queue.h
* Add definitions for TAILQ, LIST, and SLIST ccb_hdr queues.gibbs1998-12-151-3/+5
|
* Return ENODEV instead of EINVAL when a particular exchange or movegibbs1998-12-121-3/+3
| | | | operation exceeds the capabilities of the changer device.
* Some fixes to handle fixed mode and variable mode more sensibly- and alsomjacob1998-12-111-46/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | incorporate some notion of which revision the device is. If it's < SCSI2, for example, READ BLOCK LIMITS is not a MANDATORY command. At any rate, the initial state is to try and read block limits to get a notion of the smallest and largest record size as well as the granularity. However, this doesn't mean that the device should actually *in* fixed block mode should the max && min be equal... *That* choice is (for now) determined by whether the device comes up with a blocksize of nonzero. If so, then it's a fixed block preferred device, otherwise not (this will change again soon). When actually doing I/O, and you're in fixed length mode, the block count is *not* the byte count divided by the minimum block size- it's the byte count divided by the current blocksize (or use shift/mask shortcuts if that worked out...). Then when you *change* the blocksize via an ioctl, make sure this actually propagates to the stored notion of blocksize (and update the shift/mask shortcuts). Misc Other: When doing a mode select, only use the SCSI_SAME_DENSITY (0x7f) code if the device is >= SCSI2- otherwise just use the saved density code. Recover from the ripple of ILLEGAL REQUEST not being 'retried' in that RESERVE/RELEASE is not a mandatory command for < SCSI2 (so ignore it if it fails).
* Convert dadump to use reasonable data types so that some casting is unecessary.gibbs1998-12-111-17/+17
|
* Do not attempt to retry commands that fail with ILLEGAL REQUEST status.gibbs1998-12-111-3/+3
|
* Convert debugging printfs to the CAM_DEBUG macro.gibbs1998-12-101-40/+50
| | | | | | Allow sync transfers if the controller supports it. Wide will follow as soon as I get the kinks worked out of wide target transfers in the aic7xxx driver (currently the only target mode driver in the tree).
* Expand the hba_misc fied in the Path Inquiry ccb to allow a controller drivergibbs1998-12-102-10/+65
| | | | | | | | to specify that it does not provide initiator services (PIM_NOINITIATOR) and that the initial bus reset for device probing should be avoided (PIM_NOBUSRESET). Modify the XPT layer to honor these flags.
* use CAM_DEBUG_XPT to track XPT; correct a misspellingmjacob1998-12-061-13/+16
|
* print the appropriate SCSI revision (with CCS as a proper name for the ↵mjacob1998-12-061-4/+8
| | | | announce message
* Add a CAM_DEBUG_XPT define (to debug XPT layer only). Add a CAM_DEBUGGEDmjacob1998-12-051-2/+8
| | | | | macro to be like the CAM_DEBUG macro but to instead provide a predicate result.
* Add in named SID field revision names (including CCS).mjacob1998-12-051-1/+8
| | | | | Add in named defines for DEFAULT and NOCHANGE densities (for sequential access devices).
* Examine all occurrences of sprintf(), strcat(), and str[n]cpy()archie1998-12-044-21/+15
| | | | | | | | | | | | | | 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>
* "Fix" a problem with the Quantum Viking. It appears that this drive doesken1998-12-021-4/+28
| | | | | | | | | | | | | not like the 6-byte read and write commands! It returns illegal request, with the field pointer pointing to byte 9 of a 6 byte CDB. In any case, the work around is to put in a quirk mechanism that makes sure that we don't send 6-byte reads or writes to this device. It's rather sad that this is necessary. You'd think that they would be able to get something that basic to work right in their firmware... Reviewed by: gibbs Reported by: Adam McDougall <bsdx@spawnet.com>
* ...nor does this old TDC3620 like to be asked for compression.joerg1998-11-261-1/+5
| | | | But well, now it's running again!
* This old firmware of the TDC3620 hangs the SCSI bus upon serialjoerg1998-11-251-1/+12
| | | | number requests. Don't ask it so.
* Fix a few problems that Bruce noticed about a month ago, and fix oup oneken1998-11-225-19/+46
| | | | | | | | | | | | other problem. - Hold onto splsoftcam() in the peripheral driver open routines until we have locked the periph. This eliminates a race condition. - Disallow opening the pass driver when securelevel > 1. - If a user tries to open the pass driver with O_NONBLOCK set, return EINVAL instead of ENODEV. (noticed by gibbs)
* Generalize the quirk entry that disables multi-lun probing for Sony CDROMken1998-11-041-4/+3
| | | | | | | drives. It seems that quite a few (possibly all?) of their drives respond to inquiries on multiple luns. Hopefully we can detect problems like this in the probe phase at some point. For now, this is a pretty functional solution.
* Fix a problem with the way we handled device invalidation when attachingken1998-10-2210-335/+438
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to a device failed. In theory, the same steps that happen when we get an AC_LOST_DEVICE async notification should have been taken when a driver fails to attach. In practice, that wasn't the case. This only affected the da, cd and ch drivers, but the fix affects all peripheral drivers. There were several possible problems: - In the da driver, we didn't remove the peripheral's softc from the da driver's linked list of softcs. Once the peripheral and softc got removed, we'd get a kernel panic the next time the timeout routine called dasendorderedtag(). - In the da, cd and possibly ch drivers, we didn't remove the peripheral's devstat structure from the devstat queue. Once the peripheral and softc were removed, this could cause a panic if anyone tried to access device statistics. (one component of the linked list wouldn't exist anymore) - In the cd driver, we didn't take the peripheral off the changer run queue if it was scheduled to run. In practice, it's highly unlikely, and maybe impossible that the peripheral would have been on the changer run queue at that stage of the probe process. The fix is: - Add a new peripheral callback function (the "oninvalidate" function) that is called the first time cam_periph_invalidate() is called for a peripheral. - Create new foooninvalidate() routines for each peripheral driver. This routine is always called at splsoftcam(), and contains all the stuff that used to be in the AC_LOST_DEVICE case of the async callback handler. - Move the devstat cleanup call to the destructor/cleanup routines, since some of the drivers do I/O in their close routines. - Make sure that when we're flushing the buffer queue, we traverse it at splbio(). - Add a check for the invalid flag in the pt driver's open routine. Reviewed by: gibbs
* Add a mechanism to send a non-tagged transaction even if a device isgibbs1998-10-151-1/+7
| | | | | | | | currently operating in a tagged mode. The SIM driver should determine if a device is in tag mode by looking at the CAM_TAG_ACTION_VALID flag in the ccb header. If the flag is set, the tag_action field is either a SCSI II tag message (simple, ordered, head) or CAM_TAG_ACTION_NONE to specify that no tagging should be performed.
* Fix several potential buffer overrun conditions. These changes have beenken1998-10-153-29/+116
| | | | | | | | 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
* Clean up some unused variables.ken1998-10-157-30/+8
| | | | | Reviewed by: ken Submitted by: phk
* Narrow the quirk entry for the Seagate Elite 9 a bit to just cover drivesken1998-10-141-2/+2
| | | | | with 71* firmware revisions. Scott Mace <smace@intt.ORG> reports that drives with 00* firmware revisions do tagged queueing just fine.
* Disable tagged queueing for the Seagate Elite 9GB drives. They tend to getken1998-10-141-1/+10
| | | | | | | | | hung up when you send tags to them too quickly. (CAM is able to recover from the problem, but this just avoids it altogether.) Reviewed by: gibbs Reported by: Bret Ford <bford@uop.cs.uop.edu> and: Martin Renters <martin@tdc.on.ca>
* Disable cache syncs for a broken NEC drive.ken1998-10-131-1/+9
| | | | | Reviewed by: gibbs Submitted by: Blaz Zupan <blaz@gold.amis.net>
* Fix a bug in the error recovery code. It was possible to have more thanken1998-10-132-2/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | one error recovery action oustanding for a given peripheral. This is bad for several reasons. The first problem is that the error recovery actions would likely be to fix the same problem. (e.g., we queue 5 CCBs to a disk, and the first one comes back with 0x04,0x02. We start error recovery, and the second one comes back with the same status. Then the third one comes back, and so on. Each one causes the drive to get nailed with a start unit, when we really only need one.) The other problem is that we only have space to store one CCB while we're doing error recovery. The subsequent error recovery actions that got started were over-writing the CCBs from previous error recovery actions, but we still tried to call the done routine N times for N error recovery actions. Each call to dadone() was done with the same CCB, though. So on the second one, we got a "biodone: buffer not busy" panic, since the buffer in question had already been through biodone(). In any case, this fixes things so that any any given time, there's only one error recovery action outstanding for any given peripheral driver. Reviewed by: gibbs Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk> [ Philippe wins the "bug finder of the week" award ]
OpenPOWER on IntegriCloud