SCSI Tools for Debian notes
---------------------------

scsiinfo:
---------
Comes both with text interface and advanced X interface. Textmode usage
with "scsiinfo". X-Startup with "scsi-config", but you must have wish
installed to make it work.

  -- Christoph Lameter <clameter@debian.org>

scsitools is a fork of hwtools previously maintained by Christoph Lameter
(in 1996-1997) & Josip Rodin and Robert Woodcock acting on behalf of the
Debian QA Team (in 1999). It was needed to open the SCSI tools provided by
hwtools to other Debian architectures than i386 (in effect, hwtools is a
collection of tools mainly designed for i386).

scsidev & /dev/scsi:
--------------------
/dev/scsi directory is now supported on 2.2 kernels through a set of init
scripts.  Even the root partition could use /dev/scsi notation but the kernel
should support ramdisk compiled in this case.
Populating /dev/scsi is done in 2 steps:
 1. in S09scsitools-pre.sh, before remounting / rw, a ramdisk is set up,
    mounted on /dev/scsi and filled in according to /etc/scsi.alias.
    This way, further references to /dev/scsi could be made, even for root
    and swap partitions.
 2. in S20scsitools.sh, the ramdisk is freed and the real /dev/scsi refilled
    accordingly.

If you switch on a SCSI device after the boot up sequence, you can run
  /etc/init.d/scsitools.sh restart
to rescan the SCSI chain.  It uses the rescan-scsi-bus script which is
based on add-single-device feature of the Linux SCSI driver.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
CAUTION: This is not for hotplugging your peripherals. As SCSI was not designed
for this you could damage your hardware!
However perhaps it is legal to switch on an already connected device. It is
perhaps not guaranteed this device doesn't corrupt an ongoing data transfer.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Furthermore, this feature does not work very well with all SCSI host adapters.
Some Linux SCSI drivers do not acknowledge the removal of a peripheral when
using the remove-single-device feature.  In such kind of driver, the low level
directly maintains a cache of available peripherals but there is no
communication with the mid level when removing a peripheral, so the low level
still think the device is alive and, at the time rescan-scsi-bus check for
its removal, the kernel is displaying indefinitely a message like this one:

  esp0: Warning, live target 4 not responding to selection.

This bug was discovered during the test of scsitools in the ESP100 driver
(sparc) on 2.2 kernels.  I wrote a fix for it and reported it upstream (to the
linux-sparc mailing list).  It is provided here in kernel-source-2.2.14.espfix
file.  The way it works is generic by adding a revoke function call to the mid
level driver to tell the low level that the peripheral was removed, but this
revoke function have to be written for all problematic low level drivers.
Note that this bug could also exist for NCR5380 and NCR53C9x drivers at least,
since they are based on the same design than the Sparc ESP one.

  -- Eric Delaunay <delaunay@debian.org>