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 sourcecode
+ no bug in the driver; it prevents you from using the wrong source code
with the wrong kernel version.
Authors of this Driver
5 Users' Manual
5.1 Commandline Parameters
5.2 Troubleshooting
- 5.3 Bugreports
+ 5.3 Bug reports
5.4 Support WWW-page
6 References
7 Credits to
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 to this file to easify the codes' readability. The driver
+ 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
- textsize a bit. At the end of this file you can find a small manual for
+ 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
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 dexribes you the handling of devices on non-F/W adapters.
+ 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.
--------------------------------------------------------
One consequence of information hiding is that the real (pun,lun)
numbers are also hidden. The two possibilities to get around this problem
- is to offer fake pun/lun combinations to the operating system or to
+ 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. a ldn is a "logical device number"
+ 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:
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 usem then it just maped ldn ->
+ 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.
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 existant, but it has no ldn assigned, it gets a 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
+ 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
+ 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
- multpile lun probing is inactive.
+ multiple lun probing is inactive.
2.4 SCSI-Device Order
---------------------
2.6 Abort & Reset Commands
--------------------------
These are implemented with busy waiting for interrupt to arrive.
- ibmmca_reset() and ibmmca_abort() do not work sufficently well
- up to now and need still a lot of development work. But, this seems
- to be even a problem with other SCSI-low level drivers, too. However,
+ 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
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, whithout confusing the SCSI-Subsystem.
+ 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
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
+ 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
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 workarround to forgive those
- adapters their protests, but it is marked up in the statisctis, so
+ 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
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
- descissive hint to move the code-part out and declare it global. Now,
- it seems to work by far much better an more stable. Let us see, what
+ 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-
- Michael Lang
Apr 23, 2000 (v3.2pre1)
- 1) During a very long time, I collected a huge amount of bugreports from
+ 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 bugreports are taken into account and should be
+ 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
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
+ 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
+ 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 midlevel-driver has to send
- a REQUEST_SENSE in order to see, where the problem is located. This
+ 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 supressed by
+ 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.
- Michael Lang
July 17, 2000 (v3.2pre8)
- A long period of collecting bugreports from all corners of the world
+ 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 disbale Fast-SCSI for the external bus.
- The feature-control command, where this crash appeared regularly tried
+ 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,
+ 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
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. Weired, but I am trying to recompile everything on
+ 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.
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, existant on all PS/2, except models 8595-XXX.
+ 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
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 tranferred by bypassing the internal command buffer of the adapter
+ 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
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 prooved to run on other adapters, however you may be lucky.
+ 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 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 I cannot find the IBM MCA SCSI support in the config menue?
+ 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 files' origin, the webaddress
+ 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
- bugreports.
+ 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
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 synchonous mode anymore after a reset, until you reboot.
+ 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
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 a Ooops message and something like "killing interrupt".
+ 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
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 weired.
+ 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
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 Bugreports
+ 5.3 Bug reports
--------------
- If you really find bugs in the sourcecode or the driver will successfully
+ 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 burried in E-Mail and Leonard is supervising all
+ 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 burried in E-mail (as me, sometimes, too) and one should first check
+ 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
- bugreports for errors in the ibmmca.c code, which I could not imagine, but
+ 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
--------------------
The address of the IBM SCSI-subsystem supporting WWW-page is:
- http://www.uni-mainz.de/~langm000/linux.html
+ 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
some e-mail directly, but at least with the same information as required by
the formular.
- If you have extensive bugreports, including Ooops messages and
+ 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:
detailed bug reports and ideas for this driver (and his
patience ;-)).
Alan J. Cox
- for his bugreports and his bold activities in cross-checking
+ for his bug reports and his bold activities in cross-checking
the driver-code with his teststand.
7.2 Sponsors & Supporters