📄 readme.aic7xxx
字号:
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 disable or enable Tagged Command Queueing (TCQ) on specific devices. As of driver version 5.1.11, TCQ is now either on or off by default according to the setting you choose during the make config process. In order to en/disable TCQ for certian devices at boot time, a user may use this boot param. The driver will then parse this message out and en/disable the specific device entries that are present based upon the value given. The param line is parsed in the following manner: { - first instance indicates the start of this parameter values second instance is the start of entries for a particular device entry } - end the entries for a particular host adapter, or end the entire set of parameter entries , - move to next entry. Inside of a set of device entries, this moves us to the next device on the list. Outside of device entries, this moves us to the next host adapter . - Same effect as , but is safe to use with insmod. x - the number to enter into the array at this position. 0 = Enable tagged queueing on this device and use the default queue depth 1-254 = Enable tagged queueing on this device and use this number as the queue depth 255 = Disable tagged queueing on this device. Note: anything above 32 for an actual queue depth is wasteful and not recommended. A few examples of how this can be used: tag_info:{{8,12,,0,,255,4}} This line will only effect the first aic7xxx card registered. It will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2 at the default, set id 3 to tagged queueing enabled and use the default queue depth, id 4 default, id 5 disabled, and id 6 to 4. Any not specified entries stay at the default value, repeated commas with no value specified will simply increment to the next id without changing anything for the missing values. tag_info:{,,,{,,,255}} First, second, and third adapters at default values. Fourth adapter, id 3 is disabled. Notice that leading commas simply increment what the first number effects, and there are no need for trailing commas. When you close out an adapter, or the entire entry, anything not explicitly set stays at the default value. A final note on this option. The scanner I used for this isn't perfect or highly robust. If you mess the line up, the worst that should happen is that the line will get ignored. If you don't close out the entire entry with the final bracket, then any other aic7xxx options after this will get ignored. So, in general, be sure of what you are entering, and after you have it right, just add it to the lilo.conf file so there won't be any mistakes. As a means of checking this parser, the entire tag_info array for each card is now printed out in the /proc/scsi/aic7xxx/x file. You can use that to verify that your options were parsed correctly. Boot command line options may be combined to form the proper set of options a user might need. For example, the following is valid: aic7xxx=verbose,extended,irq_trigger:1 The only requirement is that individual options be separated by a comma or a period on the command line. Module Loading command options ------------------------------ When loading the aic7xxx driver as a module, the exact same options are available to the user. However, the syntax to specify the options changes slightly. For insmod, you need to wrap the aic7xxx= argument in quotes and replace all ',' with '.'. So, for example, a valid insmod line would be: insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended' This line should result in the *exact* same behaviour as if you typed it in at the lilo prompt and the driver was compiled into the kernel instead of being a module. The reason for the single quote is so that the shell won't try to interpret anything in the line, such as {. Insmod assumes any options starting with a letter instead of a number is a character string (which is what we want) and by switching all of the commas to periods, insmod won't interpret this as more than one string and write junk into our binary image. I consider it a bug in the insmod program that even if you wrap your string in quotes (quotes that pass the shell mind you and that insmod sees) it still treates a comma inside of those quotes as starting a new variable, resulting in memory scribbles if you don't switch the commas to periods. Kernel Compile options ------------------------------ The various kernel compile time options for this driver are now fairly well documented in the file Documentation/Configure.help. In order to see this documentation, you need to use one of the advanced configuration programs (menuconfig and xconfig). If you are using the "make menuconfig" method of configuring your kernel, then you would simply highlight the option in question and hit the ? key. If you are using the "make xconfig" method of configuring your kernel, then simply click on the help button next to the option you have questions about. The help information from the Configure.help file will then get automatically displayed. /proc support ------------------------------ The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/ directory. That directory contains a file for each SCSI controller in the system. Each file presents the current configuration and transfer statistics (enabled with #define in aic7xxx.c) for each controller. Thanks to Michael Neuffer 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 useful 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 useful 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.redhat.com/pub/aic/ - Out of date. I used to keep stuff here, but too many people complained about having a hard time getting into Red Hat's ftp server. So use the web site below instead. ftp://ftp.pcnet.com/users/eischen/Linux/ - Dan Eischen's driver distribution area ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/ - European Linux mirror of Teleport site Web sites ------------------------------ http://people.redhat.com/dledford/ - My web site, also the primary aic7xxx site with several related pages.Dean W. Gehnertdeang@teleport.com$Revision: 3.0 $Modified by Doug Ledford 1998-2000⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -