Date: Sun, 08 Mar 1998 18:30:05 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: undisclosed-recipients:; Subject: New CAM snapshot available. Message-ID: <199803090133.SAA04697@pluto.plutotech.com>
next in thread | raw e-mail | index | archive | help
------- Blind-Carbon-Copy X-Mailer: exmh version 2.0.1 12/23/97 To: scsi@FreeBSD.org Subject: New CAM snapshot available. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Mar 1998 18:30:05 -0700 From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> The 980308 CAM snapshot is now available at the following locations: ftp.FreeBSD.org:/pub/FreeBSD/cam ftp.kdm.org:/pub/FreeBSD/cam The README available at these sites is reproduced below. As always, your comments about CAM are greatly appreciated. Thanks, Justin Common Access Method SCSI Layer "What is CAM? and why would I want it?" CAM is an ANSI ratified spec that defines a software interface for talking to SCSI and ATAPI devices. This new SCSI layer for FreeBSD is not strictly CAM compliant, but follows many of the precepts of CAM. More importantly, this work addresses many of the short comings of the previous SCSI layer and should provide better performance, reliability, and ease the task of adding support for new controllers. "Who is working on CAM?" Justin T. Gibbs <gibbs@FreeBSD.org> Kenneth D. Merry <ken@plutotech.com> General discussion about CAM usually occurs on the FreeBSD-scsi@FreeBSD.org list. "What hardware is supported?" Controller Drivers: Aic7xxx driver (ahc): This driver supports all of the devices the original FreeBSD driver supports but with the following new features: Support for aic7890/91/95 based controllers. ULTRA2 speeds have not yet been tested. I'd be happy to do so if someone wants to send me a drive. 8-) The driver now uses the secondary DMA FIFO to DMA SCBs and SG lists on controllers that support it. Although some prefetching is performed now, there is still much room for improvement. Autotermination support for all cards that support it. SCB paging that allows up to 255 SCBs to be active on aic7770, aic7850, and aic7860 cards. Bug fixes to the multi-lun support. The beginnings of a target mode implementation. AdvanSys Driver (adv): This driver supports the entire line of AdvanSys narrow channel devices. Tagged queuing is also supported. NCR Driver (ncr): This driver supports all of the devices the original driver supports, but does not yet have truely robust error recovery features implemented. Supported Peripherals: Direct Access driver (da): 512 byte sectored disk drivers. Support for other sector sizes is planned, but further investigation on the "right" approach for this is needed. It probably belongs in the disk-slice code. CDROM driver (cd): This driver should support everything the old driver did. Sequential Access driver (sa): This driver should support most "newer" tape drives. It does not have the ability to change either the density or compression settings yet. This is the "greenest" component in CAM currently, having only been tested on an Archive Python. Look for additional enhancements to this driver in the near term. "What versions of FreeBSD can I use CAM with?" CAM is developed under FreeBSD-current so most patch sets apply to a "current" of the day the snapshot was released. The patches will likely apply to source trees synched near that date, but there are no guarantees. As soon as the merging activity for 2.2.6 into -stable dies down, we plan on releasing a version of CAM for 2.2. CAM greatly increases the stability of the SCSI system and is currently being run on Wcarchive (a 2.2 environment). If your environment does not require device support that CAM has yet to offer and you are encountering SCSI related instabilities, you may want to give it a try when the next 2.2 patch set becomes available. "How reliable is it?" Although "work in progress", this code has been through over six months of testing here at Pluto in a RAID application. We feel pretty good about the stability of the code. If you do have the facilities to experiment (you must be running current), please do. We welcome your feedback especially about the performance and reliability of the new system. "How do I install it?" BACKUP YOUR OLD SRC TREE AND KERNEL!!!! cp /kernel /kernel.works Get the code: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-980308.diffs.gz On a FreeBSD-current system from ~980308 cd /usr/src zcat cam-980308.diffs.gz | patch -p1 cd usr.sbin/config make clean all install cd ../../sys/i386/conf vi MYKERNEL Comment out all unsupported SCSI devices, and substitute "da" for "sd" and "sa" for "st". Look in LINT or GENERIC for examples. config MYKERNEL cd ../../MYKERNEL make all make install "What are the features of CAM?" - Round-robin, per priority level scheduling of devices and their resources. - I/O Completion, error recovery, and processing queued I/O is performed in a separate software interrupt handler. The old system had the potential of blocking out hardware interrupts for lengthy periods as much of this processing occurred as the result of a call from the controller's interrupt handler. - The generic SCSI layer now understands tagged I/O and exports this functionality to the peripheral drivers. This allows drivers like the "direct access" driver to perform ordered tagged transactions for meta-data writes. Async, ordered, meta-data writes are now enabled in vfs_bio.c - The "direct access" driver prevents "tag starvation" from occurring by guaranteeing that at least one write in every 5 second period to a tagged queuing device has an ordered tag. This removes the need for individual controller drivers to worry about this problem. - Complete and controller independent handling of the "QUEUE FULL" and "BUSY" status codes. The number of tags that are queued to a device are dynamically adjusted by the generic layer. - Interrupt driven sub-device probing. At boot time, all buses are probed in parallel yielding a much faster boot. As probing occurs after all interrupt and timer services are available, no additional (and often error prone) "polling" code is needed in each controller driver. - Better error recovery. When an error occurs, the queue of transactions to the erring device is "frozen", full status is reported back to the peripheral driver, and the peripheral driver can recover the device without perturbing queued up I/O. As all transactions have an associated priority and generation count, after recovery is complete, transactions that are retried are automatically re-queued in their original order. - All error handling is performed based on a detected failure. The old code would often perform actions "just in case" before accessing a device as the error recovery mechanism was inadequate. Now, for example, if your disk spins down, the system will properly recover even if the device is already open. - Support for "high power" commands. Peripheral drivers can mark actions that may tax a power supply as "high powered". Only a certain number (default of 4, but configurable with the CAM_MAX_HIGHPOWER kernel option) of these commands are allowed to be active at a time. This allows a user to, for example, disable spin-up on the drives in an enclosure and let the system spin them up in a controlled fashion. - By default, all luns are scanned on devices during probe. In the old SCSI layer, this was often problematic as it performed a Test Unit Ready prior to performing an Identify. Many devices that properly handle the Identify will hang the bus if you attempt a different command to a high lun. - Transfer negotiations only occurs to devices that actually support negotiations (based on their inquiry information). This is performed in a controller independent fashion. - There is now a generic quirk mechanism that allows controllers, peripheral drivers, or the CAM transport layer to define their own quirks entries. Currently the CAM transport layer has quirk entries that allow for modulation of tags and disabling multi-lun probing. The AdvanSys driver uses quirk entries to control some of the "hardware bug fixes" in the driver that only apply to certain types of devices. - Hard-wiring of devices to specific unit numbers is supported as it was in the old system. - Userland "pass-through" commands are supported. The interface is different than from the old SCSI code, but sample code is provided (including patches to XMCD), and we also provide the beginnings of a "scsi.8" utility in the form of "camcontrol". Features added in the 971211 Snapshot: - Preliminary tape support. This has only been tested on a DDS2 drive and the driver is fairly green. - New device statistic code. A whole slew of information is now recorded on a per-device basis. The interface is generic and once we have systat converted to using this code, all other drivers using the old "dk" stat interface will be converted. The Iostat utility has already been converted to use the new stats. - Bus DMA based bounce buffer support. ISA AdvanSys support now works in all memory configurations. - aic7xxx driver improvements. The aic7895 is now supported. The command queing algorithm is now more efficient. Bug fixes include some problems with error recovery and target initiated sync/wide negotiation. - AdvanSys driver improvements. The driver has now been tested on almost every narrow SCSI card AdvanSys has produced. Many bugs in the device probe code have been fixed. - Table driven error handling. This greatly simplifies the task of enhancing or modifying how errors are handled. - Enhanced PCI conf support. Although this isn't really CAM related, you get it for free. Check out the pciconf utilty for details. - Numerous other bug fixes I've forgotten about. Features added in the 980103 Snapshot: - Preliminary NCR/Symbios adapter support. Regular operations should be fine, but the error recovery portions of this driver need work. - iostat is now fully functional. - Fixed an infinite retry bug in the Adaptec driver's error recovery code. - Fixed a bug that prevented disconnections and ultra speeds for target ids above 7 in the Adaptec driver. - Expanded the use of bowrite to other locations where synchronous writes were used only to maintain write ordering. - The disk drivers now perform the buffer elelevator sort even if the device supports tags. - The da driver will now only invalidate the media if it believes the media or device has changed. This means that errors like unrecoverable media errors will not prevent future reads and writes (e.g. to remap a sector). - Userconfig.c now compiles. - Correct ccd to initialize b_resid to 0 as all other buffer allocators in the kernel do so that low level driver code only needs to touch b_resid in the error case. - Transfer negotiation now occurs earlier in the probe sequence so that the messages output at boot time have the final and proper negotiation info in them. - When performing the mode sense during probe to retrieve the control page, we nolonger attempt to use the DBD bit. Some devices don't like that. Changes for the 980308 Snapshot: - Aic7xxx driver now supports the 7890/91 (AKA 2940U2W). This includes support for the new "bmov" instruction, and some utilization of the secondary DMA FIFO for S/G list prefetch on aic7890/91/95 chips. ULTRA2 speeds have not been tested as I do not have any ULTRA2 peripherals to test with. - CAM now differentiates between "user" transfer settings and "current" transfer settings. When a controller starts up, it's current settings should be async/narrow and it's user settings should reflect any configured settings for the card (e.g. SCSI-Select settings) or the defaults if configuration is not supported. During device probe, the XPT layer will querry for the user settings, filter them based on the capabilities of the device and use the result to set the current settings. The aic7xxx driver has been updated to deal with these changes including a new scheme for storing and handling negotiation settings in that driver. Updating the other drivers will follow shortly and is trivial to do. - Full kernel hot swap support. The kernel and all peripheral drivers can handle devices arriving and going away after boot up. - To determine whether any new devices have arrived, you must rescan a SCSI bus, or rescan a particular device by completely specifying it's bus/target/lun. This can be done with the new "camcontrol" utility. Although it would be possible to have the kernel "auto-detect" some new devices using Asynchronous Even Notifications (AEN), no controller driver currently supports AENs and device support for AENs is rare, so AEN support is low on the wish list. - The kernel can figure out that a device has gone away if it gets a selection timeout while talking to the device. In that case, the kernel will automatically invalidate the device and all attached peripheral drivers. You can also issue a rescan of a bus or a bus/target/lun and the kernel will notice if any devices have gone away. - Device removal goes in two stages: - The kernel notices (either through a rescan or a selection timeout) that a device has gone away. It marks the device as invalid, and prints out something like this: (cd5:ahc1:0:1:3): lost device At this point, the peripheral driver will still exists if it is open, although in a state where all new opens, ioctls and I/O requests are refused. This ensures that the system can gracefully handle final close of the device. - Once final close of the device occurs (all userland processes that have the device open issue a close), the kernel finishes removing that peripheral driver instance. The kernel then prints out something like this: (cd5:ahc1:0:1:3): removing device entry Then, and only then, can another peripheral driver with the same unit number take its place. The system enforces this behavior to ensure that all clients release the device, thereby acknowledging the error condition, before any new or old clients can access the new device instance. Be aware when removing a device that even though the "regular" peripheral driver (cd, sd, sa) for a device has gone away, the passthrough peripheral driver, if still open, will still be around. For instance, if you're playing a CD with xmcd, xmcd will only have the passthrough device open, not the cd device. If you unplug the CDROM drive from the SCSI bus, the cd device will go away on the next rescan or selection timeout since you don't have a CD filesystem mounted. The passthrough device will not release, though, until you exit XMCD. The passthrough device is normally "silent" about it's presense, and by default will not print any messages when it arrives or goes away. If you boot with -v, the passthrough driver will print out probe messages and arrival/departure messages. - Better CD changer support. The CAM CDROM driver now automatically detects lun-based CD changers and schedules run time for each lun. This greatly reduces the changer thrashing caused by multiple users or applications accessing multiple CDs on a changer at the same time. - Changer detection is rather simplistic -- if the CD driver sees a CDROM device with a LUN greater than 0, it assumes that that device is part of a changer. All luns of that target will be included in a changer meta-driver, and scheduled to run on a mutually exclusive basis. - Each lun on a changer gets a minimum and a maximum amount of run time. The compiled in defaults are 2 seconds and 10 seconds, respectively, but they can be changed easily by the end user. The maximum run time is only enforced if there is another lun on the changer with I/O waiting. The default minimum and maximum run time can be changed in the kernel config file. See LINT for details. They can also be changed on the fly via two new sysctl variables: kern.cam.cd.changer.min_busy_seconds kern.cam.cd.changer.max_busy_seconds So you can interactively tune your changer's performance to suit your changer and usage patterns. - If anyone actually has a CD tower or other peripheral with independant devices reported on each LUN (not target!), please send probe (i.e. boot) output to ken@plutotech.com. I'll put a quirk entry in the CD driver so that your device doesn't get recognized as a changer. Many thanks go to Lars Fredriksen for letting us borrow his changer to perform this work. - New camcontrol utility. There is no man page for it yet, but eventually this should be at least as useful as scsi(8). For now, it can: - list CAM peripherals attached to a given device - send a test unit ready to a given device - send a SCSI inquiry to a device (and yes, Satoshi, you can print out a drive serial number all by itself. :) ) - send a start/stop unit command to a device (and optionally load or eject media) - rescan a given bus for new/removed devices, or rescan a given bus/target/lun to see if it is present or has gone away - read the defect list (permanant or grown) for a given drive. - Tape driver enhancements. - The CAM tape driver now supports the retension, offline/rewoffl and erase mt(1) commands. - The tape driver also will reserve and release a tape drive on open and close, respectively. This insures mutually exclusive access to the tape drive in multiple initiator environments. - mt(1) has been updated with a number of new densities, and now prints out the bits per inch for each density. - Improved statistics support. Almost every SCSI command sent to a device is now recorded in the devstat facility. Before, some commands, especially non block I/O commands, fell through the cracks. - New transport layer device driver. This drive accepts CCB types that don't apply to a single device (e.g. bus rescanning CCBs). It also accepts the getpassthrough ioctl, and thus performs matching between peripheral drivers and their corresponding passthrough drivers. This change allows users to perform diagnostics on a device using the passthrough driver, even if the normal peripheral driver for the device can't be opened. For instance, you can issue a test unit ready to a CDROM device even when there is no media in the drive. - Updated userland CAM library. - The CAM library interface has been changed to take advantage of the new transport layer device. So, there is now a cam_open_spec_device() function. This allows you to individually specify the device name (e.g. "da", "cd", "sa") and unit number for the peripheral driver you want to open. cam_open_device() now just tries to derive the peripheral name and unit number from the passed in device path. It then passes those in to the real open function. - The CAM library now includes a number of tape-related CCB building functions. - -- Justin T. Gibbs <gibbs@FreeBSD.org> Kenneth D. Merry <ken@plutotech.com> ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803090133.SAA04697>