1 AIC7xxx Driver for Linux 2 3Introduction 4---------------------------- 5The AIC7xxx SCSI driver adds support for Adaptec (http://www.adaptec.com) 6SCSI controllers and chipsets. Major portions of the driver and driver 7development are shared between both Linux and FreeBSD. Support for the 8AIC-7xxx chipsets have been in the default Linux kernel since approximately 9linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD 102.1.0 or later. 11 12 Supported cards/chipsets 13 ---------------------------- 14 Adaptec Cards 15 ---------------------------- 16 AHA-274x 17 AHA-274xT 18 AHA-274xW 19 AHA-284x 20 AHA-284xW 21 All PCI based cards using any of the chipsets listed under motherboard 22 chipsets. In general, this means *all* of the Adaptec SCSI controllers 23 except the ones specifically excluded later on in this document. 24 25 Motherboard Chipsets 26 ---------------------------- 27 AIC-777x 28 AIC-785x 29 AIC-786x 30 AIC-787x 31 AIC-788x 32 AIC-789x 33 AIC-3860 34 35 Bus Types 36 ---------------------------- 37 W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support 38 SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s. 39 U - Ultra SCSI, transfer rates up to 40MB/s. 40 U2- Ultra 2 SCSI, transfer rates up to 80MB/s. 41 U3- Ultra 3 SCSI, transfer rates up to 160MB/s. 42 D - Differential SCSI. 43 T - Twin Channel SCSI. Up to 14 SCSI devices. 44 45 AHA-274x - EISA SCSI controller 46 AHA-284x - VLB SCSI controller 47 AHA-29xx - PCI SCSI controller 48 AHA-39xx - PCI controllers with multiple separate SCSI channels on-board. 49 50 Not Supported Devices 51 ------------------------------ 52 Adaptec Cards 53 ---------------------------- 54 AHA-2920 (Only the cards that use the Future Domain chipset are not 55 supported, any 2920 cards based on Adaptec AIC chipsets, 56 such as the 2920C, are supported) 57 AAA-13x Raid Adapters 58 AAA-113x Raid Port Card 59 60 Motherboard Chipsets 61 ---------------------------- 62 AIC-781x 63 64 Bus Types 65 ---------------------------- 66 R - Raid Port busses are not supported. 67 68 The hardware RAID devices sold by Adaptec are *NOT* supported by this 69 driver (and will people please stop emailing me about them, they are 70 a totally separate beast from the bare SCSI controllers and this driver 71 can not be retrofitted in any sane manner to support the hardware RAID 72 features on those cards - Doug Ledford). 73 74 75 People 76 ------------------------------ 77 Justin T Gibbs gibbs@plutotech.com 78 (BSD Driver Author) 79 Dan Eischen deischen@iworks.InterWorks.org 80 (Original Linux Driver Co-maintainer) 81 Dean Gehnert deang@teleport.com 82 (Original Linux FTP/patch maintainer) 83 Jess Johnson jester@frenzy.com 84 (AIC7xxx FAQ author) 85 Doug Ledford dledford@redhat.com 86 (Current Linux aic7xxx-5.x.x Driver/Patch/FTP maintainer) 87 88 Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original 89 author of the driver. John has since retired from the project. Thanks 90 again for all his work! 91 92 Mailing list 93 ------------------------------ 94 There is a mailing list available for users who want to track development 95 and converse with other users and developers. This list is for both 96 FreeBSD and Linux support of the AIC7xxx chipsets. 97 98 To subscribe to the AIC7xxx mailing list send mail to the list server, 99 with "subscribe AIC7xxx" in the body (no Subject: required): 100 To: majordomo@FreeBSD.ORG 101 --- 102 subscribe AIC7xxx 103 104 To unsubscribe from the list, send mail to the list server with: 105 To: majordomo@FreeBSD.ORG 106 --- 107 unsubscribe AIC7xxx 108 109 Send regular messages and replies to: AIC7xxx@FreeBSD.ORG 110 111 Boot Command line options 112 ------------------------------ 113 "aic7xxx=no_reset" - Eliminate the SCSI bus reset during startup. 114 Some SCSI devices need the initial reset that this option disables 115 in order to work. If you have problems at bootup, please make sure 116 you aren't using this option. 117 118 "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at 119 bootup by scanning from the highest numbered PCI device to the 120 lowest numbered PCI device, others do just the opposite and scan 121 from lowest to highest numbered PCI device. There is no reliable 122 way to autodetect this ordering. So, we default to the most common 123 order, which is lowest to highest. Then, in case your motherboard 124 scans from highest to lowest, we have this option. If your BIOS 125 finds the drives on controller A before controller B but the linux 126 kernel finds your drives on controller B before A, then you should 127 use this option. 128 129 "aic7xxx=extended" - Force the driver to detect extended drive translation 130 on your controller. This helps those people who have cards without 131 a SEEPROM make sure that linux and all other operating systems think 132 the same way about your hard drives. 133 134 "aic7xxx=scbram" - Some cards have external SCB RAM that can be used to 135 give the card more hardware SCB slots. This allows the driver to use 136 that SCB RAM. Without this option, the driver won't touch the SCB 137 RAM because it is known to cause problems on a few cards out there 138 (such as 3985 class cards). 139 140 "aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel 141 to use the correct IRQ type for your card. This only applies to EISA 142 based controllers. On these controllers, 0 is for Edge triggered 143 interrupts, and 1 is for Level triggered interrupts. If you aren't 144 sure or don't know which IRQ trigger type your EISA card uses, then 145 let the kernel autodetect the trigger type. 146 147 "aic7xxx=verbose" - This option can be used in one of two ways. If you 148 simply specify aic7xxx=verbose, then the kernel will automatically 149 pick the default set of verbose messages for you to see. 150 Alternatively, you can specify the command as 151 "aic7xxx=verbose:0xXXXX" where the X entries are replaced with 152 hexadecimal digits. This option is a bit field type option. For 153 a full listing of the available options, search for the 154 #define VERBOSE_xxxxxx lines in the aic7xxx.c file. If you want 155 verbose messages, then it is recommended that you simply use the 156 aic7xxx=verbose variant of this command. 157 158 "aic7xxx=pci_parity:x" - This option controls whether or not the driver 159 enables PCI parity error checking on the PCI bus. By default, this 160 checking is disabled. To enable the checks, simply specify pci_parity 161 with no value afterwords. To reverse the parity from even to odd, 162 supply any number other than 0 or 255. In short: 163 pci_parity - Even parity checking (even is the normal PCI parity) 164 pci_parity:x - Where x > 0, Odd parity checking 165 pci_parity:0 - No check (default) 166 NOTE: In order to get Even PCI parity checking, you must use the 167 version of the option that does not include the : and a number at 168 the end (unless you want to enter exactly 2^32 - 1 as the number). 169 170 "aic7xxx=no_probe" - This option will disable the probing for any VLB 171 based 2842 controllers and any EISA based controllers. This is 172 needed on certain newer motherboards where the normal EISA I/O ranges 173 have been claimed by other PCI devices. Probing on those machines 174 will often result in the machine crashing or spontaneously rebooting 175 during startup. Examples of machines that need this are the 176 Dell PowerEdge 6300 machines. 177 178 "aic7xxx=seltime:2" - This option controls how long the card waits 179 during a device selection sequence for the device to respond. 180 The original SCSI spec says that this "should be" 256ms. This 181 is generally not required with modern devices. However, some 182 very old SCSI I devices need the full 256ms. Most modern devices 183 can run fine with only 64ms. The default for this option is 184 64ms. If you need to change this option, then use the following 185 table to set the proper value in the example above: 186 0 - 256ms 187 1 - 128ms 188 2 - 64ms 189 3 - 32ms 190 191 "aic7xxx=panic_on_abort" - This option is for debugging and will cause 192 the driver to panic the linux kernel and freeze the system the first 193 time the drivers abort or reset routines are called. This is most 194 helpful when some problem causes infinite reset loops that scroll too 195 fast to see. By using this option, you can write down what the errors 196 actually are and send that information to me so it can be fixed. 197 198 "aic7xxx=dump_card" - This option will print out the *entire* set of 199 configuration registers on the card during the init sequence. This 200 is a debugging aid used to see exactly what state the card is in 201 when we finally finish our initialization routines. If you don't 202 have documentation on the chipsets, this will do you absolutely 203 no good unless you are simply trying to write all the information 204 down in order to send it to me. 205 206 "aic7xxx=dump_sequencer" - This is the same as the above options except 207 that instead of dumping the register contents on the card, this 208 option dumps the contents of the sequencer program RAM. This gives 209 the ability to verify that the instructions downloaded to the 210 card's sequencer are indeed what they are suppossed to be. Again, 211 unless you have documentation to tell you how to interpret these 212 numbers, then it is totally useless. 213 214 "aic7xxx=override_term:0xffffffff" - This option is used to force the 215 termination on your SCSI controllers to a particular setting. This 216 is a bit mask variable that applies for up to 8 aic7xxx SCSI channels. 217 Each channel gets 4 bits, divided as follows: 218 bit 3 2 1 0 219 | | | Enable/Disable Single Ended Low Byte Termination 220 | | En/Disable Single Ended High Byte Termination 221 | En/Disable Low Byte LVD Termination 222 En/Disable High Byte LVD Termination 223 224 The upper 2 bits that deal with LVD termination only apply to Ultra2 225 controllers. Futhermore, due to the current Ultra2 controller 226 designs, these bits are tied together such that setting either bit 227 enables both low and high byte LVD termination. It is not possible 228 to only set high or low byte LVD termination in this manner. This is 229 an artifact of the BIOS definition on Ultra2 controllers. For other 230 controllers, the only important bits are the two lowest bits. Setting 231 the higher bits on non-Ultra2 controllers has no effect. A few 232 examples of how to use this option: 233 234 Enable low and high byte termination on a non-ultra2 controller that 235 is the first aic7xxx controller (the correct bits are 0011), 236 aic7xxx=override_term:0x3 237 238 Enable all termination on the third aic7xxx controller, high byte 239 termination on the second aic7xxx controller, and low and high byte 240 SE termination on the first aic7xxx controller 241 (bits are 1111 0010 0011), 242 aic7xxx=override_term:0xf23 243 244 No attempt has been made to make this option non-cryptic. It really 245 shouldn't be used except in dire circumstances, and if that happens, 246 I'm probably going to be telling you what to set this to anyway :) 247 248 "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV 249 bit in the DEVCONFIG PCI register. Currently, this is one of the 250 very few registers that we have absolutely *no* way of detecting 251 what the variable should be. It depends entirely on how the chipset 252 and external terminators were coupled by the card/motherboard maker. 253 Further, a chip reset (at power up) always sets this bit to 0. If 254 there is no BIOS to run on the chipset/card (such as with a 2910C 255 or a motherboard controller with the BIOS totally disabled) then 256 the variable may not get set properly. Of course, if the proper 257 setting was 0, then that's what it would be after the reset, but if 258 the proper setting is actually 1.....you get the picture. Now, since 259 we can't detect this at all, I've added this option to force the 260 setting. If you have a BIOS on your controller then you should never 261 need to use this option. However, if you are having lots of SCSI 262 reset problems and can't seem to get them knocked out, this may help. 263 264 Here's a test to know for certain if you need this option. Make 265 a boot floppy that you can use to boot your computer up and that 266 will detect the aic7xxx controller. Next, power down your computer. 267 While it's down, unplug all SCSI cables from your Adaptec SCSI 268 controller. Boot the system back up to the Adaptec EZ-SCSI BIOS 269 and then make sure that termination is enabled on your adapter (if 270 you have an Adaptec BIOS of course). Next, boot up the floppy you 271 made and wait for it to detect the aic7xxx controller. If the kernel 272 finds the controller fine, says scsi : x hosts and then tries to 273 detect your devices like normal, up to the point where it fails to 274 mount your root file system and panics, then you're fine. If, on 275 the other hand, the system goes into an infinite reset loop, then 276 you need to use this option and/or the previous option to force the 277 proper termination settings on your controller. If this happens, 278 then you next need to figure out what your settings should be. 279 280 To find the correct settings, power your machine back down, connect 281 back up the SCSI cables, and boot back into your machine like normal. 282 However, boot with the aic7xxx=verbose:0x39 option. Record the 283 initial DEVCONFIG values for each of your aic7xxx controllers as 284 they are listed, and also record what the machine is detecting as 285 the proper termination on your controllers. NOTE: the order in 286 which the initial DEVCONFIG values are printed out is not gauranteed 287 to be the same order as the SCSI controllers are registered. The 288 above option and this option both work on the order of the SCSI 289 controllers as they are registered, so make sure you match the right 290 DEVCONFIG values with the right controllers if you have more than 291 one aic7xxx controller. 292 293 Once you have the detected termination settings and the initial 294 DEVCONFIG values for each controller, then figure out what the 295 termination on each of the controllers *should* be. Hopefully, that 296 part is correct, but it could possibly be wrong if there is 297 bogus cable detection logic on your controller or something similar. 298 If all the controllers have the correct termination settings, then 299 don't set the aic7xxx=override_term variable at all, leave it alone. 300 Next, on any controllers that go into an infinite reset loop when 301 you unplug all the SCSI cables, get the starting DEVCONFIG value. 302 If the initial DEVCONFIG value is divisible by 2, then the correct 303 setting for that controller is 0. If it's an odd number, then 304 the correct setting for that controller is 1. For any other 305 controllers that didn't have an infinite reset problem, then reverse 306 the above options. If DEVCONFIG was even, then the correct setting 307 is 1, if not then the correct setting is 0. 308 309 Now that you know what the correct setting was for each controller, 310 we need to encode that into the aic7xxx=stpwlev:0x... variable. 311 This variable is a bit field encoded variable. Bit 0 is for the first 312 aic7xxx controller, bit 1 for the next, etc. Put all these bits 313 together and you get a number. For example, if the third aic7xxx 314 needed a 1, but the second and first both needed a 0, then the bits 315 would be 100 in binary. This then translates to 0x04. You would 316 therefore set aic7xxx=stpwlev:0x04. This is fairly standard binary 317 to hexadecimal conversions here. If you aren't up to speed on the 318 binary->hex conversion then send an email to the aic7xxx mailing 319 list and someone can help you out. 320 321 "aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to disable 322 or enable Tagged Command Queueing (TCQ) on specific devices. As of 323 driver version 5.1.11, TCQ is now either on or off by default 324 according to the setting you choose during the make config process. 325 In order to en/disable TCQ for certian devices at boot time, a user 326 may use this boot param. The driver will then parse this message out 327 and en/disable the specific device entries that are present based upon 328 the value given. The param line is parsed in the following manner: 329 330 { - first instance indicates the start of this parameter values 331 second instance is the start of entries for a particular 332 device entry 333 } - end the entries for a particular host adapter, or end the entire 334 set of parameter entries 335 , - move to next entry. Inside of a set of device entries, this 336 moves us to the next device on the list. Outside of device 337 entries, this moves us to the next host adapter 338 . - Same effect as , but is safe to use with insmod. 339 x - the number to enter into the array at this position. 340 0 = Enable tagged queueing on this device and use the default 341 queue depth 342 1-254 = Enable tagged queueing on this device and use this 343 number as the queue depth 344 255 = Disable tagged queueing on this device. 345 Note: anything above 32 for an actual queue depth is wasteful 346 and not recommended. 347 348 A few examples of how this can be used: 349 350 tag_info:{{8,12,,0,,255,4}} 351 This line will only effect the first aic7xxx card registered. It 352 will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2 353 at the default, set id 3 to tagged queueing enabled and use the 354 default queue depth, id 4 default, id 5 disabled, and id 6 to 4. 355 Any not specified entries stay at the default value, repeated 356 commas with no value specified will simply increment to the next id 357 without changing anything for the missing values. 358 359 tag_info:{,,,{,,,255}} 360 First, second, and third adapters at default values. Fourth 361 adapter, id 3 is disabled. Notice that leading commas simply 362 increment what the first number effects, and there are no need 363 for trailing commas. When you close out an adapter, or the 364 entire entry, anything not explicitly set stays at the default 365 value. 366 367 A final note on this option. The scanner I used for this isn't 368 perfect or highly robust. If you mess the line up, the worst that 369 should happen is that the line will get ignored. If you don't 370 close out the entire entry with the final bracket, then any other 371 aic7xxx options after this will get ignored. So, in general, be 372 sure of what you are entering, and after you have it right, just 373 add it to the lilo.conf file so there won't be any mistakes. As 374 a means of checking this parser, the entire tag_info array for 375 each card is now printed out in the /proc/scsi/aic7xxx/x file. You 376 can use that to verify that your options were parsed correctly. 377 378 Boot command line options may be combined to form the proper set of options 379 a user might need. For example, the following is valid: 380 381 aic7xxx=verbose,extended,irq_trigger:1 382 383 The only requirement is that individual options be separated by a comma or 384 a period on the command line. 385 386 Module Loading command options 387 ------------------------------ 388 When loading the aic7xxx driver as a module, the exact same options are 389 available to the user. However, the syntax to specify the options changes 390 slightly. For insmod, you need to wrap the aic7xxx= argument in quotes 391 and replace all ',' with '.'. So, for example, a valid insmod line 392 would be: 393 394 insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended' 395 396 This line should result in the *exact* same behaviour as if you typed 397 it in at the lilo prompt and the driver was compiled into the kernel 398 instead of being a module. The reason for the single quote is so that 399 the shell won't try to interpret anything in the line, such as {. 400 Insmod assumes any options starting with a letter instead of a number 401 is a character string (which is what we want) and by switching all of 402 the commas to periods, insmod won't interpret this as more than one 403 string and write junk into our binary image. I consider it a bug in 404 the insmod program that even if you wrap your string in quotes (quotes 405 that pass the shell mind you and that insmod sees) it still treates 406 a comma inside of those quotes as starting a new variable, resulting 407 in memory scribbles if you don't switch the commas to periods. 408 409 410 Kernel Compile options 411 ------------------------------ 412 The various kernel compile time options for this driver are now fairly 413 well documented in the file Documentation/Configure.help. In order to 414 see this documentation, you need to use one of the advanced configuration 415 programs (menuconfig and xconfig). If you are using the "make menuconfig" 416 method of configuring your kernel, then you would simply highlight the 417 option in question and hit the ? key. If you are using the "make xconfig" 418 method of configuring your kernel, then simply click on the help button 419 next to the option you have questions about. The help information from 420 the Configure.help file will then get automatically displayed. 421 422 /proc support 423 ------------------------------ 424 The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/ 425 directory. That directory contains a file for each SCSI controller in 426 the system. Each file presents the current configuration and transfer 427 statistics (enabled with #define in aic7xxx.c) for each controller. 428 429 Thanks to Michael Neuffer for his upper-level SCSI help, and 430 Matthew Jacob for statistics support. 431 432 Debugging the driver 433 ------------------------------ 434 Should you have problems with this driver, and would like some help in 435 getting them solved, there are a couple debugging items built into 436 the driver to facilitate getting the needed information from the system. 437 In general, I need a complete description of the problem, with as many 438 logs as possible concerning what happens. To help with this, there is 439 a command option aic7xxx=panic_on_abort. This option, when set, forces 440 the driver to panic the kernel on the first SCSI abort issued by the 441 mid level SCSI code. If your system is going to reset loops and you 442 can't read the screen, then this is what you need. Not only will it 443 stop the system, but it also prints out a large amount of state 444 information in the process. Second, if you specify the option 445 "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much 446 information as it runs that you won't be able to see anything. 447 However, this can actually be very useful if your machine simply 448 locks up when trying to boot, since it will pin-point what was last 449 happening (in regards to the aic7xxx driver) immediately prior to 450 the lockup. This is really only useful if your machine simply can 451 not boot up successfully. If you can get your machine to run, then 452 this will produce far too much information. 453 454 FTP sites 455 ------------------------------ 456 ftp://ftp.redhat.com/pub/aic/ 457 - Out of date. I used to keep stuff here, but too many people 458 complained about having a hard time getting into Red Hat's ftp 459 server. So use the web site below instead. 460 ftp://ftp.pcnet.com/users/eischen/Linux/ 461 - Dan Eischen's driver distribution area 462 ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/ 463 - European Linux mirror of Teleport site 464 465 Web sites 466 ------------------------------ 467 http://people.redhat.com/dledford/ 468 - My web site, also the primary aic7xxx site with several related 469 pages. 470 471Dean W. Gehnert 472deang@teleport.com 473 474$Revision: 1.1.1.1 $ 475 476Modified by Doug Ledford 1998-2000 477 478