This section gives specific information about the various host adapters that are supported in some way or another under linux.
Drivers in the distribution kernel :
Adaptec 152x, Adaptec 154x (DTC 329x boards usually work, but are unsupported), Adaptec 174x, Adaptec 274x/284x (294x support requires a newer version of the driver), BusLogic MultiMaster Host Adapters, EATA-DMA and EATA-PIO protocol compilant boards (DPT PM2001, PM2011, PM2012A, PM2012B, PM2021, PM2022, PM2024, PM2122, PM2124, PM2322, PM2041, PM2042, PM2044, PM2142, PM2144, PM2322, PM3021, PM3122, PM3222, PM3224, PM3334 some boards from NEC, AT&T, SNI, AST, Olivetti, and Alphatronix), Future Domain 850, 885, 950, and other boards in that series (but not the 840, 841, 880, and 881 boards unless you make the appropriate patch), Future Domain 16x0 with TMC-1800, TMC-18C30, or TMC-18C50 chips, NCR53c8xx,PAS16 SCSI ports, Seagate ST0x, Trantor T128/T130/T228 boards, Ultrastor 14F, 24F, and 34F, and Western Digital 7000.
MCA :
MCA boards which are compatible with a supported board (ie, Adaptec 1640 and BusLogic 640) will work.
Alpha drivers :
Many ALPHA drivers are available at
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi
Drivers which will work with modifications
NCR53c8x0/7x0:
A NCR53c8xx driver has been developed, but currently will not work
with NCR53c700, NCR53c700-66, NCR53c710, and NCR53c720 chips. A list
of changes needed to make each of these chips work follows, as well
as a summary of the complexity.
NCR53c720 (trivial) - detection changes, initialization changes, change
fixup code to translate '810 register addresses to
'7xx mapping.
NCR53c710 (trivial) - detection changes, initialization changes,
of assembler, change fixup code to translate '810 register
addresses to '7xx mapping, change interrupt handlers to treat
IID interrupt from INTFLY instruction to emulate it.
NCR53c700, NCR53c700-66 (very messy) - detection changes,
initialization changes, modification of NCR code to not use DSA,
modification of Linux code to handle context switches.
SCSI hosts that will not work :
All parallel->SCSI adapters, Rancho SCSI boards, and Grass Roots SCSI boards. BusLogic FlashPoint boards, such as the BT-930/932/950, are currently unsupported.
SCSI hosts that will NEVER work :
Non Adaptec compatible, non NCR53c8xx DTC boards (including the 3270 and 3280).
CMD SCSI boards.
Acquiring programming information requires a non-disclosure agreement with DTC/CMD. This means that it would be impossible to distribute a Linux driver if one were written, since complying with the NDA would mean distributing no source, in violation of the GPL, and complying with the GPL would mean distributing source, in violation of the NDA.
If you want to run Linux on some other unsupported piece of hardware, your options are to either write a driver yourself (Eric Youngdale and I are usually willing to answer technical questions concerning the Linux SCSI drivers) or to commission a driver (Normal consulting rates mean that this will not be a viable option for personal use).
With some host adapters (see Buyers' Guide : Feature Comparison), you can use multiple host adapters of the same type in the same system. With multiple adapters of the same type in the same system, generally the one at the lowest address will be scsi0, the one at the next address scsi1, etc.
In all cases, it is possible to use multiple host adapters of different types, provided that none of their addresses conflict. SCSI controllers are scanned in the order specified in the builtin_scsi_hosts[] array in drivers/scsi/hosts.c, with the order currently being
BusLogic, Ultrastor 14/34F, Ultrastor 14F,, Adaptec 151x/152x, Adaptec 154x, Adaptec 174x, AIC7XXX, AM53C974, Future Domain 16x0, Always IN2000, Generic NCR5380, QLOGIC, PAS16, Seagate, Trantor T128/T130, NCR53c8xx, EATA-DMA, WD7000, debugging driver.
In most cases (ie, you aren't trying to use both BusLogic and Adaptec drivers), this can be changed to suit your needs (ie, keeping the same devices when new SCSI devices are added to the system on a new controller) by moving the individual entries.
Make sure interrupts are enabled correctly, and there are no IRQ, DMA, or address conflicts with other boards.
If your SCSI adapter is one of the following :
Adaptec 152x, Adaptec 151x, Adaptec AIC-6260, Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950, Future Domain TMC-8xx, Trantor T128, Trantor T128F, Trantor T228F, Seagate ST01, Seagate ST02, or a Western Digital 7000
and it is not detected on bootup, ie you get a
scsi : 0 hosts
message or a
scsi%d : type
message is not printed for each supported SCSI adapter installed in the system, you may have a problem with the autoprobe routine not knowing about your board.
Autodetection will fail for drivers using the BIOS for autodetection if the BIOS is disabled. Double check that your BIOS is enabled, and not conflicting with any other peripherial BIOSes.
Autodetection will also fail if the board's "signature" and/or BIOS address don't match known ones.
If the BIOS is installed, please use DOS and DEBUG to find a signature that will detect your board -
Ie, if your board lives at 0xc8000, under DOS do
debug
d c800:0
q
and send a message to the SCSI channel of the mailing list with the ASCII message, with the length and offset from the base address (ie, 0xc8000). Note that the EXACT text is required, and you should provide both the hex and ASCII portions of the text.
If no BIOS is installed, and you are using an Adaptec 152x, Trantor T128, or Seagate driver, you can use command line or compile time overrides to force detection.
Please consult the appropriate subsection for your SCSI board as well as section General Flakiness.
(This include the Trantor T128 and Seagate boards, but not the Adaptec, Generic NCR5380, PAS16, and Ultrastor drivers)
This is often caused when the memory mapped I/O ports are incorrectly cached. You should have the board's address space marked as uncachable in the XCMOS settings.
If this is not possible, you will have to disable cache entirely.
If you have manually specified the address of the board, remember that Linux needs the actual address of the board, and not the 16 byte segment the documentation may refer to.
Ie, 0xc8000 would be correct, 0xc800 would not work and could cause memory corruption.
You'll need to edit the binary image of the kernel (before or after writing it out to disk), and modify a few two byte fields (little endian) to guarantee that it will work on your system.
This means the bytes are 3.5" : 0xA0 0x05 5.25" : 0xB0 0x04
dd or rawrite the file to a disk. Insert the disk in the first floppy drive, wait until it prompts you to insert the root disk, and insert the root floppy from your distribution.
You need to start with the version of the kernel used by the driver author. This revision may be alluded to in the documentation included with the driver.
Various recent kernel revisions can be found at
nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus
as linux-version.tar.gz
They are also mirrored at tsx-11.mit.edu and various other sites.
cd to /usr/src.
Remove your old Linux sources, if you want to keep a backup copy of them
mv linux linux-old
Untar the archive
gunzip < linux-0.99.12.tar.gz | tar xvfp -
Apply the patches. The patches will be relative to some directory in the filesystem. By examining the output file lines in the patch file (grep for ^---), you can tell where this is - ie patches with these lines
--- ./kernel/blk_drv/scsi/Makefile
--- ./config.in Wed Sep 1 16:19:33 1993
would have the files relative to /usr/src/linux.
Untar the driver sources at an appropriate place - you can type
tar tfv patches.tar
to get a listing, and move files as necessary (The SCSI driver files should live in /usr/src/linux/kernel/drivers/scsi)
Either cd to the directory they are relative to and type
patch -p0 < patch_file
or tell patch to strip off leading path components. Ie, if the files started with
--- linux-new/kernel/blk_drv/scsi/Makefile
and you wanted to apply them while in /usr/src/linux, you could cd to /usr/src/linux and type
patch -p1 < patches
to strip off the "linux-new" component.
After you have applied the patches, look for any patch rejects, which will be the name of the rejected file with a # suffix appended.
find /usr/src/linux/ -name "*#" -print
If any of these exist, look at them. In some cases, the differences will be in RCS identifiers and will be harmless, in other cases, you'll have to manually apply important parts. Documentation on diff files and patch is beyond the scope of this document.
See also Configuring and building the kernel.
In some cases, a driver author may not offer patches with the .c and .h files which comprise his driver, or the patches may be against an older revision of the kernel and not go in cleanly.
*
* SCSI low-level drivers
*
bool 'Always IN2000 SCSI support' CONFIG_SCSI_IN2000 y
ifdef CONFIG_SCSI_IN2000
SCSI_OBS := $(SCSI_OBJS) in2000.o
SCSI_SRCS := $(SCSI_SRCS) in2000.c
endif
scsi.a: $(SCSI_OBJS)
#ifdef CONFIG_SCSI_GENERIC_NCR5380
#include "g_NCR5380.h"
#endif
#ifdef CONFIG_SCSI_IN2000
#include "in2000.h"
#endif
#define IN2000 {"Always IN2000", in2000_detect, \
in2000_info, in2000_command, \
in2000_queuecommand, \
in2000_abort, \
in2000_reset, \
NULL, \
in2000_biosparam, \
1, 7, IN2000_SG, 1, 0, 0}
#ifdef CONFIG_SCSI_GENERIC_NCR5380
GENERIC_NCR5380,
#endif
#ifdef CONFIG_SCSI_IN2000
IN2000,
#endif
A number of Compaq systems map the 32-bit BIOS extensions used to probe for PCI devices into memory which is inaccessible to the Linux kernel due to the memory layout. If Linux is unable to detect a supported PCI SCSI board, and the kernel tells you something like
pcibios_init: entry in high memory, unable to access
Grab
ftp://ftp.compaq.com/pub/softpaq/Software-Solutions/sp0921.zip
which is a self-extracting archive of a program which will relocate the BIOS32 code.
Some PCI systems have broken BIOSes which disable interrupts and fail to reenable them before returning control to the caller. The following patch fixes this
--- bios32.c.orig Mon Nov 13 22:35:31 1995
+++ bios32.c Thu Jan 18 00:15:09 1996
@@ -56,6 +56,7 @@
#include <linux/pci.h>
#include <asm/segment.h>
+#include <asm/system.h>
#define PCIBIOS_PCI_FUNCTION_ID 0xb1XX
#define PCIBIOS_PCI_BIOS_PRESENT 0xb101
@@ -125,7 +126,9 @@
unsigned long address; /* %ebx */
unsigned long length; /* %ecx */
unsigned long entry; /* %edx */
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%edi)"
: "=a" (return_code),
"=b" (address),
@@ -134,6 +137,7 @@
: "0" (service),
"1" (0),
"D" (&bios32_indirect));
+ restore_flags(flags);
switch (return_code) {
case 0:
@@ -161,11 +165,13 @@
unsigned char present_status;
unsigned char major_revision;
unsigned char minor_revision;
+ unsigned long flags;
int pack;
if ((pcibios_entry = bios32_service(PCI_SERVICE))) {
pci_indirect.address = pcibios_entry;
+ save_flags(flags);
__asm__("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -176,6 +182,7 @@
: "1" (PCIBIOS_PCI_BIOS_PRESENT),
"D" (&pci_indirect)
: "bx", "cx");
+ restore_flags(flags);
present_status = (pack >> 16) & 0xff;
major_revision = (pack >> 8) & 0xff;
@@ -210,7 +217,9 @@
{
unsigned long bx;
unsigned long ret;
+ unsigned long flags;
+ save_flags(flags);
__asm__ ("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -221,6 +230,7 @@
"c" (class_code),
"S" ((int) index),
"D" (&pci_indirect));
+ restore_flags(flags);
*bus = (bx >> 8) & 0xff;
*device_fn = bx & 0xff;
return (int) (ret & 0xff00) >> 8;
@@ -232,7 +242,9 @@
{
unsigned short bx;
unsigned short ret;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -244,6 +256,7 @@
"d" (vendor),
"S" ((int) index),
"D" (&pci_indirect));
+ restore_flags(flags);
*bus = (bx >> 8) & 0xff;
*device_fn = bx & 0xff;
return (int) (ret & 0xff00) >> 8;
@@ -254,7 +267,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags (flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -273,7 +288,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -292,7 +309,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -303,6 +322,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -311,7 +331,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -322,6 +344,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -330,7 +353,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -341,6 +366,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -349,7 +375,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -360,6 +388,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
Supported Configurations :
BIOS addresses : 0xd8000, 0xdc000, 0xd0000, 0xd4000, 0xc8000, 0xcc000, 0xe0000,
0xe4000.
Ports : 0x140, 0x340
IRQs : 9, 10, 11, 12
DMA : not used
IO : port mapped
Autoprobe :
Works with many boards with an installed BIOS. All
other boards, including the Adaptec 1510, and Sound Blaster16 SCSI
must use a kernel command line or compile time override.
Autoprobe Override :
Compile time :
Define PORTBASE, IRQ, SCSI_ID, RECONNECT, PARITY as appropriate, see Defines
kernel command line :
aha152x=<PORTBASE>[,<IRQ>[,<SCSI-ID>[,<RECONNECT>[,<PARITY>]]]]
SCSI-ID is the SCSI ID of the HOST adapter, not of any devices you have installed on it. Usually, this should be 7.
To force detection at 0x340, IRQ 11, at SCSI-ID 7, allowing disconnect/reconnect, you would use the following command line option :
aha152x=0x340,11,7,1
Antiquity Problems, fix by upgrading :
Defines :
AUTOCONF : use configuration the controller reports (only 152x)
IRQ : override interrupt channel (9,10,11 or 12) (default 11)
SCSI_ID : override SCSI ID of AIC-6260 (0-7) (default 7)
RECONNECT : override target disconnect/reselect (set to non-zero to
allow, zero to disable)
DONT_SNARF : Don't register ports (pl12 and below)
SKIP_BIOSTEST : Don't test for BIOS signature (AHA-1510 or disabled BIOS)
PORTBASE : Force port base. Don't try to probe
Supported Configurations :
Ports : 0x330 and 0x334
IRQs : 9, 10, 11, 12, 14, 15
DMA channels : 5, 6, 7
IO : port mapped, bus master
Autoprobe :
will detect boards at 0x330 and 0x334 only.
Autoprobe override :
aha1542=<PORTBASE>[,<BUSON>,<BUSOFF>[,<DMASPEED>]]
Notes:
Antiquity Problems, fix by upgrading :
Common problems :
Newer boards aren't much better, and also suffer from extreme cabling and termination sensitivity.
See also Common Problems #2 and #3 and Common Problems, General Flakiness.
buslogic=0x330
Supported Configurations :
Slots : 1-8
Ports : EISA board, not applicable
IRQs : 9, 10, 11, 12, 14, 15
DMA Channels : EISA board, not applicable
IO : port mapped, bus master
Autoprobe :
works with all supported configurations
Autoprobe override :
none
Note:
Common Problems :
your board was disabled because it was not running in enhanced mode. Boards running in standard 1542 mode are not supported.
A newer version which also supports the Adaptec 294x boards is available at
ftp://ftp.ims.com/pub/Linux/aic7xxx
Supported Configurations :
274x 284x 294x
EISA Slots : 1-12 N/A N/A
Ports : N/A ALL ALL
IRQs : ALL ALL ALL
DMA Channels : N/A ALL N/A
IO : port mapped, bus master
Autoprobe Override :
kernel command line :
aha274x=extended
(to force extended mapping)
Notes:
Supported Configurations :
Ports : 0x100, 0x110, 0x200, 0x220
IRQs : 10, 11, 14, 15
DMA : not used
IO : port mapped
Autoprobe :
BIOS not required
Autoprobe override :
none
Common Problems :
(this section Copyright 1995 by Leonard N. Zubkoff <lnz@dandelion.com>) (see README.BusLogic for more complete BusLogic driver documentation)
BusLogic MultiMaster SCSI Driver for Linux
Version 1.2.2 for Linux 1.2.13
Version 1.3.2 for Linux 1.3.88
ftp://ftp.dandelion.com/BusLogic-1.2.2.tar.gz
ftp://ftp.dandelion.com/BusLogic-1.3.2.tar.gz
16 April 1996
Leonard N. Zubkoff
Dandelion Digital
lnz@dandelion.com
BusLogic, Inc. designs and manufactures a variety of high performance SCSI host
adapters which share a common programming interface across a diverse collection
of bus architectures by virtue of their MultiMaster ASIC technology. This
driver supports all present BusLogic MultiMaster Host Adapters, and should
support any future MultiMaster designs with little or no modification. Host
adapters based on the new FlashPoint architecture are not supported by this
driver; consult the README.FlashPoint file for information about a program to
upgrade Linux users from the unsupported FlashPoint LT to the supported BT-948.
My primary goals in writing this completely new BusLogic driver for Linux are
to achieve the full performance that BusLogic SCSI Host Adapters and modern
SCSI peripherals are capable of, and to provide a highly robust driver that can
be depended upon for high performance mission critical applications. All of
the major performance and error recovery features can be configured from the
Linux kernel command line, allowing individual installations to tune driver
performance and error recovery to their particular needs.
BusLogic has been an excellent company to work with and I highly recommend
their products to the Linux community. In November 1995, I was offered the
opportunity to become a beta test site for their latest MultiMaster product,
the BT-948 PCI Ultra SCSI Host Adapter, and then again for the BT-958 PCI Wide
Ultra SCSI Host Adapter in January 1996. This was mutually beneficial since
BusLogic received a degree and kind of testing that their own testing group
cannot readily achieve, and the Linux community has available high performance
host adapters that have been well tested with Linux even before being brought
to market. This relationship has also given me the opportunity to interact
directly with their technical staff, to understand more about the internal
workings of their products, and in turn to educate them about the needs and
potential of the Linux community. Their interest and support is greatly
appreciated.
Unlike some other vendors, if you contact BusLogic Technical Support with a
problem and are running Linux, they will not tell you that your use of their
products is unsupported. Their latest product marketing literature even states
"BusLogic SCSI host adapters are compatible with all major operating systems
including: ... Linux ...".
BusLogic, Inc. is located at 4151 Burton Drive, Santa Clara, California, 95054,
USA and can be reached by Voice at 408/492-9090 or by FAX at 408/492-1542.
BusLogic maintains a World Wide Web site at http://www.buslogic.com, an
anonymous FTP site at ftp.buslogic.com, and a BBS at 408/492-1984. BusLogic
Technical Support can be reached by electronic mail at techsup@buslogic.com, by
Voice at 408/654-0760, or by FAX at 408/492-1542. Contact information for
offices in Europe and Japan is available on the Web site.
SUPPORTED HOST ADAPTERS
The following list comprises the supported BusLogic SCSI Host Adapters as of
the date of this document. It is recommended that anyone purchasing a BusLogic
Host Adapter not in the following table contact the author beforehand to verify
that it is or will be supported.
"W" Series Host Adapters:
BT-948 PCI Ultra Fast Single-ended SCSI-2
BT-958 PCI Ultra Wide Single-ended SCSI-2
BT-958D PCI Ultra Wide Differential SCSI-2
"C" Series Host Adapters:
BT-946C PCI Fast Single-ended SCSI-2
BT-956C PCI Fast Wide Single-ended SCSI-2
BT-956CD PCI Fast Wide Differential SCSI-2
BT-445C VLB Fast Single-ended SCSI-2
BT-747C EISA Fast Single-ended SCSI-2
BT-757C EISA Fast Wide Single-ended SCSI-2
BT-757CD EISA Fast Wide Differential SCSI-2
BT-545C ISA Fast Single-ended SCSI-2
BT-540CF ISA Fast Single-ended SCSI-2
"S" Series Host Adapters:
BT-445S VLB Fast Single-ended SCSI-2
BT-747S EISA Fast Single-ended SCSI-2
BT-747D EISA Fast Differential SCSI-2
BT-757S EISA Fast Wide Single-ended SCSI-2
BT-757D EISA Fast Wide Differential SCSI-2
BT-545S ISA Fast Single-ended SCSI-2
BT-542D ISA Fast Differential SCSI-2
BT-742A EISA Single-ended SCSI-2 (742A revision H)
BT-542B ISA Single-ended SCSI-2 (542B revision H)
"A" Series Host Adapters:
BT-742A EISA Single-ended SCSI-2 (742A revisions A - G)
BT-542B ISA Single-ended SCSI-2 (542B revisions A - G)
AMI FastDisk Host Adapters that are true BusLogic clones are supported by this
driver.
BT-948/958/958D INSTALLATION NOTES
The BT-948/958/958D PCI Ultra SCSI Host Adapters have some features which may
require attention in some circumstances when installing Linux.
o PCI I/O Port Assignments
When configured to factory default settings, the BT-948/958/958D will only
recognize the PCI I/O port assignments made by the motherboard's PCI BIOS.
The BT-948/958/958D will not respond to any of the ISA compatible I/O ports
that previous BusLogic SCSI Host Adapters respond to. This driver supports
the PCI I/O port assignments, so this is the preferred configuration.
However, if the obsolete BusLogic driver must be used for any reason, such as
a Linux distribution that does not yet use this driver in its boot kernel,
BusLogic has provided an AutoSCSI configuration option to enable a legacy ISA
compatible I/O port.
To enable this backward compatibility option, invoke the AutoSCSI utility via
Ctrl-B at system startup and select "Adapter Configuration", "View/Modify
Configuration", and then change the "ISA Compatible Port" setting from
"Disable" to "Primary" or "Alternate". Once this driver has been installed,
the "ISA Compatible Port" option should be set back to "Disable" to avoid
possible future I/O port conflicts. The older BT-946C/956C/956CD also have
this configuration option, but the factory default setting is "Primary".
o PCI Slot Scanning Order
In systems with multiple BusLogic PCI Host Adapters, the order in which the
PCI slots are scanned may appear reversed with the BT-948/958/958D as
compared to the BT-946C/956C/956CD. For booting from a SCSI disk to work
correctly, it is necessary that the host adapter's BIOS and the kernel agree
on which disk is the boot device, which requires that they recognize the PCI
host adapters in the same order. The motherboard's PCI BIOS provides a
standard way of enumerating the PCI host adapters, which is used by the Linux
kernel. Some PCI BIOS implementations enumerate the PCI slots in order of
increasing bus number and device number, while others do so in the opposite
direction.
Unfortunately, Microsoft decided that Windows 95 would always enumerate the
PCI slots in order of increasing bus number and device number regardless of
the PCI BIOS enumeration, and requires that their scheme be supported by the
host adapter's BIOS to receive Windows 95 certification. Therefore, the
factory default settings of the BT-948/958/958D enumerate the host adapters
by increasing bus number and device number. To disable this feature, invoke
the AutoSCSI utility via Ctrl-B at system startup and select "Adapter
Configuration", "View/Modify Configuration", press Ctrl-F10, and then change
the "Use Bus And Device # For PCI Scanning Seq." option to OFF.
This driver will interrogate the setting of the PCI Scanning Sequence option
so as to recognize the host adapters in the same order as they are enumerated
by the host adapter's BIOS.
BUSLOGIC ANNOUNCEMENTS MAILING LIST
The BusLogic Announcements Mailing List provides a forum for informing Linux
users of new driver releases and other announcements regarding Linux support
for BusLogic SCSI Host Adapters. To join the mailing list, send a message to
"BusLogic-announce-request@dandelion.com" with the line "subscribe" in the
message body.
(this section Copyright 1995 by Leonard N. Zubkoff <lnz@dandelion.com>)
There are no Linux drivers for the FlashPoint LT/DL/LW (BT-930/932/950)
available and it is not clear when or if there will be any. The FlashPoint
boards have a different architecture from the MultiMaster boards and have no
onboard CPU, only a SCSI sequencer engine. They are positioned as a desktop
workstation product, and are not particularly well suited for a high
performance multitasking operating system like Linux.
The MultiMaster BT-948/958 have an onboard CPU and the mailbox programming
interface allows for parallelism and pipelining between the host operating
system and the host adapter, whereas the FlashPoint boards require frequent
host CPU intervention. As interrupt latencies rise in a loaded multitasking
system, the BT-948/958 should maintain excellent performance whereas the
FlashPoint's performance will likely drop quite rapidly. Furthermore, the
firmware on the BT-948/958 contains the low level knowledge for proper
interaction with the SCSI bus, whereas with a sequencer engine the Linux driver
must contain some or all of this information, and it often takes quite a long
time to get all the kinks worked out. Given the relatively small difference in
the street price of these products, the BT-948 or BT-958 is clearly the better
choice for Linux.
<begin quotation>
ANNOUNCEMENT
BusLogic FlashPoint/BT-948 Upgrade Program
1 February 1996
Ever since its introduction last October, the BusLogic FlashPoint LT has
been problematic for members of the Linux community, in that no Linux
drivers have been available for this new Ultra SCSI product. Despite it's
officially being positioned as a desktop workstation product, and not being
particularly well suited for a high performance multitasking operating
system like Linux, the FlashPoint LT has been touted by computer system
vendors as the latest thing, and has been sold even on many of their high
end systems, to the exclusion of the older MultiMaster products. This has
caused grief for many people who inadvertently purchased a system expecting
that all BusLogic SCSI Host Adapters were supported by Linux, only to
discover that the FlashPoint was not supported and would not be for quite
some time, if ever.
After this problem was identified, BusLogic contacted its major OEM
customers to make sure the BT-946C/956C MultiMaster cards would still be
made available, and that Linux users who mistakenly ordered systems with
the FlashPoint would be able to upgrade to the BT-946C. While this helped
many purchasers of new systems, it was only a partial solution to the
overall problem of FlashPoint support for Linux users. It did nothing to
assist the people who initially purchased a FlashPoint for a supported
operating system and then later decided to run Linux, or those who had
ended up with a FlashPoint LT, believing it was supported, and were unable
to return it.
In the middle of December, I asked to meet with BusLogic's senior
management to discuss the issues related to Linux and free software support
for the FlashPoint. Rumors of varying accuracy had been circulating
publicly about BusLogic's attitude toward the Linux community, and I felt
it was best that these issues be addressed directly. I sent an email
message after 11pm one evening, and the meeting took place the next
afternoon. Unfortunately, corporate wheels sometimes grind slowly,
especially when a company is being acquired, and so it's taken until now
before the details were completely determined and a public statement could
be made.
BusLogic is not prepared at this time to release the information necessary
for third parties to write drivers for the FlashPoint. The only existing
FlashPoint drivers have been written directly by BusLogic Engineering, and
there is no FlashPoint documentation sufficiently detailed to allow outside
developers to write a driver without substantial assistance. While there
are people at BusLogic who would rather not release the details of the
FlashPoint architecture at all, that debate has not yet been settled either
way. In any event, even if documentation were available today it would
take quite a while for a usable driver to be written, especially since I'm
not convinced that the effort required would be worthwhile.
However, BusLogic does remain committed to providing a high performance
SCSI solution for the Linux community, and does not want to see anyone left
unable to run Linux because they have a Flashpoint LT. Therefore, BusLogic
has put in place a direct upgrade program to allow any Linux user worldwide
to trade in their FlashPoint LT for the new BT-948 MultiMaster PCI Ultra
SCSI Host Adapter. The BT-948 is the Ultra SCSI successor to the BT-946C
and has all the best features of both the BT-946C and FlashPoint LT,
including smart termination and a flash PROM for easy firmware updates, and
is of course compatible with the present Linux driver. The price for this
upgrade has been set at US $45, and the upgrade program will be
administered through BusLogic Technical Support, which can be reached by
electronic mail at techsup@BusLogic.com, by Voice at +1 408 654-0760, or by
FAX at +1 408 492-1542.
I was a beta test site for the BT-948 and versions 1.2.1 and 1.3.1 of my
BusLogic driver already include latent support for the BT-948. Additional
cosmetic support for the Ultra SCSI MultiMaster cards will be added in a
subsequent release. As a result of this cooperative testing process,
several firmware bugs were found and corrected (make sure you have firmware
version 5.05R or later). My heavily loaded Linux test system provided an
ideal environment for testing error recovery processes that are much more
rarely exercised in production systems, but are crucial to overall system
stability. It was especially convenient being able to work directly with
their firmware engineer in demonstrating the problems under control of the
firmware debugging environment; things sure have come a long way since the
last time I worked on firmware for an embedded system. I am presently
working on some performance testing and expect to have some data to report
in the not too distant future.
BusLogic asked me to send this announcement since a large percentage of the
questions regarding support for the FlashPoint have either been sent to me
directly via email, or have appeared in the Linux newsgroups in which I
participate. To summarize, BusLogic is offering Linux users an upgrade
from the unsupported FlashPoint LT (BT-930) to the supported BT-948 for US
$45. Contact BusLogic Technical Support at techsup@BusLogic.com or +1 408
654-0760 to take advantage of their offer.
Leonard N. Zubkoff
lnz@dandelion.com
<end quotation>
Supported boards: all, that support the EATA-DMA protocol.
Among them are:
DPT Smartcache (Plus) family: PM2011 ISA Fast Single-ended SCSI-2 PM2012B EISA Fast Single-ended SCSI-2 DPT Smartcache III family: PM2021 ISA Fast Single-ended SCSI-2 PM2021W ISA Wide Single-ended SCSI-2 PM2022 EISA Fast Single-ended SCSI-2 PM2022W EISA Wide Single-ended SCSI-2 PM2024 PCI Fast Single-ended SCSI-2 PM2024W PCI Wide Single-ended SCSI-2 PM2122 EISA Fast Single-ended SCSI-2 PM2122W EISA Wide Single-ended SCSI-2 PM2124 PCI Fast Single-ended SCSI-2 PM2124W PCI Wide Single-ended SCSI-2 PM2322 EISA Fast Single-ended SCSI-2 PM2322W EISA Wide Single-ended SCSI-2 DPT Smartcache VI family: PM2041W ISA Wide Single-ended SCSI-2 PM2041UW ISA Ultra Wide Single-ended SCSI-2 PM2042W EISA Wide Single-ended SCSI-2 PM2042UW EISA Ultra Wide Single-ended SCSI-2 PM2044W PCI Wide Single-ended SCSI-2 PM2044UW PCI Ultra Wide Single-ended SCSI-2 PM2142W EISA Wide Single-ended SCSI-2 PM2142UW EISA Ultra Wide Single-ended SCSI-2 PM2144W PCI Wide Single-ended SCSI-2 PM2144UW PCI Ultra Wide Single-ended SCSI-2 PM2322W EISA Wide Single-ended SCSI-2 PM2322UW EISA Ultra Wide Single-ended SCSI-2 DPT SmartRAID family: PM3021 ISA Fast Single-ended SCSI-2 PM3021W ISA Wide Single-ended SCSI-2 PM3122 EISA Fast Single-ended SCSI-2 PM3122W EISA Wide Single-ended SCSI-2 PM3222 EISA Fast Single-ended SCSI-2 PM3222W EISA Wide Single-ended SCSI-2 PM3224 PCI Fast Single-ended SCSI-2 PM3224W PCI Wide Single-ended SCSI-2 PM3334W PCI Wide Single-ended SCSI-2 PM3334UW PCI Ultra Wide Single-ended SCSI-2
also the differential versions of the above controllers.
and some controllers from:
NEC, AT&T, SNI, AST, Olivetti, Alphatronix.
Supported Configurations :
Slots : ALL
Ports : ALL
IRQs : ALL level & edge triggered
DMA Channels : ISA ALL, EISA/PCI not applicable
IO : port mapped, bus master
SCSI Channels : ALL
Autoprobe :
works with all supported configurations
The latest version of the EATA-DMA driver is available on:
ftp.i-Connect.Net:/pub/Local/EATA/
Mailinglist: The EATA Mailing List provides a forum to Linux users of the EATA-DMA and EATA-PIO driver for discussions and announcements of new releases and other announcements. To join the mailing list, send a message to "linux-eata-request@i-connect.net" with the line "subscribe" in the message body.
/proc/scsi support: To get advanced command statistics, do the following: echo "eata_dma latency" >/proc/scsi/eata_dma/<driver_no> and to switch it off again: echo "eata_dma nolatency" >/proc/scsi/eata_dma/<driver_no>
Common Problems :
Solution: Use one of the ascsi* bootdisks.
hd.c: ST-506 interface disk with more than 16 heads detected,
probably due to non-standard sector translation. Giving up.
(disk %d: cyl=%d, sect=63, head=64)
hdc: probing with STATUS instead of ALTSTATUS
hdc: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdc: cannot handle disk with 0 physical heads
hdd: probing with STATUS instead of ALTSTATUS
hdd: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdd: cannot handle disk with 0 physical heads
Notes:
Supported Configurations :
BIOSs : 2.0, 3.0, 3.2, 3.4, 3.5
BIOS Addresses : 0xc8000, 0xca000, 0xce000, 0xde000
Ports : 0x140, 0x150, 0x160, 0x170
IRQs : 3, 5, 10, 11, 12, 14, 15
DMA : not used
IO : port mapped
Autoprobe :
works with all supported configurations, requires installed BIOS
Autoprobe Override :
none
Antiquity Problems, fix by upgrading :
Notes :
Supported and Unsupported Configurations :
Ports : all
IRQs : all
DMA channels : DMA is not used
IO : port mapped
Autoprobe :
none
Autoprobe Override :
Compile time : Define GENERIC_NCR5380_OVERRIDE to be an array of tuples
with port, irq, dma, board type - ie
#define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}
for a NCR5380 board at port 330, IRQ 5.
#define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}
for a T130B at port 0x350.
Older versions of the code eliminate the BOARD_* entry.
The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.
kernel command line :
ncr5380=port,irq
ncr5380=port,irq,dma
ncr53c400=port,irq
255 may be used for no irq, 254 for irq autoprobe.
Common Problems :
The NCR5380 compatible registers are offset eight from the base address. So, if your address is 0x350, use
ncr5380=0x358,254
on the kernel command line.
Antiquity problems, fix by upgrading :
Pre-public release 6 versions of the Generic NCR5380 driver didn't support interrupts on these boards. Upgrade.
Notes :
Supported and Unsupported Configurations :
Base addresses : ALL
IRQs : ALL
DMA channels : PCI, not applicable
IO : port mapped, busmastering
Autoprobe :
requires PCI BIOS, uses PCI BIOS routines to
search for devices and read configuration space
The driver uses the pre-programmed values in some registers for initialization, so a BIOS must be installed.
Antiquity Problems, fix by upgrading :
The latest release of the driver is available at
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/ncr53c810
Currently, this is a 1.2.10 and newer patch, although the next release will be 1.3.x exclusively. These patches are NOT entirely clean due to some ELF and other patches which were in the baseline revision of my source tree, and if you can't manually correct the (four) problems you should get, you shouldn't use them. Note that only the newest patch is needed; these are not incremental.
If you wish to run the newer NCR driver with a 1.3.x kernel before then, Harald Evensen <Harald.Evensen@pvv.unit.no> has adapted the patches for 1.3.x
ftp://ftp.pvv.unit.no/pub/Linux/ALPHA/ncr
These patches should be clean.
Please see all of the READMEs in these directories. You should also join the NCR mailing list if you are interested in running the ALPHA code, since interim bug fixes and announcements of the next release are posted to this list.
To subscribe, send mail to majordomo@colorado.edu with
subscribe ncr53c810
in the text. You can unsubscribe by sending mail to the same address and including
unsubscribe ncr53c810
in the text.
Common Problems :
This is often due to a mismatch between the IRQ hardware jumper for a slot or mainboard device and the value set in the CMOS setup. DOUBLE CHECK
It may also be due to PCI INTB, INTC, or INTD being selected on a PCI board in a system which only supports PCI INTA. If you are using an NCR board which has jumpers to select between PCI interrupt lines, make sure you are using INTA.
Finally, PCI should be using level-sensitive rather than edge triggered interrupts. Check that your board is jumpered for level-sensitive, and if that fails try edge-triggered because your system may be broken.
This problem is especially common with Viglen some Viglen motherboards, where the mainboard IRQ jumper settings are NOT as documented in the manual. I've been told that what claims to be IRQ5 is really IRQ9, your mileage will vary.
"scsi%d: IRQ0 not free, detaching"
"scsi%d: IRQ255 not free, detaching"
irq = my_irq;
return normal_init (tpnt, board, chip, (int) base,
(int) io_port, (int) irq, DMA_NONE, 1, bus, device_fn,
options);
Notes:
Supported and Unsupported Configurations :
Base addresses : 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000
IRQs : 3, 5
DMA channels : DMA is not used
IO : memory mapped
Autoprobe :
probes for address only, IRQ is assumed to be 5, requires installed BIOS.
Autoprobe Override :
Compile time :
Define OVERRIDE to be the base address, CONTROLLER to
FD or SEAGATE as appropriate, and IRQ to the IRQ.
kernel command line :
st0x=address,irq or tmc8xx=address,irq (only works for .99.13b and newer)
Antiquity Problems, fix by upgrading :
This is what happens when you write data out to the bus
The problem was encountered in slow devices that do the command processing as they read the command, where the REQ/ACK handshake takes over 12us - REQ didn't go false when the driver expected it to, so the driver ended up sending multiple bytes of data for each REQ pulse.
Common Problems :
The board ships with the defaults set up for MSDOS, ie interrupts are disabled. To jumper the board for interrupts, on the Seagate use jumper W3 (ST01) or JP3 (ST02) and short pins F-G to select IRQ 5.
You must set heads sectors and cylinders. You can do this from the extra functions menu.See Disks Partitioning
The code in seagate.c looks like this now :
cli();
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
(reselect ? CMD_ATTN : 0);
sti();
Changing this to
cli();
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
(reselect ? CMD_ATTN : 0);
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
sti();
may fix your problem.
Defines :
FAST or FAST32 will use blind transfers where possible
ARBITRATE will cause the host adapter to arbitrate for the
bus for better SCSI-II compatibility, rather than just
waiting for BUS FREE and then doing its thing. Should
let us do one command per Lun when I integrate my
reorganization changes into the distribution sources.
SLOW_HANDSHAKE will allow compatibility with broken devices that don't
handshake fast enough (ie, some CD ROM's) for the Seagate
code.
SLOW_RATE=x, x some number will let you specify a default
transfer rate if handshaking isn't working correctly.
Supported and Unsupported Configurations :
Ports : 0x388, 0x384, 0x38x, 0x288
IRQs : 10, 12, 14, 15
IMPORTANT : IRQ MUST be different from the IRQ used for the sound
portion of the board.
DMA : is not used for the SCSI portion of the board
IO : port mapped
Autoprobe :
does not require BIOS
Autoprobe Override :
Compile time : Define PAS16_OVERRIDE to be an array of port, irq
tuples. Ie
#define PAS16_OVERRIDE {{0x388, 10}}
for a board at port 0x388, IRQ 10.
kernel command line :
pas16=port,irq
Defines :
AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
for commands that return with a CHECK CONDITION status.
PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance
increase compared to polled I/O.
PARITY - enable parity checking. Not supported
SCSI2 - enable support for SCSI-II tagged queuing. Untested
UNSAFE - leave interrupts enabled during pseudo-DMA transfers. You
only really want to use this if you're having a problem with
dropped characters during high speed communications, and even
then, you're going to be better off twiddling with transfersize.
USLEEP - enable support for devices that don't disconnect. Untested.
Common problems :
You should install the NCR5380 patches that I posted to the net some time ago, which should be integrated into some future alpha release. These patches fix a race condition in earlier NCR5380 driver cores, as well as fixing support for multiple devices on NCR5380 based boards.
If that fails, you should disable the PSEUDO_DMA option by changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef PSEUDO_DMA.
Note that the later should be considered a last resort, because there will be a severe performance degradation.
Supported and Unsupported Configurations :
Base addresses : 0xcc000, 00xc8000, 0xdc000, 0xd8000
IRQs : none, 3, 5, 7 (all boards)
10, 12, 14, 15 (T128F only)
DMA : not used.
IO : memory mapped
Autoprobe :
works for all supported configurations, requires installed BIOS.
Autoprobe Override :
Compile time : Define T128_OVERRIDE to be an array of address, irq
tuples. Ie
#define T128_OVERRIDE {{0xcc000, 5}}
for a board at address 0xcc000, IRQ 5.
The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.
kernel command line :
t128=address,irq
-1 may be used for no irq, -2 for irq autoprobe.
Defines :
AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
for commands that return with a CHECK CONDITION status.
PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance
increase compared to polled I/O.
PARITY - enable parity checking. Not supported
SCSI2 - enable support for SCSI-II tagged queuing. Untested
UNSAFE - leave interrupts enabled during pseudo-DMA transfers. You
only really want to use this if you're having a problem with
dropped characters during high speed communications, and even
then, you're going to be better off twiddling with transfersize.
USLEEP - enable support for devices that don't disconnect. Untested.
Common Problems :
If that fails, you should disable the PSEUDO_DMA option by changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef PSEUDO_DMA.
Note that the later should be considered a last resort, because there will be a severe performance degradation.
Supported Configurations :
Ports : 0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340
IRQs : 10, 11, 14, 15
DMA channels : 5, 6, 7
IO : port mapped, bus master
Autoprobe :
does not work for boards at port 0x310, BIOS not required.
Autoprobe override :
compile time only, define PORT_OVERRIDE
Common Problems :
hd=cylinders,heads,sectors
Supported Configurations :
BIOS Addresses : 0xce000
Ports : 0x350
IRQs : 15
DMA Channels : 6
IO : port mapped, bus master
Autoprobe :
requires installed BIOS
Common Problems :
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/AM53C974-0.3.tar.gz
Supported Configurations :
Ports : all
IRQs : all
DMA Channels : 6
IO : port mapped, bus master (unintelligent)
Hey Drew, where is this section (I (D.F.) saw it only in the toc ;-)?