1403 lines
76 KiB
Plaintext
1403 lines
76 KiB
Plaintext
|
|
-=< The IBM Microchannel SCSI-Subsystem >=-
|
|
|
|
for the IBM PS/2 series
|
|
|
|
Low Level Software-Driver for Linux
|
|
|
|
Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU
|
|
General Public License. Originally written by Martin Kolinek, December 1995.
|
|
Officially modified and maintained by Michael Lang since January 1999.
|
|
|
|
Version 4.0a
|
|
|
|
Last update: January 3, 2001
|
|
|
|
Before you Start
|
|
----------------
|
|
This is the common README.ibmmca file for all driver releases of the
|
|
IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0
|
|
or newer do not work with kernel versions older than 2.4.0, while driver
|
|
versions older than 4.0 do not work with kernels 2.4.0 or later! If you
|
|
try to compile your kernel with the wrong driver source, the
|
|
compilation is aborted and you get a corresponding error message. This is
|
|
no bug in the driver; it prevents you from using the wrong source code
|
|
with the wrong kernel version.
|
|
|
|
Authors of this Driver
|
|
----------------------
|
|
- Chris Beauregard (improvement of the SCSI-device mapping by the driver)
|
|
- Martin Kolinek (origin, first release of this driver)
|
|
- Klaus Kudielka (multiple SCSI-host management/detection, adaption to
|
|
Linux Kernel 2.1.x, module support)
|
|
- Michael Lang (assigning original pun/lun mapping, dynamical ldn
|
|
assignment, rewritten adapter detection, this file,
|
|
patches, official driver maintenance and subsequent
|
|
debugging, related with the driver)
|
|
|
|
Table of Contents
|
|
-----------------
|
|
1 Abstract
|
|
2 Driver Description
|
|
2.1 IBM SCSI-Subsystem Detection
|
|
2.2 Physical Units, Logical Units, and Logical Devices
|
|
2.3 SCSI-Device Recognition and dynamical ldn Assignment
|
|
2.4 SCSI-Device Order
|
|
2.5 Regular SCSI-Command-Processing
|
|
2.6 Abort & Reset Commands
|
|
2.7 Disk Geometry
|
|
2.8 Kernel Boot Option
|
|
2.9 Driver Module Support
|
|
2.10 Multiple Hostadapter Support
|
|
2.11 /proc/scsi-Filesystem Information
|
|
2.12 /proc/mca-Filesystem Information
|
|
2.13 Supported IBM SCSI-Subsystems
|
|
2.14 Linux Kernel Versions
|
|
3 Code History
|
|
4 To do
|
|
5 Users' Manual
|
|
5.1 Commandline Parameters
|
|
5.2 Troubleshooting
|
|
5.3 Bug reports
|
|
5.4 Support WWW-page
|
|
6 References
|
|
7 Credits to
|
|
7.1 People
|
|
7.2 Sponsors & Supporters
|
|
8 Trademarks
|
|
9 Disclaimer
|
|
|
|
* * *
|
|
|
|
1 Abstract
|
|
----------
|
|
This README-file describes the IBM SCSI-subsystem low level driver for
|
|
Linux. The descriptions which were formerly kept in the source code have
|
|
been taken out of this file to simplify the codes readability. The driver
|
|
description has been updated, as most of the former description was already
|
|
quite outdated. The history of the driver development is also kept inside
|
|
here. Multiple historical developments have been summarized to shorten the
|
|
text size a bit. At the end of this file you can find a small manual for
|
|
this driver and hints to get it running on your machine.
|
|
|
|
2 Driver Description
|
|
--------------------
|
|
2.1 IBM SCSI-Subsystem Detection
|
|
--------------------------------
|
|
This is done in the ibmmca_detect() function. It first checks, if the
|
|
Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the
|
|
Microchannel. In a next step, a free interrupt is chosen and the main
|
|
interrupt handler is connected to it to handle answers of the SCSI-
|
|
subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11
|
|
instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a
|
|
further step it is checked, if the adapter gets detected by force from
|
|
the kernel commandline, where the I/O port and the SCSI-subsystem id can
|
|
be specified. The next step checks if there is an integrated SCSI-subsystem
|
|
installed. This register area is fixed through all IBM PS/2 MCA-machines
|
|
and appears as something like a virtual slot 10 of the MCA-bus. On most
|
|
PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not
|
|
integrated SCSI-controller is available. But on certain PS/2s, like model
|
|
9595, this slot 10 is used to store other information which at earlier
|
|
stage confused the driver and resulted in the detection of some ghost-SCSI.
|
|
If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS
|
|
registers are either 0xff or 0x00, there must be an integrated SCSI-
|
|
subsystem present and it will be registered as IBM Integrated SCSI-
|
|
Subsystem. The next step checks, if there is a slot-adapter installed on
|
|
the MCA-bus. To get this, the first two POS-registers, that represent the
|
|
adapter ID are checked. If they fit to one of the ids, stored in the
|
|
adapter list, a SCSI-subsystem is assumed to be found in a slot and will be
|
|
registered. This check is done through all possible MCA-bus slots to allow
|
|
more than one SCSI-adapter to be present in the PS/2-system and this is
|
|
already the first point of problems. Looking into the technical reference
|
|
manual for the IBM PS/2 common interfaces, the POS2 register must have
|
|
different interpretation of its single bits to avoid overlapping I/O
|
|
regions. While one can assume, that the integrated subsystem has a fix
|
|
I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must
|
|
use a different I/O-address. This is expressed by bit 1 to 3 of POS2
|
|
(multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated
|
|
subsystem, but not for the adapters! The following list shows, how the
|
|
bits of POS2 and POS3 should be interpreted.
|
|
|
|
The POS2-register of all PS/2 models' integrated SCSI-subsystems has the
|
|
following interpretation of bits:
|
|
Bit 7 - 4 : Chip Revision ID (Release)
|
|
Bit 3 - 2 : Reserved
|
|
Bit 1 : 8k NVRAM Disabled
|
|
Bit 0 : Chip Enable (EN-Signal)
|
|
The POS3-register is interpreted as follows (for most IBM SCSI-subsys.):
|
|
Bit 7 - 5 : SCSI ID
|
|
Bit 4 - 0 : Reserved = 0
|
|
The slot-adapters have different interpretation of these bits. The IBM SCSI
|
|
adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following
|
|
interpretation of the POS2 register:
|
|
Bit 7 - 4 : ROM Segment Address Select
|
|
Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540)
|
|
Bit 0 : Adapter Enable (EN-Signal)
|
|
and for the POS3 register:
|
|
Bit 7 - 5 : SCSI ID
|
|
Bit 4 : Fairness Enable (SCSI ID3 f. F/W)
|
|
Bit 3 - 0 : Arbitration Level
|
|
The most modern product of the series is the IBM SCSI-2 F/W adapter, it
|
|
allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be
|
|
between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide
|
|
adapter PUN expression. In short words, this means, that IBM PS/2 machines
|
|
can only support 1 single integrated subsystem by default. Additional
|
|
slot-adapters get ports assigned by the automatic configuration tool.
|
|
|
|
One day I found a patch in ibmmca_detect(), forcing the I/O-address to be
|
|
0x3540 for integrated SCSI-subsystems, there was a remark placed, that on
|
|
integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5.
|
|
This means, that really for these models, POS2 has to be interpreted
|
|
sticking to the technical reference guide. In this case, the bit 2 (4) is
|
|
a reserved bit and may not be interpreted. These differences between the
|
|
adapters and the integrated controllers are taken into account by the
|
|
detection routine of the driver on from version >3.0g.
|
|
|
|
Every time, a SCSI-subsystem is discovered, the ibmmca_register() function
|
|
is called. This function checks first, if the requested area for the I/O-
|
|
address of this SCSI-subsystem is still available and assigns this I/O-
|
|
area to the SCSI-subsystem. There are always 8 sequential I/O-addresses
|
|
taken for each individual SCSI-subsystem found, which are:
|
|
|
|
Offset Type Permissions
|
|
0 Command Interface Register 1 Read/Write
|
|
1 Command Interface Register 2 Read/Write
|
|
2 Command Interface Register 3 Read/Write
|
|
3 Command Interface Register 4 Read/Write
|
|
4 Attention Register Read/Write
|
|
5 Basic Control Register Read/Write
|
|
6 Interrupt Status Register Read
|
|
7 Basic Status Register Read
|
|
|
|
After the I/O-address range is assigned, the host-adapter is assigned
|
|
to a local structure which keeps all adapter information needed for the
|
|
driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun
|
|
and the adapters' ldn tables are initialized and get probed afterwards by
|
|
the check_devices() function. If no further adapters are found,
|
|
ibmmca_detect() quits.
|
|
|
|
2.2 Physical Units, Logical Units, and Logical Devices
|
|
------------------------------------------------------
|
|
There can be up to 56 devices on the SCSI bus (besides the adapter):
|
|
there are up to 7 "physical units" (each identified by physical unit
|
|
number or pun, also called the scsi id, this is the number you select
|
|
with hardware jumpers), and each physical unit can have up to 8
|
|
"logical units" (each identified by logical unit number, or lun,
|
|
between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
|
|
busses and provides support for 30 logical devices at the same time, where
|
|
in wide-addressing mode you can have 16 puns with 32 luns on each device.
|
|
This section describes the handling of devices on non-F/W adapters.
|
|
Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
|
|
which means a lot of possible devices for such a small machine.
|
|
|
|
Typically the adapter has pun=7, so puns of other physical units
|
|
are between 0 and 6(15). On a wide-adapter a pun higher than 7 is
|
|
possible, but is normally not used. Almost all physical units have only
|
|
one logical unit, with lun=0. A CD-ROM jukebox would be an example of a
|
|
physical unit with more than one logical unit.
|
|
|
|
The embedded microprocessor of the IBM SCSI-subsystem hides the complex
|
|
two-dimensional (pun,lun) organization from the operating system.
|
|
When the machine is powered-up (or rebooted), the embedded microprocessor
|
|
checks, on its own, all 56 possible (pun,lun) combinations, and the first
|
|
15 devices found are assigned into a one-dimensional array of so-called
|
|
"logical devices", identified by "logical device numbers" or ldn. The last
|
|
ldn=15 is reserved for the subsystem itself. Wide adapters may have
|
|
to check up to 15 * 8 = 120 pun/lun combinations.
|
|
|
|
2.3 SCSI-Device Recognition and Dynamical ldn Assignment
|
|
--------------------------------------------------------
|
|
One consequence of information hiding is that the real (pun,lun)
|
|
numbers are also hidden. The two possibilities to get around this problem
|
|
are to offer fake pun/lun combinations to the operating system or to
|
|
delete the whole mapping of the adapter and to reassign the ldns, using
|
|
the immediate assign command of the SCSI-subsystem for probing through
|
|
all possible pun/lun combinations. An ldn is a "logical device number"
|
|
which is used by IBM SCSI-subsystems to access some valid SCSI-device.
|
|
At the beginning of the development of this driver, the following approach
|
|
was used:
|
|
|
|
First, the driver checked the ldn's (0 to 6) to find out which ldn's
|
|
have devices assigned. This was done by the functions check_devices() and
|
|
device_exists(). The interrupt handler has a special paragraph of code
|
|
(see local_checking_phase_flag) to assist in the checking. Assume, for
|
|
example, that three logical devices were found assigned at ldn 0, 1, 2.
|
|
These are presented to the upper layer of Linux SCSI driver
|
|
as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0).
|
|
On the other hand, if the upper layer issues a command to device
|
|
say (4,0), this driver returns DID_NO_CONNECT error.
|
|
|
|
In a second step of the driver development, the following improvement has
|
|
been applied: The first approach limited the number of devices to 7, far
|
|
fewer than the 15 that it could use, then it just mapped ldn ->
|
|
(ldn/8,ldn%8) for pun,lun. We ended up with a real mishmash of puns
|
|
and luns, but it all seemed to work.
|
|
|
|
The latest development, which is implemented from the driver version 3.0
|
|
and later, realizes the device recognition in the following way:
|
|
The physical SCSI-devices on the SCSI-bus are probed via immediate_assign-
|
|
and device_inquiry-commands, that is all implemented in a completely new
|
|
made check_devices() subroutine. This delivers an exact map of the physical
|
|
SCSI-world that is now stored in the get_scsi[][]-array. This means,
|
|
that the once hidden pun,lun assignment is now known to this driver.
|
|
It no longer believes in default-settings of the subsystem and maps all
|
|
ldns to existing pun,lun "by foot". This assures full control of the ldn
|
|
mapping and allows dynamical remapping of ldns to different pun,lun, if
|
|
there are more SCSI-devices installed than ldns available (n>15). The
|
|
ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0,
|
|
excluding the pun of the subsystem. This assures, that at least simple
|
|
SCSI-installations have optimum access-speed and are not touched by
|
|
dynamical remapping. The ldns 7 to 14 are put to existing devices with
|
|
lun>0 or to non-existing devices, in order to satisfy the subsystem, if
|
|
there are less than 15 SCSI-devices connected. In the case of more than 15
|
|
devices, the dynamical mapping goes active. If the get_scsi[][] reports a
|
|
device to be existent, but it has no ldn assigned, it gets an ldn out of 7
|
|
to 14. The numbers are assigned in cyclic order, therefore it takes 8
|
|
dynamical reassignments on the SCSI-devices until a certain device
|
|
loses its ldn again. This assures that dynamical remapping is avoided
|
|
during intense I/O between up to 15 SCSI-devices (means pun,lun
|
|
combinations). A further advantage of this method is that people who
|
|
build their kernel without probing on all luns will get what they expect,
|
|
because the driver just won't assign everything with lun>0 when
|
|
multiple lun probing is inactive.
|
|
|
|
2.4 SCSI-Device Order
|
|
---------------------
|
|
Because of the now correct recognition of physical pun,lun, and
|
|
their report to mid-level- and higher-level-drivers, the new reported puns
|
|
can be different from the old, faked puns. Therefore, Linux will eventually
|
|
change /dev/sdXXX assignments and prompt you for corrupted superblock
|
|
repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!!
|
|
You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file
|
|
entries right. After that, the system should come up as errorfree as before.
|
|
If your boot-partition is not coming up, also edit the /etc/lilo.conf-file
|
|
in a Linux session booted on old kernel and run lilo before reboot. Check
|
|
lilo.conf anyway to get boot on other partitions with foreign OSes right
|
|
again. But there exists a feature of this driver that allows you to change
|
|
the assignment order of the SCSI-devices by flipping the PUN-assignment.
|
|
See the next paragraph for a description.
|
|
|
|
The problem for this is, that Linux does not assign the SCSI-devices in the
|
|
way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to
|
|
the device with at minimum id 0. But the first drive should be at id 6,
|
|
because for historical reasons, drive at id 6 has, by hardware, the highest
|
|
priority and a drive at id 0 the lowest. IBM was one of the rare producers,
|
|
where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most
|
|
other producers' BIOS does not (I think even Adaptec-BIOS). The
|
|
IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the
|
|
kernel enables to choose the preferred way of SCSI-device-assignment.
|
|
Defining this flag would result in Linux determining the devices in the
|
|
same order as DOS and OS/2 does on your MCA-machine. This is also standard
|
|
on most industrial computers and OSes, like e.g. OS-9. Leaving this flag
|
|
undefined will get your devices ordered in the default way of Linux. See
|
|
also the remarks of Chris Beauregard from Dec 15, 1997 and the followups
|
|
in section 3.
|
|
|
|
2.5 Regular SCSI-Command-Processing
|
|
-----------------------------------
|
|
Only three functions get involved: ibmmca_queuecommand(), issue_cmd(),
|
|
and interrupt_handler().
|
|
|
|
The upper layer issues a scsi command by calling function
|
|
ibmmca_queuecommand(). This function fills a "subsystem control block"
|
|
(scb) and calls a local function issue_cmd(), which writes a scb
|
|
command into subsystem I/O ports. Once the scb command is carried out,
|
|
the interrupt_handler() is invoked. If a device is determined to be
|
|
existant and it has not assigned any ldn, it gets one dynamically.
|
|
For this, the whole stuff is done in ibmmca_queuecommand().
|
|
|
|
2.6 Abort & Reset Commands
|
|
--------------------------
|
|
These are implemented with busy waiting for interrupt to arrive.
|
|
ibmmca_reset() and ibmmca_abort() do not work sufficiently well
|
|
up to now and need still a lot of development work. This seems
|
|
to be a problem with other low-level SCSI drivers too, however
|
|
this should be no excuse.
|
|
|
|
2.7 Disk Geometry
|
|
-----------------
|
|
The ibmmca_biosparams() function should return the same disk geometry
|
|
as the bios. This is needed for fdisk, etc. The returned geometry is
|
|
certainly correct for disks smaller than 1 gigabyte. In the meantime,
|
|
it has been proved, that this works fine even with disks larger than
|
|
1 gigabyte.
|
|
|
|
2.8 Kernel Boot Option
|
|
----------------------
|
|
The function ibmmca_scsi_setup() is called if option ibmmcascsi=n
|
|
is passed to the kernel. See file linux/init/main.c for details.
|
|
|
|
2.9 Driver Module Support
|
|
-------------------------
|
|
Is implemented and tested by K. Kudielka. This could probably not work
|
|
on kernels <2.1.0.
|
|
|
|
2.10 Multiple Hostadapter Support
|
|
---------------------------------
|
|
This driver supports up to eight interfaces of type IBM-SCSI-Subsystem.
|
|
Integrated-, and MCA-adapters are automatically recognized. Unrecognizable
|
|
IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters.
|
|
|
|
2.11 /proc/scsi-Filesystem Information
|
|
--------------------------------------
|
|
Information about the driver condition is given in
|
|
/proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information.
|
|
|
|
This table is quite informative for interested users. It shows the load
|
|
of commands on the subsystem and whether you are running the bypassed
|
|
(software) or integrated (hardware) SCSI-command set (see below). The
|
|
amount of accesses is shown. Read, write, modeselect is shown separately
|
|
in order to help debugging problems with CD-ROMs or tapedrives.
|
|
|
|
The following table shows the list of 15 logical device numbers, that are
|
|
used by the SCSI-subsystem. The load on each ldn is shown in the table,
|
|
again, read and write commands are split. The last column shows the amount
|
|
of reassignments, that have been applied to the ldns, if you have more than
|
|
15 pun/lun combinations available on the SCSI-bus.
|
|
|
|
The last two tables show the pun/lun map and the positions of the ldns
|
|
on this pun/lun map. This may change during operation, when a ldn is
|
|
reassigned to another pun/lun combination. If the necessity for dynamical
|
|
assignments is set to 'no', the ldn structure keeps static.
|
|
|
|
2.12 /proc/mca-Filesystem Information
|
|
-------------------------------------
|
|
The slot-file contains all default entries and in addition chip and I/O-
|
|
address information of the SCSI-subsystem. This information is provided
|
|
by ibmmca_getinfo().
|
|
|
|
2.13 Supported IBM SCSI-Subsystems
|
|
----------------------------------
|
|
The following IBM SCSI-subsystems are supported by this driver:
|
|
|
|
- IBM Fast/Wide SCSI-2 Adapter
|
|
- IBM 7568 Industrial Computer SCSI Adapter w/Cache
|
|
- IBM Expansion Unit SCSI Controller
|
|
- IBM SCSI Adapter w/Cache
|
|
- IBM SCSI Adapter
|
|
- IBM Integrated SCSI Controller
|
|
- All clones, 100% compatible with the chipset and subsystem command
|
|
system of IBM SCSI-adapters (forced detection)
|
|
|
|
2.14 Linux Kernel Versions
|
|
--------------------------
|
|
The IBM SCSI-subsystem low level driver is prepared to be used with
|
|
all versions of Linux between 2.0.x and 2.4.x. The compatibility checks
|
|
are fully implemented up from version 3.1e of the driver. This means, that
|
|
you just need the latest ibmmca.h and ibmmca.c file and copy it in the
|
|
linux/drivers/scsi directory. The code is automatically adapted during
|
|
kernel compilation. This is different from kernel 2.4.0! Here version
|
|
4.0 or later of the driver must be used for kernel 2.4.0 or later. Version
|
|
4.0 or later does not work together with older kernels! Driver versions
|
|
older than 4.0 do not work together with kernel 2.4.0 or later. They work
|
|
on all older kernels.
|
|
|
|
3 Code History
|
|
--------------
|
|
Jan 15 1996: First public release.
|
|
- Martin Kolinek
|
|
|
|
Jan 23 1996: Scrapped code which reassigned scsi devices to logical
|
|
device numbers. Instead, the existing assignment (created
|
|
when the machine is powered-up or rebooted) is used.
|
|
A side effect is that the upper layer of Linux SCSI
|
|
device driver gets bogus scsi ids (this is benign),
|
|
and also the hard disks are ordered under Linux the
|
|
same way as they are under dos (i.e., C: disk is sda,
|
|
D: disk is sdb, etc.).
|
|
- Martin Kolinek
|
|
|
|
I think that the CD-ROM is now detected only if a CD is
|
|
inside CD_ROM while Linux boots. This can be fixed later,
|
|
once the driver works on all types of PS/2's.
|
|
- Martin Kolinek
|
|
|
|
Feb 7 1996: Modified biosparam function. Fixed the CD-ROM detection.
|
|
For now, devices other than harddisk and CD_ROM are
|
|
ignored. Temporarily modified abort() function
|
|
to behave like reset().
|
|
- Martin Kolinek
|
|
|
|
Mar 31 1996: The integrated scsi subsystem is correctly found
|
|
in PS/2 models 56,57, but not in model 76. Therefore
|
|
the ibmmca_scsi_setup() function has been added today.
|
|
This function allows the user to force detection of
|
|
scsi subsystem. The kernel option has format
|
|
ibmmcascsi=n
|
|
where n is the scsi_id (pun) of the subsystem. Most likely, n is 7.
|
|
- Martin Kolinek
|
|
|
|
Aug 21 1996: Modified the code which maps ldns to (pun,0). It was
|
|
insufficient for those of us with CD-ROM changers.
|
|
- Chris Beauregard
|
|
|
|
Dec 14 1996: More improvements to the ldn mapping. See check_devices
|
|
for details. Did more fiddling with the integrated SCSI detection,
|
|
but I think it's ultimately hopeless without actually testing the
|
|
model of the machine. The 56, 57, 76 and 95 (ultimedia) all have
|
|
different integrated SCSI register configurations. However, the 56
|
|
and 57 are the only ones that have problems with forced detection.
|
|
- Chris Beauregard
|
|
|
|
Mar 8-16 1997: Modified driver to run as a module and to support
|
|
multiple adapters. A structure, called ibmmca_hostdata, is now
|
|
present, containing all the variables, that were once only
|
|
available for one single adapter. The find_subsystem-routine has vanished.
|
|
The hardware recognition is now done in ibmmca_detect directly.
|
|
This routine checks for presence of MCA-bus, checks the interrupt
|
|
level and continues with checking the installed hardware.
|
|
Certain PS/2-models do not recognize a SCSI-subsystem automatically.
|
|
Hence, the setup defined by command-line-parameters is checked first.
|
|
Thereafter, the routine probes for an integrated SCSI-subsystem.
|
|
Finally, adapters are checked. This method has the advantage to cover all
|
|
possible combinations of multiple SCSI-subsystems on one MCA-board. Up to
|
|
eight SCSI-subsystems can be recognized and announced to the upper-level
|
|
drivers with this improvement. A set of defines made changes to other
|
|
routines as small as possible.
|
|
- Klaus Kudielka
|
|
|
|
May 30 1997: (v1.5b)
|
|
1) SCSI-command capability enlarged by the recognition of MODE_SELECT.
|
|
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
|
|
allows data to be written from the system to the device. It is a
|
|
necessary step to be allowed to set blocksize of SCSI-tape-drives and
|
|
the tape-speed, without confusing the SCSI-Subsystem.
|
|
2) The recognition of a tape is included in the check_devices routine.
|
|
This is done by checking for TYPE_TAPE, that is already defined in
|
|
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 cosmetic 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
|
|
- chrisb@truespectra.com
|
|
- 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)
|
|
1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for
|
|
the delayed release, but it was not finished with the release of
|
|
Kernel 2.2.0.
|
|
- Michael Lang
|
|
|
|
Feb 10, 1999 (v3.1)
|
|
1) Added a new commandline parameter called 'bypass' in order to bypass
|
|
every integrated subsystem SCSI-command consequently in case of
|
|
troubles.
|
|
2) Concatenated read_capacity requests to the harddisks. It gave a lot
|
|
of troubles with some controllers and after I wanted to apply some
|
|
extensions, it jumped out in the same situation, on my w/cache, as like
|
|
on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
|
|
decisive hint to move the code-part out and declare it global. Now
|
|
it seems to work far better and more stable. Let us see what
|
|
the world thinks of it...
|
|
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
|
|
test with a HP drive gave right results, so the problem is vendor-
|
|
specific and not a problem of the OS or the driver.
|
|
- Michael Lang
|
|
|
|
Feb 18, 1999 (v3.1d)
|
|
1) The abort command and the reset function have been checked for
|
|
inconsistencies. From the logical point of thinking, they work
|
|
at their optimum, now, but as the subsystem does not answer with an
|
|
interrupt, abort never finishes, sigh...
|
|
2) Everything, that is accessed by a busmaster request from the adapter
|
|
is now declared as global variable, even the return-buffer in the
|
|
local checking phase. This assures, that no accesses to undefined memory
|
|
areas are performed.
|
|
3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to
|
|
avoid memory-pointers for the areas higher than 16MByte in order to
|
|
be sure, it also works on 16-Bit Microchannel bus systems.
|
|
4) A lot of small things have been found, but nothing that endangered the
|
|
driver operations. Just it should be more stable, now.
|
|
- Michael Lang
|
|
|
|
Feb 20, 1999 (v3.1e)
|
|
1) I took the warning from the Linux Kernel Hackers Guide serious and
|
|
checked the cmd->result return value to the done-function very carefully.
|
|
It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if
|
|
some error appeared, else it is undefined. Now, this is fixed. Before
|
|
any SCB command gets queued, the tsb.dev_status is set to 0, so the
|
|
cmd->result won't screw up Linux higher level drivers.
|
|
2) The reset-function has slightly improved. This is still planed for
|
|
abort. During the abort and the reset function, no interrupts are
|
|
allowed. This is however quite hard to cope with, so the INT-status
|
|
register is read. When the interrupt gets queued, one can find its
|
|
status immediately on that register and is enabled to continue in the
|
|
reset function. I had no chance to test this really, only in a bogus
|
|
situation, I got this function running, but the situation was too much
|
|
worse for Linux :-(, so tests will continue.
|
|
3) Buffers got now consistent. No open address mapping, as before and
|
|
therefore no further troubles with the unassigned memory segmentation
|
|
faults that scrambled probes on 95XX series and even on 85XX series,
|
|
when the kernel is done in a not so perfectly fitting way.
|
|
4) Spontaneous interrupts from the subsystem, appearing without any
|
|
command previously queued are answered with a DID_BAD_INTR result.
|
|
5) Taken into account ZP Gus' proposals to reverse the SCSI-device
|
|
scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed
|
|
by him, I implemented it in a slightly derived way, which offers in
|
|
addition more flexibility.
|
|
- Michael Lang
|
|
|
|
Apr 23, 2000 (v3.2pre1)
|
|
1) During a very long time, I collected a huge amount of bug reports from
|
|
various people, trying really quite different things on their SCSI-
|
|
PS/2s. Today, all these bug reports are taken into account and should be
|
|
mostly solved. The major topics were:
|
|
- Driver crashes during boottime by no obvious reason.
|
|
- Driver panics while the midlevel-SCSI-driver is trying to inquire
|
|
the SCSI-device properties, even though hardware is in perfect state.
|
|
- Displayed info for the various slot-cards is interpreted wrong.
|
|
The main reasons for the crashes were two:
|
|
1) The commands to check for device information like INQUIRY,
|
|
TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices
|
|
to deliver information of up to 255 bytes. Midlevel drivers offer
|
|
1024 bytes of space for the answer, but the IBM-SCSI-adapters do
|
|
not accept this, as they stick quite near to ANSI-SCSI and report
|
|
a COMMAND_ERROR message which causes the driver to panic. The main
|
|
problem was located around the INQUIRY command. Now, for all the
|
|
mentioned commands, the buffersize sent to the adapter is at
|
|
maximum 255 which seems to be a quite reasonable solution.
|
|
TEST_UNIT_READY gets a buffersize of 0 to make sure that no
|
|
data is transferred in order to avoid any possible command failure.
|
|
2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
|
|
a REQUEST_SENSE in order to see where the problem is located. This
|
|
REQUEST_SENSE may have various length in its answer-buffer. IBM
|
|
SCSI-subsystems report a command failure if the returned buffersize
|
|
is different from the sent buffersize, but this can be suppressed by
|
|
a special bit, which is now done and problems seem to be solved.
|
|
2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on
|
|
2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
|
|
3) Commandline-parameters are recognized again, even under Kernel 2.3.x or
|
|
higher.
|
|
- Michael Lang
|
|
|
|
April 27, 2000 (v3.2pre2)
|
|
1) Bypassed commands get read by the adapter by one cycle instead of two.
|
|
This increases SCSI-performance.
|
|
2) Synchronous datatransfer is provided for sure to be 5 MHz on older
|
|
SCSI and 10 MHz on internal F/W SCSI-adapter.
|
|
3) New commandline parameters allow to force the adapter to slow down while
|
|
in synchronous transfer. Could be helpful for very old devices.
|
|
- Michael Lang
|
|
|
|
June 2, 2000 (v3.2pre5)
|
|
1) Added Jim Shorney's contribution to make the activity indicator
|
|
flashing in addition to the LED-alphanumeric display-panel on
|
|
models 95A. To be enabled to choose this feature freely, a new
|
|
commandline parameter is added, called 'activity'.
|
|
2) Added the READ_CONTROL bit for test_unit_ready SCSI-command.
|
|
3) Added some suppress_exception bits to read_device_capacity and
|
|
all device_inquiry occurrences in the driver code.
|
|
4) Complaints about the various KERNEL_VERSION implementations are
|
|
taken into account. Every local_LinuxKernelVersion occurrence is
|
|
now replaced by KERNEL_VERSION, defined in linux/version.h.
|
|
Corresponding changes were applied to ibmmca.h, too. This was a
|
|
contribution to all kernel-parts by Philipp Hahn.
|
|
- Michael Lang
|
|
|
|
July 17, 2000 (v3.2pre8)
|
|
A long period of collecting bug reports from all corners of the world
|
|
now lead to the following corrections to the code:
|
|
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
|
was that it is possible to disable Fast-SCSI for the external bus.
|
|
The feature-control command, where this crash appeared regularly, tried
|
|
to set the maximum speed of 10MHz synchronous transfer speed and that
|
|
reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
|
|
the feature-command probes down from maximum speed until the adapter
|
|
stops to complain, which is at the same time the maximum possible
|
|
speed selected in the reference program. So, F/W external can run at
|
|
5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the
|
|
COMMAND ERROR message is used to detect if the adapter does not complain.
|
|
2) Up to now, only combined busmode is supported, if you use external
|
|
SCSI-devices, attached to the F/W-controller. If dual bus is selected,
|
|
only the internal SCSI-devices get accessed by Linux. For most
|
|
applications, this should do fine.
|
|
3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W
|
|
bus on the F/W adapter. If F/W adapter is detected, the driver
|
|
automatically uses the extended PUN/LUN <-> LDN mapping tables, which
|
|
are now new from 3.2pre8. This allows PUNs between 0 and 15 and should
|
|
provide more fun with the F/W adapter.
|
|
4) Several machines use the SCSI: POS registers for internal/undocumented
|
|
storage of system relevant info. This confused the driver, mainly on
|
|
models 9595, as it expected no onboard SCSI only, if all POS in
|
|
the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism
|
|
to check for integrated SCSI is much more restrictive and these problems
|
|
should be history.
|
|
- Michael Lang
|
|
|
|
July 18, 2000 (v3.2pre9)
|
|
This develop rather quickly at the moment. Two major things were still
|
|
missing in 3.2pre8:
|
|
1) The adapter PUN for F/W adapters has 4-bits, while all other adapters
|
|
have 3-bits. This is now taken into account for F/W.
|
|
2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should
|
|
normally get the inverse probing order of your devices on the SCSI-bus.
|
|
The ANSI device order gets scrambled in version 3.2pre8!! Now, a new
|
|
and tested algorithm inverts the device-order on the SCSI-bus and
|
|
automatically avoids accidental access to whatever SCSI PUN the adapter
|
|
is set and works with SCSI- and Wide-SCSI-addressing.
|
|
- Michael Lang
|
|
|
|
July 23, 2000 (v3.2pre10 unpublished)
|
|
1) LED panel display supports wide-addressing in ibmmca=display mode.
|
|
2) Adapter-information and autoadaption to address-space is done.
|
|
3) Auto-probing for maximum synchronous SCSI transfer rate is working.
|
|
4) Optimization to some embedded function calls is applied.
|
|
5) Added some comment for the user to wait for SCSI-devices being probed.
|
|
6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but...
|
|
- Michael Lang
|
|
|
|
July 26, 2000 (v3.2pre11)
|
|
1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
|
|
a model 9595. Asking around in the community, nobody except of me has
|
|
seen such errors. Weird, but I am trying to recompile everything on
|
|
the model 9595. Maybe, as I use a specially modified gcc, that could
|
|
cause problems. But, it was not the reason. The true background was,
|
|
that the kernel was compiled for i386 and the 9595 has a 486DX-2.
|
|
Normally, no troubles should appear, but for this special machine,
|
|
only the right processor support is working fine!
|
|
2) Previous problems with synchronous speed, slowing down from one adapter
|
|
to the next during probing are corrected. Now, local variables store
|
|
the synchronous bitmask for every single adapter found on the MCA bus.
|
|
3) LED alphanumeric panel support for XX95 systems is now showing some
|
|
alive rotator during boottime. This makes sense, when no monitor is
|
|
connected to the system. You can get rid of all display activity, if
|
|
you do not use any parameter or just ibmmcascsi=activity, for the
|
|
harddrive activity LED, existent on all PS/2, except models 8595-XXX.
|
|
If no monitor is available, please use ibmmcascsi=display, which works
|
|
fine together with the linuxinfo utility for the LED-panel.
|
|
- Michael Lang
|
|
|
|
July 29, 2000 (v3.2)
|
|
1) Submission of this driver for kernel 2.4test-XX and 2.2.17.
|
|
- Michael Lang
|
|
|
|
December 28, 2000 (v3.2d / v4.0)
|
|
1) The interrupt handler had some wrong statement to wait for. This
|
|
was done due to experimental reasons during 3.2 development but it
|
|
has shown that this is not stable enough. Going back to wait for the
|
|
adapter to be not busy is best.
|
|
2) Inquiry requests can be shorter than 255 bytes of return buffer. Due
|
|
to a bug in the ibmmca_queuecommand routine, this buffer was forced
|
|
to 255 at minimum. If the memory address, this return buffer is pointing
|
|
to does not offer more space, invalid memory accesses destabilized the
|
|
kernel.
|
|
3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary
|
|
to remove old kernel version dependent waste from the driver. 3.2d is
|
|
only distributed with older kernels but keeps compatibility with older
|
|
kernel versions. 4.0 and higher versions cannot be used with older
|
|
kernels anymore!! You must have at least kernel 2.4.0!!
|
|
4) The commandline argument 'bypass' and all its functionality got removed
|
|
in version 4.0. This was never really necessary, as all troubles were
|
|
based on non-command related reasons up to now, so bypassing commands
|
|
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
|
|
5) Dynamic reassignment of ldns was again verified and analyzed to be
|
|
completely inoperational. This is corrected and should work now.
|
|
6) All commands that get sent to the SCSI adapter were verified and
|
|
completed in such a way, that they are now completely conform to the
|
|
demands in the technical description of IBM. Main candidates were the
|
|
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
|
|
be transferred by bypassing the internal command buffer of the adapter
|
|
or else the response can be a random result. GET_POS_INFO would be more
|
|
safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
|
|
is not allowed by the technical references of IBM. (Sorry, folks, the
|
|
model 80 problem is still a task to be solved in a different way.)
|
|
7) v3.2d is still hold back for some days for testing, while 4.0 is
|
|
released.
|
|
- Michael Lang
|
|
|
|
January 3, 2001 (v4.0a)
|
|
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 running.
|
|
Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs.
|
|
A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter
|
|
was in such a case recognized as integrated SCSI-adapter or something
|
|
else, but not as the correct adapter. As the I/O-ports get assigned
|
|
wrongly by that reason, the system should crash in most cases. You
|
|
should upgrade to the latest release of the SCSI-driver. The
|
|
recommended version is 3.2 or later. Here, the F/W support is in
|
|
a stable and reliable condition. Wide-addressing is in addition
|
|
supported.
|
|
Q: I get an Oops message and something like "killing interrupt".
|
|
A: The reason for this is that the IBM SCSI-subsystem only sends a
|
|
termination status back, if some error appeared. In former releases
|
|
of the driver, it was not checked, if the termination status block
|
|
is NULL. From version 3.2, it is taken care of this.
|
|
Q: I have a F/W adapter and the driver sees my internal SCSI-devices,
|
|
but ignores the external ones.
|
|
A: Select combined busmode in the IBM config-program and check for that
|
|
no SCSI-id on the external devices appears on internal devices.
|
|
Reboot afterwards. Dual busmode is supported, but works only for the
|
|
internal bus, yet. External bus is still ignored. Take care for your
|
|
SCSI-ids. If combined bus-mode is activated, on some adapters,
|
|
the wide-addressing is not possible, so devices with ids between 8
|
|
and 15 get ignored by the driver & adapter!
|
|
Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck.
|
|
A COMMAND ERROR is reported and characters on the screen are missing.
|
|
Warm reboot is not possible. Things look like quite weird.
|
|
A: Check the processor type of your 9595. If you have an 80486 or 486DX-2
|
|
processor complex on your mainboard and you compiled a kernel that
|
|
supports 80386 processors, it is possible, that the kernel cannot
|
|
keep track of the PS/2 interrupt handling and stops on an NMI. Just
|
|
compile a kernel for the correct processor type of your PS/2 and
|
|
everything should be fine. This is necessary even if one assumes,
|
|
that some 80486 system should be downward compatible to 80386
|
|
software.
|
|
Q: Some commands hang and interrupts block the machine. After some
|
|
timeout, the syslog reports that it tries to call abort, but the
|
|
machine is frozen.
|
|
A: This can be a busy wait bug in the interrupt handler of driver
|
|
version 3.2. You should at least upgrade to 3.2c if you use
|
|
kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or
|
|
later (including all test releases).
|
|
Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver
|
|
completely refuses to work, reports NMIs, COMMAND ERRORs or other
|
|
ambiguous stuff. When reducing the RAM size down below 16 MB,
|
|
everything is running smoothly.
|
|
A: No real answer, yet. In any case, one should force the kernel to
|
|
present SCBs only below the 16 MBytes barrier. Maybe this solves the
|
|
problem. Not yet tried, but guessing that it could work. To get this,
|
|
set unchecked_isa_dma argument of ibmmca.h from 0 to 1.
|
|
|
|
5.3 Bug reports
|
|
--------------
|
|
If you really find bugs in the source code or the driver will successfully
|
|
refuse to work on your machine, you should send a bug report to me. The
|
|
best for this is to follow the instructions on the WWW-page for this
|
|
driver. Fill out the bug-report form, placed on the WWW-page and ship it,
|
|
so the bugs can be taken into account with maximum efforts. But, please
|
|
do not send bug reports about this driver to Linus Torvalds or Leonard
|
|
Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all
|
|
SCSI-drivers and won't have the time left to look inside every single
|
|
driver to fix a bug and especially DO NOT send modified code to Linus
|
|
Torvalds or Alan J. Cox which has not been checked here!!! They are both
|
|
quite buried in E-mail (as me, sometimes, too) and one should first check
|
|
for problems on my local teststand. Recently, I got a lot of
|
|
bug reports for errors in the ibmmca.c code, which I could not imagine, but
|
|
a look inside some Linux-distribution showed me quite often some modified
|
|
code, which did no longer work on most other machines than the one of the
|
|
modifier. Ok, so now that there is maintenance service available for this
|
|
driver, please use this address first in order to keep the level of
|
|
confusion low. Thank you!
|
|
|
|
When you get a SCSI-error message that panics your system, a list of
|
|
register-entries of the SCSI-subsystem is shown (from Version 3.1d). With
|
|
this list, it is very easy for the maintainer to localize the problem in
|
|
the driver or in the configuration of the user. Please write down all the
|
|
values from this report and send them to the maintainer. This would really
|
|
help a lot and makes life easier concerning misunderstandings.
|
|
|
|
Use the bug-report form (see 5.4 for its address) to send all the bug-
|
|
stuff to the maintainer or write e-mail with the values from the table.
|
|
|
|
5.4 Support WWW-page
|
|
--------------------
|
|
The address of the IBM SCSI-subsystem supporting WWW-page is:
|
|
|
|
http://www.staff.uni-mainz.de/mlang/linux.html
|
|
|
|
Here you can find info about the background of this driver, patches,
|
|
troubleshooting support, news and a bugreport form. Please check that
|
|
WWW-page regularly for latest hints. If ever this URL changes, please
|
|
refer to the MAINTAINERS file in order to get the latest address.
|
|
|
|
For the bugreport, please fill out the formular on the corresponding
|
|
WWW-page. Read the dedicated instructions and write as much as you
|
|
know about your problem. If you do not like such formulars, please send
|
|
some e-mail directly, but at least with the same information as required by
|
|
the formular.
|
|
|
|
If you have extensive bug reports, including Oops messages and
|
|
screen-shots, please feel free to send it directly to the address
|
|
of the maintainer, too. The current address of the maintainer is:
|
|
|
|
Michael Lang <langa2@kph.uni-mainz.de>
|
|
|
|
6 References
|
|
------------
|
|
IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference,
|
|
Common Interfaces", Armonk, September 1991, PN 04G3281,
|
|
(available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for
|
|
around 40,-DM at "Hallo IBM").
|
|
|
|
IBM Corp., "Personal System/2 Micro Channel SCSI
|
|
Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365.
|
|
|
|
IBM Corp., "Personal System/2 Micro Channel SCSI
|
|
Adapter Technical Reference", Armonk, March 1990, PN 68X2397.
|
|
|
|
IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus",
|
|
Armonk, March 1994, PN 83G7545.
|
|
|
|
Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie-
|
|
Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl.
|
|
Addison Wesley, 1996.
|
|
|
|
Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel
|
|
Hill - North Carolina, 1995
|
|
|
|
Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart
|
|
1993
|
|
|
|
Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme *
|
|
Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988
|
|
|
|
7 Credits to
|
|
------------
|
|
7.1 People
|
|
----------
|
|
Klaus Grimm
|
|
who already a long time ago gave me the old code from the
|
|
SCSI-driver in order to get it running for some old machine
|
|
in our institute.
|
|
Martin Kolinek
|
|
who wrote the first release of the IBM SCSI-subsystem driver.
|
|
Chris Beauregard
|
|
who for a long time maintained MCA-Linux and the SCSI-driver
|
|
in the beginning. Chris, wherever you are: Cheers to you!
|
|
Klaus Kudielka
|
|
with whom in the 2.1.x times, I had a quite fruitful
|
|
cooperation to get the driver running as a module and to get
|
|
it running with multiple SCSI-adapters.
|
|
David Weinehall
|
|
for his excellent maintenance of the MCA-stuff and the quite
|
|
detailed bug reports and ideas for this driver (and his
|
|
patience ;-)).
|
|
Alan J. Cox
|
|
for his bug reports and his bold activities in cross-checking
|
|
the driver-code with his teststand.
|
|
|
|
7.2 Sponsors & Supporters
|
|
-------------------------
|
|
"Hallo IBM",
|
|
IBM-Deutschland GmbH
|
|
the service of IBM-Deutschland for customers. Their E-Mail
|
|
service is unbeatable. Whatever old stuff I asked for, I
|
|
always got some helpful answers.
|
|
Karl-Otto Reimers,
|
|
IBM Klub - Sparte IBM Geschichte, Sindelfingen
|
|
for sending me a copy of the w/Cache manual from the
|
|
IBM-Deutschland archives.
|
|
Harald Staiger
|
|
for his extensive hardware donations which allows me today
|
|
still to test the driver in various constellations.
|
|
Erich Fritscher
|
|
for his very kind sponsoring.
|
|
Louis Ohland,
|
|
Charles Lasitter
|
|
for support by shipping me an IBM SCSI-2 Fast/Wide manual.
|
|
In addition, the contribution of various hardware is quite
|
|
decessive and will make it possible to add FWSR (RAID)
|
|
adapter support to the driver in the near future! So,
|
|
complaints about no RAID support won't remain forever.
|
|
Yes, folks, that is no joke, RAID support is going to rise!
|
|
Erik Weber
|
|
for the great deal we made about a model 9595 and the nice
|
|
surrounding equipment and the cool trip to Mannheim
|
|
second-hand computer market. In addition, I would like
|
|
to thank him for his exhaustive SCSI-driver testing on his
|
|
95er PS/2 park.
|
|
Anthony Hogbin
|
|
for his direct shipment of a SCSI F/W adapter, which allowed
|
|
me immediately on the first stage to try it on model 8557
|
|
together with onboard SCSI adapter and some SCSI w/Cache.
|
|
Andreas Hotz
|
|
for his support by memory and an IBM SCSI-adapter. Collecting
|
|
all this together now allows me to try really things with
|
|
the driver at maximum load and variety on various models in
|
|
a very quick and efficient way.
|
|
Peter Jennewein
|
|
for his model 30, which serves me as part of my teststand
|
|
and his cool remark about how you make an ordinary diskette
|
|
drive working and how to connect it to an IBM-diskette port.
|
|
Johannes Gutenberg-Universitaet, Mainz &
|
|
Institut fuer Kernphysik, Mainz Microtron (MAMI)
|
|
for the offered space, the link, placed on the central
|
|
homepage and the space to store and offer the driver and
|
|
related material and the free working times, which allow
|
|
me to answer all your e-mail.
|
|
|
|
8 Trademarks
|
|
------------
|
|
IBM, PS/2, OS/2, Microchannel are registered trademarks of International
|
|
Business Machines Corporation
|
|
|
|
MS-DOS is a registered trademark of Microsoft Corporation
|
|
|
|
Microware, OS-9 are registered trademarks of Microware Systems
|
|
|
|
9 Disclaimer
|
|
------------
|
|
Beside the GNU General Public License and the dependent disclaimers and disclaimers
|
|
concerning the Linux-kernel in special, this SCSI-driver comes without any
|
|
warranty. Its functionality is tested as good as possible on certain
|
|
machines and combinations of computer hardware, which does not exclude,
|
|
that data loss or severe damage of hardware is possible while using this
|
|
part of software on some arbitrary computer hardware or in combination
|
|
with other software packages. It is highly recommended to make backup
|
|
copies of your data before using this software. Furthermore, personal
|
|
injuries by hardware defects, that could be caused by this SCSI-driver are
|
|
not excluded and it is highly recommended to handle this driver with a
|
|
maximum of carefulness.
|
|
|
|
This driver supports hardware, produced by International Business Machines
|
|
Corporation (IBM).
|
|
|
|
------
|
|
Michael Lang
|
|
(langa2@kph.uni-mainz.de)
|