Date: Mon, 17 Jul 1995 09:56:54 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: stratlif@grail.cba.csuohio.edu (steven ratliff) Cc: freebsd-hackers@freebsd.org Subject: Re: SCSI drivers Message-ID: <199507171656.JAA11318@ref.tfs.com> In-Reply-To: <199507162113.OAA08474@freefall.cdrom.com> from "steven ratliff" at Jul 16, 95 05:15:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
we already do most of this.. > > > The following may be irrelevant as I haven't looked at nor understand > FreeBSD's current SCSI system but I found the following News article > interesting. Particularly the section on error handling and recovery. > > Someone who does understand FreeBSD's SCSI might want to look at > this driver for Ideas on implementing a similar scheme if we don't already > do this. This might help with the rash of SCSI device hang reports that have > been posted recently. > > Steve > > DRIVER FEATURES > > o Configuration Reporting and Testing > > During system initialization, this driver reports extensively on the host > adapter hardware configuration, including the synchronous transfer > parameters negotiated with each target device. In addition, this driver > tests the hardware interrupt configuration to verify that interrupts are > actually delivered to the interrupt handler. This should catch a high > percentage of PCI motherboard configuration errors early, because when > the host adapter is probed successfully, most of the remaining problems > appear to be related to interrupts. We autoconfigure to thte interrupt th eboard is on but the interupt code isn't running yet so we can't TEST it. We already do all the other reporting (if asked) > > o Performance Features > > BusLogic SCSI host adapters directly implement SCSI-2 tagged queuing, and > so support has been included in this driver to utilize tagged queuing > with any target devices that report the tagged queuing capability. > SCSI-2 tagged queuing allows for multiple outstanding commands to be > issued to each target device, and can improve I/O performance > substantially. In addition, BusLogic's Strict Round Robin Mode is used > to optimize host adapter performance, and scatter/gather I/O can support > as many segments as can be effectively utilized by the I/O subsystem. we've done most of this since day 1 by default we are supporting 4 parallel operations passed to each disk. > > o Error Recovery > > This driver implements extensive error recovery procedures. When the > higher level parts of the SCSI subsystem request that a command be reset, > a bus device reset is first sent to the target device. If two bus device > resets have been attempted and no command to the device has completed > successfully, then a host adapter hard reset and SCSI bus reset is > performed. SCSI bus resets caused by other devices and detected by the > host adapter are also handled by issuing a hard reset to the host adapter > and full reinitialization. This strategy should improve overall system > robustness by preventing individual errant devices from causing the > system as a whole to lockup or crash, and thereby allowing a clean > shutdown and restart after the offending component is removed. we need to do more work on this part, but the basics are in place > > o Shared Interrupts Support > > On systems that support shared interrupts, any number of BusLogic host > adapters may share the same interrupt request channel. This driver scans > all registered BusLogic host adapters whenever an interrupt is handled on > any interrupt channel assigned to a BusLogic host adapter. Our system doesn't support it... the same (well an earlier version of it) driver DOES share interrupts on OSF1/386 (the OS supports shared interrupts) > > o Symmetric Multiprocessing Support > > While the Linux Kernel is currently limited to uniprocessors, there are > efforts being made to support symmetric multiprocessing (SMP) systems. > With that in mind, this driver implementation uses separate primitives > for disabling processor interrupts versus mediating exclusive access to > the host adapter hardware and driver data structures, so that when a > symmetric multiprocessing Linux Kernel becomes available, this driver > should only need relatively minor changes. It's too early to do this until we have a better idea of What approach we are going to take for MP. > > o Wide SCSI Support > > All BusLogic host adapters share a common programming interface, except > for the inevitable improvements and extensions as new models are > released, so support for Wide SCSI data transfer has automatically been > available in existing drivers. This driver adds explicit support for up > to 16 Device IDs and 64 Logical Units, to fully exploit the capabilities > of the newest BusLogic Wide SCSI host adapters. this is not an issue the the BL driver under FreeBSD but the generic SCSI code. We already support 16 devices.. it's needed for the wide NCR and adaptec adapters as well. > > Having said all that it does highlight the fact that I've been concentrating on work and not FreeBSD, and that a major SCSI cleanup is becoming needed.. This seems to happen every 9 months or so. since I wrote it in 1991, it's been through 5 rewrites and definitly needs a new one about now.. julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507171656.JAA11318>