tmscsim.txt

linux 内核源代码

    transfers, Disconnection, leaves Send Start (not used) untouched and
    enables Tagged Command Queueing for the selected device. The "-" skips
    the Negotiation Period setting but the "10" sets the max sync. speed to
    10 MHz. It's useless to specify both NegoPeriod and SyncSpeed as
    discussed above. The values used in this example will result in maximum
    performance.

(3) Special commands: You can force a SCSI bus reset, an INQUIRY command, the
    removal or the addition of a device's DCB and a SCSI register dump.
    This is only used for debugging when you meet problems. The parameter of
    the INQUIRY and REMOVE commands is the device index as shown by the
    output of /proc/scsi/tmscsim/? in the device listing in the first column
    (Idx). ADD takes the SCSI ID and LUN.
    Examples:
     echo "reset" >/proc/scsi/tmscsim/0
     echo "inquiry 1" >/proc/scsi/tmscsim/0
     echo "remove 2" >/proc/scsi/tmscsim/1
     echo "add 2 3" >/proc/scsi/tmscsim/?
     echo "dump" >/proc/scsi/tmscsim/0

    Note that you will meet problems when you REMOVE a device's DCB with the
    remove command if it contains partitions which are mounted. Only use it
    after unmounting its partitions, telling the SCSI mid-level code to
    remove it (scsi remove-single-device) and you really need a few bytes of
    memory.
    The ADD command allows you to configure a device before you tell the
    mid-level code to try detection.


I'd suggest reviewing the output of /proc/scsi/tmscsim/? after changing
settings to see if everything changed as requested.


5. Configuration via boot/module parameters
-------------------------------------------
With the DC390, the driver reads its EEPROM settings and tries to use them.
But you may want to override the settings prior to being able to change the
driver configuration via /proc/scsi/tmscsim/?.
If you do have another AM53C974 based adapter, that's even the only
possibility to adjust settings before you are able to write to the
/proc/scsi/tmscsim/? pseudo-file, e.g. if you want to use another 
adapter ID than 7.  
(BTW, the log message "DC390: No EEPROM found!" is normal without a DC390.)
For this purpose, you can pass options to the driver before it is initialised
by using kernel or module parameters. See lilo(8) or modprobe(1) manual
pages on how to pass params to the kernel or a module.
[NOTE: Formerly, it was not possible to override the EEPROM supplied
 settings of the DC390 with cmd line parameters. This has changed since
 2.0e7]

The syntax of the params is much shorter than the syntax of the /proc/...
interface. This makes it a little bit more difficult to use. However, long
parameter lines have the risk to be misinterpreted and the length of kernel
parameters is limited.

As the support for non-DC390 adapters works by simulating the values of the
DC390 EEPROM, the settings are given in a DC390 BIOS' way.

Here's the syntax:
tmscsim=AdaptID,SpdIdx,DevMode,AdaptMode,TaggedCmnds,DelayReset

Each of the parameters is a number, containing the described information:

* AdaptID: The SCSI ID of the host adapter. Must be in the range 0..7
  Default is 7.

* SpdIdx: The index of the maximum speed as in the DC390 BIOS. The values
  0..7 mean 10, 8.0, 6.7, 5.7, 5.0, 4.0, 3.1 and 2 MHz resp. Default is
  0 (10.0 MHz).

* DevMode is a bit mapped value describing the per-device features. It
  applies to all devices. (Sync, Disc and TagQ will only apply, if the
  device supports it.) The meaning of the bits (* = default):

   Bit Val(hex) Val(dec)  Meaning
   *0	 0x01	    1	  Parity check
   *1	 0x02	    2	  Synchronous Negotiation
   *2	 0x04	    4	  Disconnection
   *3	 0x08	    8	  Send Start command on startup. (Not used)
   *4	 0x10	   16	  Tagged Command Queueing

  As usual, the desired value is obtained by adding the wanted values. If
  you want to enable all values, e.g., you would use 31(0x1f). Default is 31.

* AdaptMode is a bit mapped value describing the enabled adapter features.

   Bit Val(hex) Val(dec)  Meaning
   *0	 0x01	    1	  Support more than two drives. (Not used)
   *1	 0x02	    2	  Use DOS compatible mapping for HDs greater than 1GB.
   *2	 0x04	    4	  Reset SCSI Bus on startup.
   *3	 0x08	    8	  Active Negation: Improves SCSI Bus noise immunity.
    4	 0x10	   16	  Immediate return on BIOS seek command. (Not used)
 (*)5	 0x20	   32	  Check for LUNs >= 1.
  
  The default for LUN Check depends on CONFIG_SCSI_MULTI_LUN.

* TaggedCmnds is a number indicating the maximum number of Tagged Commands.
  It is the binary logarithm - 1 of the actual number. Max is 4 (32).
   Value  Number of Tagged Commands
     0		 2
     1		 4
     2		 8
    *3		16
     4		32

* DelayReset is the time in seconds (minus 0.5s), the adapter waits, after a
  bus reset. Default is 1 (corresp. to 1.5s).

Example:
 modprobe tmscsim tmscsim=6,2,31
would set the adapter ID to 6, max. speed to 6.7 MHz, enable all device
features and leave the adapter features, the number of Tagged Commands
and the Delay after a reset to the defaults.

