patch-2.1.125 linux/drivers/scsi/README.aic7xxx
Next file: linux/drivers/scsi/aha1542.c
Previous file: linux/drivers/scsi/Makefile
Back to the patch index
Back to the overall index
- Lines: 309
- Date:
Thu Oct 8 08:07:33 1998
- Orig file:
v2.1.124/linux/drivers/scsi/README.aic7xxx
- Orig date:
Thu Aug 6 14:06:32 1998
diff -u --recursive --new-file v2.1.124/linux/drivers/scsi/README.aic7xxx linux/drivers/scsi/README.aic7xxx
@@ -21,15 +21,24 @@
AHA-2940W
AHA-2940U
AHA-2940UW
- AHA-2940AU
+ AHA-2940AU
+ AHA-2940U2W
+ AHA-2940U2
+ AHA-2940U2B
+ AHA-2940U2BOEM
AHA-2944D
AHA-2944WD
AHA-2944UD
AHA-2944UWD
+ AHA-2950U2
+ AHA-2950U2W
+ AHA-2950U2B
AHA-3940
AHA-3940U
AHA-3940W
AHA-3940UW
+ AHA-3940U2W
+ AHA-3950U2B
AHA-3985
AHA-3985U
AHA-3985W
@@ -42,13 +51,14 @@
AIC-786x
AIC-787x
AIC-788x
- AIC-7895
+ AIC-789x
Bus Types
----------------------------
W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support
SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s.
U - Ultra SCSI, transfer rates up to 40MB/s.
+ U2- Ultra 2 SCSI, transfer rates up to 80MB/s.
D - Differential SCSI.
T - Twin Channel SCSI. Up to 14 SCSI devices.
@@ -72,7 +82,7 @@
(Original Linux FTP/patch maintainer)
Jess Johnson jester@frenzy.com
(AIC7xxx FAQ author)
- Doug Ledford dledford@dialnet.net
+ Doug Ledford dledford@redhat.com
(Current Linux aic7xxx-5.x.x Driver/Patch/FTP/FAQ maintainer)
Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original
@@ -104,38 +114,41 @@
Some SCSI devices need the initial reset that this option disables
in order to work. If you have problems at bootup, please make sure
you aren't using this option.
- "aic7xxx=reverse_scan" - Have the driver register the SCSI cards in the
- reverse of the normal order. This may help those people who have more
- than one PCI Adaptec controller force the correct controller to be
- scsi0 under linux so that their boot hard drive is also sda under
- linux
+
+ "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at
+ bootup by scanning from the highest numbered PCI device to the
+ lowest numbered PCI device, others do just the opposite and scan
+ from lowest to highest numbered PCI device. There is no reliable
+ way to autodetect this ordering. So, we default to the most common
+ order, which is lowest to highest. Then, in case your motherboard
+ scans from highest to lowest, we have this option. If your BIOS
+ finds the drives on controller A before controller B but the linux
+ kernel finds your drives on controller B before A, then you should
+ use this option.
+
"aic7xxx=extended" - Force the driver to detect extended drive translation
on your controller. This helps those people who have cards without
a SEEPROM make sure that linux and all other operating systems think
the same way about your hard drives.
+
"aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel
to use the correct IRQ type for your card. This only applies to EISA
based controllers. On these controllers, 0 is for Edge triggered
interrupts, and 1 is for Level triggered interrupts. If you aren't
sure or don't know which IRQ trigger type your EISA card uses, then
let the kernel autodetect the trigger type.
+
"aic7xxx=verbose" - This option can be used in one of two ways. If you
- simply specify aic7xxx=verbose, then the kernel will automatically pick
- the default set of verbose messages for you to see. Alternatively, you
- can specify the command as "aic7xxx=verbose:0xXXXX" where the X entries
- are replaced with hexadecimal digits. This option is a bit field type
- option. For a full listing of the available options, search for the
- #define VERBOSE_xxxxxx lines in the aic7xxx.c file. If you want verbose
- messages, then it is recommended that you simply use the aic7xxx=verbose
- variant of this command.
- "aic7xxx=7895_irq_hack:x" - This option enables some work around code to
- fix a bug in the Tyan Thunder II motherboard BIOS. The BIOS
- incorrectly sets the IRQs on the two channels of the 7895 to two
- different values even though the motherboard hardware doesn't support
- this mode of operation. The valid values for x are: 0 to force
- both channels to use the IRQ assigned to Channel A, 1 to force both
- channels to use the IRQ assigned to Channel B, and -1 will disable
- this horrible abomination of a hack. The default is disabled (-1).
+ simply specify aic7xxx=verbose, then the kernel will automatically
+ pick the default set of verbose messages for you to see.
+ Alternatively, you can specify the command as
+ "aic7xxx=verbose:0xXXXX" where the X entries are replaced with
+ hexadecimal digits. This option is a bit field type option. For
+ a full listing of the available options, search for the
+ #define VERBOSE_xxxxxx lines in the aic7xxx.c file. If you want
+ verbose messages, then it is recommended that you simply use the
+ aic7xxx=verbose variant of this command.
+
"aic7xxx=pci_parity:x" - This option controls whether or not the driver
enables PCI parity error checking on the PCI bus. By default, this
checking is disabled. To enable the checks, simply specify pci_parity
@@ -147,6 +160,145 @@
NOTE: In order to get Even PCI parity checking, you must use the
version of the option that does not include the : and a number at
the end (unless you want to enter exactly 2^32 - 1 as the number).
+
+ "aic7xxx=no_probe" - This option will disable the probing for any VLB
+ based 2842 controllers and any EISA based controllers. This is
+ needed on certain newer motherboards where the normal EISA I/O ranges
+ have been claimed by other PCI devices. Probing on those machines
+ will often result in the machine crashing or spontaneously rebooting
+ during startup. Examples of machines that need this are the
+ Dell PowerEdge 6300 machines.
+
+ "aic7xxx=panic_on_abort" - This option is for debugging and will cause
+ the driver to panic the linux kernel and freeze the system the first
+ time the drivers abort or reset routines are called. This is most
+ helpful when some problem causes infinite reset loops that scroll too
+ fast to see. By using this option, you can write down what the errors
+ actually are and send that information to me so it can be fixed.
+
+ "aic7xxx=dump_card" - This option will print out the *entire* set of
+ configuration registers on the card during the init sequence. This
+ is a debugging aid used to see exactly what state the card is in
+ when we finally finish our initialization routines. If you don't
+ have documentation on the chipsets, this will do you absolutely
+ no good unless you are simply trying to write all the information
+ down in order to send it to me.
+
+ "aic7xxx=dump_sequencer" - This is the same as the above options except
+ that instead of dumping the register contents on the card, this
+ option dumps the contents of the sequencer program RAM. This gives
+ the ability to verify that the instructions downloaded to the
+ card's sequencer are indeed what they are suppossed to be. Again,
+ unless you have documentation to tell you how to interpret these
+ numbers, then it is totally useless.
+
+ "aic7xxx=override_term:0xffffffff" - This option is used to force the
+ termination on your SCSI controllers to a particular setting. This
+ is a bit mask variable that applies for up to 8 aic7xxx SCSI channels.
+ Each channel gets 4 bits, divided as follows:
+ bit 3 2 1 0
+ | | | Enable/Disable Single Ended Low Byte Termination
+ | | En/Disable Single Ended High Byte Termination
+ | En/Disable Low Byte LVD Termination
+ En/Disable High Byte LVD Termination
+
+ The upper 2 bits that deal with LVD termination only apply to Ultra2
+ controllers. Futhermore, due to the current Ultra2 controller
+ designs, these bits are tied together such that setting either bit
+ enables both low and high byte LVD termination. It is not possible
+ to only set high or low byte LVD termination in this manner. This is
+ an artifact of the BIOS definition on Ultra2 controllers. For other
+ controllers, the only important bits are the two lowest bits. Setting
+ the higher bits on non-Ultra2 controllers has no effect. A few
+ examples of how to use this option:
+
+ Enable low and high byte termination on a non-ultra2 controller that
+ is the first aic7xxx controller (the correct bits are 0011),
+ aic7xxx=override_term:0x3
+
+ Enable all termination on the third aic7xxx controller, high byte
+ termination on the second aic7xxx controller, and low and high byte
+ SE termination on the first aic7xxx controller
+ (bits are 1111 0010 0011),
+ aic7xxx=override_term:0xf23
+
+ No attempt has been made to make this option non-cryptic. It really
+ shouldn't be used except in dire circumstances, and if that happens,
+ I'm probably going to be telling you what to set this to anyway :)
+
+ "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV
+ bit in the DEVCONFIG PCI register. Currently, this is one of the
+ very few registers that we have absolutely *no* way of detecting
+ what the variable should be. It depends entirely on how the chipset
+ and external terminators were coupled by the card/motherboard maker.
+ Further, a chip reset (at power up) always sets this bit to 0. If
+ there is no BIOS to run on the chipset/card (such as with a 2910C
+ or a motherboard controller with the BIOS totally disabled) then
+ the variable may not get set properly. Of course, if the proper
+ setting was 0, then that's what it would be after the reset, but if
+ the proper setting is actually 1.....you get the picture. Now, since
+ we can't detect this at all, I've added this option to force the
+ setting. If you have a BIOS on your controller then you should never
+ need to use this option. However, if you are having lots of SCSI
+ reset problems and can't seem to get them knocked out, this may help.
+
+ Here's a test to know for certain if you need this option. Make
+ a boot floppy that you can use to boot your computer up and that
+ will detect the aic7xxx controller. Next, power down your computer.
+ While it's down, unplug all SCSI cables from your Adaptec SCSI
+ controller. Boot the system back up to the Adaptec EZ-SCSI BIOS
+ and then make sure that termination is enabled on your adapter (if
+ you have an Adaptec BIOS of course). Next, boot up the floppy you
+ made and wait for it to detect the aic7xxx controller. If the kernel
+ finds the controller fine, says scsi : x hosts and then tries to
+ detect your devices like normal, up to the point where it fails to
+ mount your root file system and panics, then you're fine. If, on
+ the other hand, the system goes into an infinite reset loop, then
+ you need to use this option and/or the previous option to force the
+ proper termination settings on your controller. If this happens,
+ then you next need to figure out what your settings should be.
+
+ To find the correct settings, power your machine back down, connect
+ back up the SCSI cables, and boot back into your machine like normal.
+ However, boot with the aic7xxx=verbose:0x39 option. Record the
+ initial DEVCONFIG values for each of your aic7xxx controllers as
+ they are listed, and also record what the machine is detecting as
+ the proper termination on your controllers. NOTE: the order in
+ which the initial DEVCONFIG values are printed out is not gauranteed
+ to be the same order as the SCSI controllers are registered. The
+ above option and this option both work on the order of the SCSI
+ controllers as they are registered, so make sure you match the right
+ DEVCONFIG values with the right controllers if you have more than
+ one aic7xxx controller.
+
+ Once you have the detected termination settings and the initial
+ DEVCONFIG values for each controller, then figure out what the
+ termination on each of the controllers *should* be. Hopefully, that
+ part is correct, but it could possibly be wrong if there is
+ bogus cable detection logic on your controller or something similar.
+ If all the controllers have the correct termination settings, then
+ don't set the aic7xxx=override_term variable at all, leave it alone.
+ Next, on any controllers that go into an infinite reset loop when
+ you unplug all the SCSI cables, get the starting DEVCONFIG value.
+ If the initial DEVCONFIG value is divisible by 2, then the correct
+ setting for that controller is 0. If it's an odd number, then
+ the correct setting for that controller is 1. For any other
+ controllers that didn't have an infinite reset problem, then reverse
+ the above options. If DEVCONFIG was even, then the correct setting
+ is 1, if not then the correct setting is 0.
+
+ Now that you know what the correct setting was for each controller,
+ we need to encode that into the aic7xxx=stpwlev:0x... variable.
+ This variable is a bit field encoded variable. Bit 0 is for the first
+ aic7xxx controller, bit 1 for the next, etc. Put all these bits
+ together and you get a number. For example, if the third aic7xxx
+ needed a 1, but the second and first both needed a 0, then the bits
+ would be 100 in binary. This then translates to 0x04. You would
+ therefore set aic7xxx=stpwlev:0x04. This is fairly standard binary
+ to hexadecimal conversions here. If you aren't up to speed on the
+ binary->hex conversion then send an email to the aic7xxx mailing
+ list and someone can help you out.
+
"aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to enable
tagged queueing on specific devices. As of driver version 5.0.6, we
now globally enable tagged queueing by default, but we also disable
@@ -214,8 +366,8 @@
aic7xxx=verbose,extended,irq_trigger:1
- The only requirement is that individual options be separated by a comma on
- the command line.
+ The only requirement is that individual options be separated by a comma or
+ a period on the command line.
Module Loading command options
------------------------------
@@ -263,11 +415,35 @@
Thanks to Michael Neuffer for for his upper-level SCSI help, and
Matthew Jacob for statistics support.
+ Debugging the driver
+ ------------------------------
+ Should you have problems with this driver, and would like some help in
+ getting them solved, there are a couple debugging items built into
+ the driver to facilitate getting the needed information from the system.
+ In general, I need a complete description of the problem, with as many
+ logs as possible concerning what happens. To help with this, there is
+ a command option aic7xxx=panic_on_abort. This option, when set, forces
+ the driver to panic the kernel on the first SCSI abort issued by the
+ mid level SCSI code. If your system is going to reset loops and you
+ can't read the screen, then this is what you need. Not only will it
+ stop the system, but it also prints out a large amount of state
+ information in the process. Second, if you specify the option
+ "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much
+ information as it runs that you won't be able to see anything.
+ However, this can actually be very usefull if your machine simply
+ locks up when trying to boot, since it will pin-point what was last
+ happening (in regards to the aic7xxx driver) immediately prior to
+ the lockup. This is really only usefull if your machine simply can
+ not boot up successfully. If you can get your machine to run, then
+ this will produce far too much information.
+
FTP sites
------------------------------
- ftp://ftp.dialnet.net/pub/linux/aic7xxx/
+ ftp://ftp.redhat.com/pub/aic/
- Primary site for Doug Ledford developed driver releases
- - US Linux mirror of Teleport site
+ ftp://ftp.dialnet.net/pub/linux/aic7xxx
+ - Temporary mirror of the redhat.com ftp site while people
+ get used to the new address
ftp://ftp.pcnet.com/users/eischen/Linux/
- Dan Eischen's driver distribution area
ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov