Archive-name: linux/howto/scsi/part2
Last-modified: 8 Nov 95
-----BEGIN PGP SIGNED MESSAGE-----
*** The `Linux SCSI HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>. Please
*** direct any comments or questions about this HOWTO to the author,
*** Drew Eckhardt <d...@PoohSticks.ORG>.
- --- BEGIN Linux SCSI HOWTO part 2/3 ---
3. Distribution kernels include release 4 or 5 of the driver, which does
not support useful things like disconnect/reconnect (the most noticeable
effect of this being attempts to retension/rewind/file space a tape
lock you out of all SCSI devices), multiple host adapters, and
BIOSless operation.
The latest release of the driver is available at
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/ncr53c810
Currently, this is a 1.2.10 and newer patch, although the next
release will be 1.3.x exclusively. These patches are NOT
entirely clean due to some ELF and other patches which were
in the baseline revision of my source tree, and if you
can't manually correct the (four) problems you should get,
you shouldn't use them. Note that only the newest patch is
needed; these are not incremental.
If you wish to run the newer NCR driver with a 1.3.x kernel
before then, Harald Evensen <Harald.Even...@pvv.unit.no> has
adapted the patches for 1.3.x
ftp://ftp.pvv.unit.no/pub/Linux/ALPHA/ncr
These patches should be clean.
Please see all of the READMEs in these directories. You should
also join the NCR mailing list if you are interested in running
the ALPHA code, since interim bug fixes and announcements of the
next release are posted to this list.
To subscribe, send mail to majord...@colorado.edu with
subscribe ncr53c810
in the text. You can unsubscribe by sending mail to the same address
and including
unsubscribe ncr53c810
in the text.
Common Problems :
1. Many people have encountered problems where the chip worked
fine under DOS, but failed under Linux with a timeout on
test 1 due to a lost interrupt.
This is often due to a mismatch between the IRQ hardware
jumper for a slot or mainboard device and the value set
in the CMOS setup. DOUBLE CHECK
- The IRQ you are using is used only by your onboard NCR chip,
or the slot an NCR board is installed in
- Any main board jumpers selecting the IRQ for the onboard
chip or slot match your CMOS setup.
It may also be due to PCI INTB, INTC, or INTD being selected
on a PCI board in a system which only supports PCI INTA. If you
are using an NCR board which has jumpers to select between PCI
interrupt lines, make sure you are using INTA.
Finally, PCI should be using level-sensitive rather
than edge triggered interrupts. Check that your board
is jumpered for level-sensitive, and if that fails
try edge-triggered because your system may be
broken.
This problem is especially common with Viglen some Viglen
motherboards, where the mainboard IRQ jumper settings are
NOT as documented in the manual. I've been told that what
claims to be IRQ5 is really IRQ9, your mileage will vary.
2. Lockups / other problems occur when using an S3 928, or Tseng
ET4000W32 PCI video board.
There are hardware bugs in at least some revisions of these
chips. Don't use them.
3. You get a message on boot up indicating that the I/O mapping
was disabled because base address 0 bits 0..1 indicated a
non I/O mapping
This is due to a BIOS bug in some machines which results in
dword reads of configuration regsisters returning the
high and low 16 bit words swapped.
4. Some systems have problems if PCI write posting, or CPU->
PCI buffering are enabled. If you have problems,
disable these options.
5. Some systems with the NCR SDMS software in an onboard BIOS
ROM and in the system BIOS are unable to boot DOS.
Disabling the image in one place should rectify this
problem.
6. If you encounter the message
"scsi%d: IRQ0 not free, detaching"
The NCR chip had a 0 stored in the PCI configuration register.
Either you have configuration problems (see Common Problem 1), or
you have a defective mainboard BIOS.
As a work arround, you could edit drivers/scsi/ncr53c7,8xx.c,
and change pci_init() so that you have
irq = my_irq;
before
return normal_init (tpnt, board, chip, (int) base,
(int) io_port, (int) irq, DMA_NONE, 1, bus, device_fn,
options);
7. Some systems have hideous, broken, BIOS chips. Don't
make any bug reports until you've made sure you have
the newest ROM from your vendor.
8. The command line overrides ncr53c810=xxx, etc. don't work.
In stock kernels, this is because their entry points are not included
in init/main.c, which is quite intentional :
The driver makes no attempt to avoid autoprobing for a board
where a command line override was used, so if an override
is used where the board actually showed up to the PCI
configuration routines, you'll have big problems.
The only reason you would need an override would be if the
PCI hardware + BIOS were broken, in which case certain error
recovery routines wouldn't work, rendering the override
less than useful.
Finally, nearly all of people who _think_ they need a command line
override do because they get configuration or other error messages
from the driver. If the driver says you have a configuration
problem, you have a broken system or a configuration problem
and no override is going to fix this.
If some one has gone and added the appropriate entry points to
init/main.c for command line overrides, they are totally unsupported
and may not work.
9. Certain NCR boards (most notably Nexstor) which don't use an
NCR BIOS get timeouts. Some of these ROMs handle synchronous
and transfers, negotiate for sync. transfers on power up,
and leave the drives in an unknown state. When the distribution
Linux NCR driver attempts to talk with them, it gets timeouts
and cannot recover because it won't do a bus reset or renegotiate.
If you run into this problem, you can either disable
synchronous transfers in the board's setup program, or
upgrade to a newer ALPHA release of the NCR driver which
will do synchronous negotiation.
Notes:
1. CONFIG_PCI must be set
Section 4.12 : Seagate ST0x/Future Domain TMC-8xx/TMC-9xx
Supported and Unsupported Configurations :
Base addresses : 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000
IRQs : 3, 5
DMA channels : DMA is not used
IO : memory mapped
Autoprobe : probes for address only, IRQ is assumed to be 5,
requires installed BIOS.
Autoprobe Override :
Compile time : Define OVERRIDE to be the base address, CONTROLLER to
FD or SEAGATE as appropriate, and IRQ to the IRQ.
kernel command line : st0x=address,irq or tmc8xx=address,irq (only works
for .99.13b and newer)
Antiquity Problems, fix by upgrading :
1. Versions prior to the one in the Linux .99.12 kernel had a problem
handshaking with some slow devices, where
This is what happens when you write data out to the bus
1. Write byte to data register, data register is asserted to bus
2. time_remaining = 12us
3. wait while time_remaining > 0 and REQ is not asserted
4. if time_remaining > 0, assert ACK
5. wait while time remaining > 0 and REQ is asserted
6. deassert ACK
The problem was encountered in slow devices that do the command
processing as they read the command, where the REQ/ACK handshake
takes over 12us - REQ didn't go false when the driver expected it
to, so the driver ended up sending multiple bytes of data for
each REQ pulse.
2. With Linux .99.12, a bug was introduced when I fixed the arbitration
code, resulting in failed selections on some systems. This was
fixed in .99.13.
Common Problems :
1. There are command timeouts when Linux attempts to read the partition
table or do other disk access.
The board ships with the defaults set up for MSDOS, ie interrupts
are disabled. To jumper the board for interrupts, on the Seagate
use jumper W3 (ST01) or JP3 (ST02) and short pins F-G to select
IRQ 5.
2. The driver can't handle some devices, particularly cheap SCSI
tapes and CDROMs.
The Seagate ties the SCSI bus REQ/ACK handshaking into the PC bus
IO CHANNEL READY and (optionally) 0WS signals. Unfortunately, it
doesn't tell you when the watchdog timer runs out, and you have
no way of knowing for certain that REQ went low, and may end up
seeing one REQ pulse as multiple REQ pulses.
Dealing with this means using a tight loop to look for REQ to
go low, with a timeout incase you don't catch the transition due
to an interrupt, etc. This results in a performance decrease, so it
would be undesireable to apply this to all SCSI devices. Instead,
it is selected on a per-device basis with the "borken" field for
the given SCSI device in the scsi_devices array. If you run into
problems, you should try adding your device to the list of
devices for which borken is not reset to zero (currently,
only the TENEX CDROM drives).
3. A future domain board (specific examples include the 840,841,
880, and 881) doesn't work.
A few of the Future domain boards use the Seagate
register mapping, and have the MSG and CD bits of the
status register flipped.
You should edit seagate.h, swapping the definitions for
STAT_MSG and STAT_CD, and recompile the kernel with
CONTROLLER defined to SEAGATE and an appropriate
IRQ and OVERRIDE specified.
4. When attempting to fdisk your drive, you get error messages
indicating that the HDIO_REQ or HDIO_GETGEO ioctl failed,
or
You must set heads sectors and cylinders.
You can do this from the extra functions menu.
See Section 5.4 : Disks : Partitioning
5. After manually
...
read more »
Linux SCSI HOWTO (part 1/3)