As you can see, you don't need to specify all of the six params.
If you want values to be ignored (i.e. the EEprom settings or the defaults
will be used), you may pass -2 (not 0!) at the corresponding position.

The defaults (7,0,31,15,3,1) are aggressive to allow good performance. You
can use tmscsim=7,0,31,63,4,0 for maximum performance, if your SCSI chain
allows it. If you meet problems, you can use tmscsim=-1 which is a shortcut
for tmscsim=7,4,9,15,2,10.


6. Potential improvements
-------------------------
Most of the intended work on the driver has been done. Here are a few ideas
to further improve its usability:

* Cleanly separate per-Target and per-LUN properties (DCB)
* More intelligent abort() routine
* Use new_eh code (Linux-2.1+)
* Have the mid-level (ML) code (and not the driver) handle more of the
  various conditions.
* Command queueing in the driver: Eliminate Query list and use ML instead.
* More user friendly boot/module param syntax

Further investigation on these problems:

* Driver hangs with sync readcdda (xcdroast) (most probably VIA PCI error)

Known problems: 
Please see http://www.garloff.de/kurt/linux/dc390/problems.html

* Changing the parameters of multi-lun by the tmscsim/? interface will
  cause problems, cause these settings are mostly per Target and not per LUN
  and should be updated accordingly. To be fixed for 2.0d24.
* CDRs (eg Yam CRW4416) not recognized, because some buggy devices don't 
  recover from a SCSI reset in time. Use a higher delay or don't issue
  a SCSI bus reset on driver initialization. See problems page.
  For the CRW4416S, this seems to be solved with firmware 1.0g (reported by 
  Jean-Yves Barbier).
* TEAC CD-532S not being recognized. (Works with 1.11).
* Scanners (eg. Astra UMAX 1220S) don't work: Disable Sync Negotiation.
  If this does not help, try echo "INQUIRY t" >/proc/scsi/tmscsim/? (t
  replaced by the dev index of your scanner). You may try to reset your SCSI
  bus afterwards (echo "RESET" >/proc/scsi/tmscsim/?).
  The problem seems to be solved as of 2.0d18, thanks to Andreas Rick.
* If there is a valid partition table, the driver will use it for determining
  the mapping. If there's none, a reasonable mapping (Symbios-like) will be
  assumed. Other operating systems may not like this mapping, though
  it's consistent with the BIOS' behaviour. Old DC390 drivers ignored the
  partition table and used a H/S = 64/32 or 255/63 translation. So if you
  want to be compatible to those, use this old mapping when creating
  partition tables. Even worse, on bootup the DC390 might complain if other
  mappings are found, so auto rebooting may fail.
* In some situations, the driver will get stuck in an abort loop. This is a
  bad interaction between the Mid-Layer of Linux' SCSI code and the driver.
  Try to disable DsCn, if you meet this problem. Please contact me for
  further debugging.


7. Bug reports, debugging and updates
-------------------------------------
Whenever you have problems with the driver, you are invited to ask the
author for help. However, I'd suggest reading the docs and trying to solve
the problem yourself, first. 
If you find something, which you believe to be a bug, please report it to me. 
Please append the output of /proc/scsi/scsi, /proc/scsi/tmscsim/? and
maybe the DC390 log messages to the report. 

Bug reports should be send to me (Kurt Garloff <[e-mail]>) as well
as to the linux-scsi list (<[e-mail]>), as sometimes bugs
are caused by the SCSI mid-level code.

I will ask you for some more details and probably I will also ask you to
enable some of the DEBUG options in the driver (tmscsim.c:DC390_DEBUGXXX
defines). The driver will produce some data for the syslog facility then.
Beware: If your syslog gets written to a SCSI disk connected to your
AM53C974, the logging might produce log output again, and you might end
having your box spending most of its time doing the logging.

The latest version of the driver can be found at:
 http://www.garloff.de/kurt/linux/dc390/
 ftp://ftp.suse.com/pub/people/garloff/linux/dc390/


8. Acknowledgements
-------------------
Thanks to Linus Torvalds, Alan Cox, the FSF people, the XFree86 team and 
all the others for the wonderful OS and software.
Thanks to C.L. Huang and Philip Giang (Tekram) for the initial driver
release and support.
Thanks to Doug Ledford, Gérard Roudier for support with SCSI coding.
Thanks to a lot of people (espec. Chiaki Ishikawa, Andreas Haumer, Hubert 
Tonneau) for intensively testing the driver (and even risking data loss
doing this during early revisions).
Recently, SuSE GmbH, Nuernberg, FRG, has been paying me for the driver
development and maintenance. Special thanks!


9. Copyright
------------
 This driver is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by   
 the Free Software Foundation; version 2 of the License.
 If you want to use any later version of the GNU GPL, you will probably
 be allowed to, but you have to ask me and Tekram <[e-mail]>
 before.

-------------------------------------------------------------------------
Written by Kurt Garloff <[e-mail]> 1998/06/11
Last updated 2000/11/28, driver revision 2.0e7
$Id: README.tmscsim,v 2.25.2.7 2000/12/20 01:07:12 garloff Exp $