ibmmca.txt

linux 内核源代码

      the kernel-scsi-environment. The markup of a tape is done in the 
      global ldn_is_tape[] array. If the entry on index ldn 
      is 1, there is a tapedrive connected.
   3) The ldn_is_tape[] array is necessary to distinguish between tape- and 
      other devices. Fixed blocklength devices should not cause a problem
      with the SCB-command for read and write in the ibmmca_queuecommand
      subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for
      the tape-devices, as recommended by IBM in this Technical Reference,
      mentioned below. (IBM recommends to avoid using the read/write of the
      subsystem, but the fact was, that read/write causes a command error from
      the subsystem and this causes kernel-panic.)
   4) In addition, I propose to use the ldn instead of a fix char for the
      display of PS2_DISK_LED_ON(). On 95, one can distinguish between the
      devices that are accessed. It shows activity and easyfies debugging.   
   The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2
   (I do not know yet the type). Optimization and CD-ROM audio-support, 
   I am working on ...
   - Michael Lang
   
   June 19 1997: (v1.6b)
   1) Submitting the extra-array ldn_is_tape[] -> to the local ld[]
      device-array. 
   2) CD-ROM Audio-Play seems to work now.
   3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code
      0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears 
      also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that 
      the problem is independent of the low-level-driver/bus-architecture.
   4) Hexadecimal ldn on PS/2-95 LED-display.
   5) Fixing of the PS/2-LED on/off that it works right with tapedrives and
      does not confuse the disk_rw_in_progress counter.
   - Michael Lang
  
   June 21 1997: (v1.7b)
   1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the
      outer-world about operational load statistics on the different ldns,
      seen by the driver. Everybody that has more than one IBM-SCSI should
      test this, because I only have one and cannot see what happens with more
      than one IBM-SCSI hosts.
   2) Definition of a driver version-number to have a better recognition of 
      the source when there are existing too much releases that may confuse
      the user, when reading about release-specific problems. Up to know,
      I calculated the version-number to be 1.7. Because we are in BETA-test
      yet, it is today 1.7b.
   3) Sorry for the heavy bug I programmed on June 19 1997! After that, the
      CD-ROM did not work any more! The C7-command was a fake impression
      I got while programming. Now, the READ and WRITE commands for CD-ROM are
      no longer running over the subsystem, but just over 
      IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts
      much faster(!) and hopefully all fancy multimedia-functions, like direct
      digital recording from audio-CDs also work. (I tried it with cdda2wav
      from the cdwtools-package and it filled up the harddisk immediately :-).)
      To easify boolean logics, a further local device-type in ld[], called
      is_cdrom has been included.
   4) If one uses a SCSI-device of unsupported type/commands, one
      immediately runs into a kernel-panic caused by Command Error. To better
      understand which SCSI-command caused the problem, I extended this
      specific panic-message slightly.
   - Michael Lang
 
   June 25 1997: (v1.8b)
   1) Some cosmetical changes for the handling of SCSI-device-types.
      Now, also CD-Burners / WORMs and SCSI-scanners should work. For
      MO-drives I have no experience, therefore not yet supported.
      In logical_devices I changed from different type-variables to one
      called 'device_type' where the values, corresponding to scsi.h,
      of a SCSI-device are stored.
   2) There existed a small bug, that maps a device, coming after a SCSI-tape
      wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong
      -> problem removed.
   3) Extension of the logical_device structure. Now it contains also device,
      vendor and revision-level of a SCSI-device for internal usage.
   - Michael Lang

   June 26-29 1997: (v2.0b)
   1) The release number 2.0b is necessary because of the completely new done
      recognition and handling of SCSI-devices with the adapter. As I got
      from Chris the hint, that the subsystem can reassign ldns dynamically,
      I remembered this immediate_assign-command, I found once in the handbook.
      Now, the driver first kills all ldn assignments that are set by default
      on the SCSI-subsystem. After that, it probes on all puns and luns for
      devices by going through all combinations with immediate_assign and
      probing for devices, using device_inquiry. The found physical(!) pun,lun
      structure is stored in get_scsi[][] as device types. This is followed
      by the assignment of all ldns to existing SCSI-devices. If more ldns
      than devices are available, they are assigned to non existing pun,lun
      combinations to satisfy the adapter. With this, the dynamical mapping
      was possible to implement. (For further info see the text in the 
      source code and in the description below. Read the description
      below BEFORE installing this driver on your system!)
   2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
   3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
      (pun) of the accessed SCSI-device. This is now senseful, because the 
      pun known within the driver is exactly the pun of the physical device
      and no longer a fake one.
   4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where
      hit-statistics of ldns is shown and a second part, where the maps of 
      physical and logical SCSI-devices are displayed. This could be very 
      interesting, when one is using more than 15 SCSI-devices in order to 
      follow the dynamical remapping of ldns.
   - Michael Lang
 
   June 26-29 1997: (v2.0b-1)
   1) I forgot to switch the local_checking_phase_flag to 1 and back to 0
      in the dynamical remapping part in ibmmca_queuecommand for the 
      device_exist routine. Sorry.
   - Michael Lang
 
   July 1-13 1997: (v3.0b,c)
   1) Merging of the driver-developments of Klaus Kudielka and Michael Lang 
      in order to get a optimum and unified driver-release for the 
      IBM-SCSI-Subsystem-Adapter(s).
         For people, using the Kernel-release >=2.1.0, module-support should 
      be no problem. For users, running under <2.1.0, module-support may not 
      work, because the methods have changed between 2.0.x and 2.1.x.
   2) Added some more effective statistics for /proc-output.
   3) Change typecasting at necessary points from (unsigned long) to
      virt_to_bus().
   4) Included #if... at special points to have specific adaption of the
      driver to kernel 2.0.x and 2.1.x. It should therefore also run with 
      later releases.
   5) Magneto-Optical drives and medium-changers are also recognized, now.
      Therefore, we have a completely gapfree recognition of all SCSI-
      device-types, that are known by Linux up to kernel 2.1.31.
   6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within
      the configuration, each connected SCSI-device will get a reset command
      during boottime. This can be necessary for some special SCSI-devices.
      This flag should be included in Config.in.
      (See also the new Config.in file.)
   Probable next improvement: bad disk handler.
   - Michael Lang
 
   Sept 14 1997: (v3.0c)
   1) Some debugging and speed optimization applied.
   - Michael Lang

   Dec 15, 1997
    - [e-mail]
    - made the front panel display thingy optional, specified from the
    command-line via ibmmcascsi=display.  Along the lines of the /LED
    option for the OS/2 driver.
    - fixed small bug in the LED display that would hang some machines.
    - reversed ordering of the drives (using the
    IBMMCA_SCSI_ORDER_STANDARD define).  This is necessary for two main
    reasons:
	- users who've already installed Linux won't be screwed.  Keep
	in mind that not everyone is a kernel hacker.
	- be consistent with the BIOS ordering of the drives.  In the
	BIOS, id 6 is C:, id 0 might be D:.  With this scheme, they'd be
	backwards.  This confuses the crap out of those heathens who've
	got a impure Linux installation (which, <wince>, I'm one of).
    This whole problem arises because IBM is actually non-standard with
    the id to BIOS mappings.  You'll find, in fdomain.c, a similar
    comment about a few FD BIOS revisions.  The Linux (and apparently
    industry) standard is that C: maps to scsi id (0,0).  Let's stick
    with that standard.
    - Since this is technically a branch of my own, I changed the
    version number to 3.0e-cpb.

   Jan 17, 1998: (v3.0f)
   1) Addition of some statistical info for /proc in proc_info.
   2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15
      1997. In fact, IBM is right, concerning the assignment of SCSI-devices 
      to driveletters. It is conform to the ANSI-definition of the SCSI-
      standard to assign drive C: to SCSI-id 6, because it is the highest
      hardware priority after the hostadapter (that has still today by
      default everywhere id 7). Also realtime-operating systems that I use, 
      like LynxOS and OS9, which are quite industrial systems use top-down
      numbering of the harddisks, that is also starting at id 6. Now, one
      sits a bit between two chairs. On one hand side, using the define
      IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to
      the IBM- and ANSI-SCSI-standard and keeps this driver downward
      compatible to older releases, on the other hand side, people is quite
      habituated in believing that C: is assigned to (0,0) and much other
      SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD 
      define out of the driver and put it into Config.in as subitem of 
      'IBM SCSI support'. A help, added to Documentation/Configure.help 
      explains the differences between saying 'y' or 'n' to the user, when 
      IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to 
      choose the way of assignment, depending on his own situation and gusto.
   3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is
      now called IBMMCA_SCSI_DEV_RESET.
   4) Optimization of proc_info and its subroutines.
   5) Added more in-source-comments and extended the driver description by
      some explanation about the SCSI-device-assignment problem.
   - Michael Lang
   
   Jan 18, 1998: (v3.0g)
   1) Correcting names to be absolutely conform to the later 2.1.x releases.
      This is necessary for 
            IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET
            IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD
   - Michael Lang
 
   Jan 18, 1999: (v3.1 MCA-team internal)
   1) The multiple hosts structure is accessed from every subroutine, so there
      is no longer the address of the device structure passed from function
      to function, but only the hostindex. A call by value, nothing more. This
      should really be understood by the compiler and the subsystem should get
      the right values and addresses.
   2) The SCSI-subsystem detection was not complete and quite hugely buggy up
      to now, compared to the technical manual. The interpretation of the pos2
      register is not as assumed by people before, therefore, I dropped a note
      in the ibmmca_detect function to show the registers' interpretation.
      The pos-registers of integrated SCSI-subsystems do not contain any 
      information concerning the IO-port offset, really. Instead, they contain
      some info about the adapter, the chip, the NVRAM .... The I/O-port is
      fixed to 0x3540 - 0x3547. There can be more than one adapters in the 
      slots and they get an offset for the I/O area in order to get their own
      I/O-address area. See chapter 2 for detailed description. At least, the 
      detection should now work right, even on models other than 95. The 95ers
      came happily around the bug, as their pos2 register contains always 0 
      in the critical area. Reserved bits are not allowed to be interpreted, 
      therefore, IBM is allowed to set those bits as they like and they may 
      really vary between different PS/2 models. So, now, no interpretation 
      of reserved bits - hopefully no trouble here anymore.
   3) The command error, which you may get on models 55, 56, 57, 70, 77 and
      P70 may have been caused by the fact, that adapters of older design do
      not like sending commands to non-existing SCSI-devices and will react
      with a command error as a sign of protest. While this error is not
      present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
      Adapters. Therefore, I implemented a workaround to forgive those 
      adapters their protests, but it is marked up in the statistics, so
      after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
      how often the command errors have been forgiven to the SCSI-subsystem.
      If the number is bigger than 0, you have a SCSI subsystem of older
      design, what should no longer matter.
   4) ibmmca_getinfo() has been adapted very carefully, so it shows in the 
      slotn file really, what is senseful to be presented.
   5) ibmmca_register() has been extended in its parameter list in order to
      pass the right name of the SCSI-adapter to Linux.
   - Michael Lang

   Feb 6, 1999: (v3.1)