ibmmca.txt

linux 内核源代码

   1) A lot of complains after the 2.4.0-prerelease kernel came in about
      the impossibility to compile the driver as a module. This problem is
      solved. In combination with that problem, some unprecise declaration
      of the function option_setup() gave some warnings during compilation.
      This is solved, too by a forward declaration in ibmmca.c.
   2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and
      was entirely removed.
   3) Some switch statements got optimized in code, as some minor variables
      in internal SCSI-command handlers.
   - Michael Lang

   4 To do
   -------
        - IBM SCSI-2 F/W external SCSI bus support in separate mode!
	- It seems that the handling of bad disks is really bad -
	  non-existent, in fact. However, a low-level driver cannot help
	  much, if such things happen.

   5 Users' Manual
   ---------------
   5.1 Commandline Parameters
   --------------------------
   There exist several features for the IBM SCSI-subsystem driver.
   The commandline parameter format is:
   
         ibmmcascsi=<command1>,<command2>,<command3>,...
	 
   where commandN can be one of the following:
   
         display    Owners of a model 95 or other PS/2 systems with an
	            alphanumeric LED display may set this to have their
		    display showing the following output of the 8 digits:
		      
		                ------DA
				
		    where '-' stays dark, 'D' shows the SCSI-device id
		    and 'A' shows the SCSI hostindex, being currently 
		    accessed. During boottime, this will give the message
		    
		                SCSIini*
				
                    on the LED-panel, where the * represents a rotator, 
		    showing the activity during the probing phase of the
		    driver which can take up to two minutes per SCSI-adapter.
	 adisplay   This works like display, but gives more optical overview 
	            of the activities on the SCSI-bus. The display will have
		    the following output:
		    
		                6543210A
				
		    where the numbers 0 to 6 light up at the shown position,
		    when the SCSI-device is accessed. 'A' shows again the SCSI
		    hostindex. If display nor adisplay is set, the internal
		    PS/2 harddisk LED is used for media-activities. So, if
		    you really do not have a system with a LED-display, you
		    should not set display or adisplay. Keep in mind, that
		    display and adisplay can only be used alternatively. It
		    is not recommended to use this option, if you have some
		    wide-addressed devices e.g. at the SCSI-2 F/W adapter in
		    your system. In addition, the usage of the display for
		    other tasks in parallel, like the linuxinfo-utility makes 
		    no sense with this option.
	 activity   This enables the PS/2 harddisk LED activity indicator.
	            Most PS/2 have no alphanumeric LED display, but some
		    indicator. So you should use this parameter to activate it.
		    If you own model 9595 (Server95), you can have both, the 
		    LED panel and the activity indicator in parallel. However,
		    some PS/2s, like the 8595 do not have any harddisk LED 
		    activity indicator, which means, that you must use the
		    alphanumeric LED display if you want to monitor SCSI-
		    activity.
	 bypass     This is obsolete from driver version 4.0, as the adapters
	            got that far understood, that the selection between 
		    integrated and bypassed commands should now work completely
		    correct! For historical reasons, the old description is
		    kept here:
	            This commandline parameter forces the driver never to use
	            SCSI-subsystems' integrated SCSI-command set. Except of
		    the immediate assign, which is of vital importance for
		    every IBM SCSI-subsystem to set its ldns right. Instead,
		    the ordinary ANSI-SCSI-commands are used and passed by the
		    controller to the SCSI-devices, therefore 'bypass'. The
		    effort, done by the subsystem is quite bogus and at a
		    minimum and therefore it should work everywhere. This
		    could maybe solve troubles with old or integrated SCSI-
		    controllers and nasty harddisks. Keep in mind, that using 
		    this flag will slow-down SCSI-accesses slightly, as the 
		    software generated commands are always slower than the 
		    hardware. Non-harddisk devices always get read/write-
		    commands in bypass mode. On the most recent releases of 
		    the Linux IBM-SCSI-driver, the bypass command should be
		    no longer a necessary thing, if you are sure about your
		    SCSI-hardware!
	 normal     This is the parameter, introduced on the 2.0.x development
	            rail by ZP Gu. This parameter defines the SCSI-device
		    scan order in the new industry standard. This means, that
		    the first SCSI-device is the one with the lowest pun.
		    E.g. harddisk at pun=0 is scanned before harddisk at
		    pun=6, which means, that harddisk at pun=0 gets sda
		    and the one at pun=6 gets sdb.
	 ansi       The ANSI-standard for the right scan order, as done by
	            IBM, Microware and Microsoft, scans SCSI-devices starting
		    at the highest pun, which means, that e.g. harddisk at
		    pun=6 gets sda and a harddisk at pun=0 gets sdb. If you
		    like to have the same SCSI-device order, as in DOS, OS-9
		    or OS/2, just use this parameter.
         fast       SCSI-I/O in synchronous mode is done at 5 MHz for IBM-
                    SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus
                    should then run at 10 MHz if Fast-SCSI is enabled,
                    and at 5 MHz if Fast-SCSI is disabled on the external
                    bus. This is the default setting when nothing is 
                    specified here.
         medium     Synchronous rate is at 50% approximately, which means
                    2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext.
                    SCSI-bus (when Fast-SCSI speed enabled on external bus).
         slow       The slowest possible synchronous transfer rate is set. 
                    This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz
                    for F/W external bus at Fast-SCSI speed on the external
		    bus.
		    
   A further option is that you can force the SCSI-driver to accept a SCSI-
   subsystem at a certain I/O-address with a predefined adapter PUN. This
   is done by entering 

                  commandN   = I/O-base
		  commandN+1 = adapter PUN
		  
   e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem 
   at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if
   the driver does really not recognize your SCSI-adapter! With driver version
   3.2, this recognition of various adapters was hugely improved and you
   should try first to remove your commandline arguments of such type with a 
   newer driver. I bet, it will be recognized correctly. Even multiple and 
   different types of IBM SCSI-adapters should be recognized correctly, too.
   Use the forced detection method only as last solution!
   
   Examples:
   
        ibmmcascsi=adisplay
	
   This will use the advanced display mode for the model 95 LED alphanumeric
   display.
   
        ibmmcascsi=display,0x3558,7
	
   This will activate the default display mode for the model 95 LED display
   and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558
   with adapter PUN 7.
   
   5.2 Troubleshooting
   -------------------
   The following FAQs should help you to solve some major problems with this
   driver.
   
     Q: "Reset SCSI-devices at boottime" halts the system at boottime, why?
     A: This is only tested with the IBM SCSI Adapter w/cache. It is not
        yet proven to run on other adapters, however you may be lucky.
	In version 3.1d this has been hugely improved and should work better,
	now. Normally you really won't need to activate this flag in the
	kernel configuration, as all post 1989 SCSI-devices should accept
	the reset-signal, when the computer is switched on. The SCSI-
	subsystem generates this reset while being initialized. This flag
	is really reserved for users with very old, very strange or self-made
	SCSI-devices.
     Q: Why is the SCSI-order of my drives mirrored to the device-order
        seen from OS/2 or DOS ?
     A: It depends on the operating system, if it looks at the devices in
        ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or
	if it just starts at pun 0 and counts up. If you want to be conform
	with OS/2 and DOS, you have to activate this flag in the kernel
	configuration or you should set 'ansi' as parameter for the kernel.
	The parameter 'normal' sets the new industry standard, starting
	from pun 0, scanning up to pun 6. This allows you to change your 
	opinion still after having already compiled the kernel.
     Q: Why can't I find IBM MCA SCSI support in the config menu?
     A: You have to activate MCA bus support, first.
     Q: Where can I find the latest info about this driver?
     A: See the file MAINTAINERS for the current WWW-address, which offers
        updates, info and Q/A lists. At this file's origin, the webaddress
	was: http://www.uni-mainz.de/~langm000/linux.html
     Q: My SCSI-adapter is not recognized by the driver, what can I do?
     A: Just force it to be recognized by kernel parameters. See section 5.1.
        If this really happens, do also send e-mail to the maintainer, as
	forced detection should be never necessary. Forced detection is in
	principal some flaw of the driver adapter detection and goes into 
	bug reports.
     Q: The driver screws up, if it starts to probe SCSI-devices, is there
        some way out of it?
     A: Yes, that was some recognition problem of the correct SCSI-adapter
        and its I/O base addresses. Upgrade your driver to the latest release
	and it should be fine again.
     Q: I get a message: panic IBM MCA SCSI: command error .... , what can
        I do against this?
     A: Previously, I followed the way by ignoring command errors by using
        ibmmcascsi=forgiveall, but this command no longer exists and is
	obsolete. If such a problem appears, it is caused by some segmentation
	fault of the driver, which maps to some unallowed area. The latest 
	version of the driver should be ok, as most bugs have been solved.
     Q: There are still kernel panics, even after having set 
        ibmmcascsi=forgiveall. Are there other possibilities to prevent
	such panics?
     A: No, get just the latest release of the driver and it should work 
        better and better with increasing version number. Forget about this
	ibmmcascsi=forgiveall, as also ignorecmd are obsolete.!
     Q: Linux panics or stops without any comment, but it is probable, that my
        harddisk(s) have bad blocks.
     A: Sorry, the bad-block handling is still a feeble point of this driver,
        but is on the schedule for development in the near future.
     Q: Linux panics while dynamically assigning SCSI-ids or ldns.
     A: If you disconnect a SCSI-device from the machine, while Linux is up
        and the driver uses dynamical reassignment of logical device numbers
	(ldn), it really gets "angry" if it won't find devices, that were still
	present at boottime and stops Linux.
     Q: The system does not recover after an abort-command has been generated.
     A: This is regrettably true, as it is not yet understood, why the 
        SCSI-adapter does really NOT generate any interrupt at the end of
	the abort-command. As no interrupt is generated, the abort command
	cannot get finished and the system hangs, sorry, but checks are 
	running to hunt down this problem. If there is a real pending command,
	the interrupt MUST get generated after abort. In this case, it
	should finish well.
     Q: The system gets in bad shape after a SCSI-reset, is this known?
     A: Yes, as there are a lot of prescriptions (see the Linux Hackers'
        Guide) what has to be done for reset, we still share the bad shape of
	the reset functions with all other low level SCSI-drivers. 
	Astonishingly, reset works in most cases quite ok, but the harddisks
	won't run in synchronous mode anymore after a reset, until you reboot.
     Q: Why does my XXX w/Cache adapter not use read-prefetch?
     A: Ok, that is not completely possible. If a cache is present, the 
        adapter tries to use it internally. Explicitly, one can use the cache
	with a read prefetch command, maybe in future, but this requires
	some major overhead of SCSI-commands that risks the performance to
	go down more than it gets improved. Tests with that are