Re: Linux-2.0.27 and 2.1.14 ( dont dance yet )

Cousin Gerard (
Mon, 9 Dec 1996 00:05:02 +0000 (GMT)

On Sun, 8 Dec 1996, Edward Welbon wrote:

> Howdy Uncle George,
> You really should include more details concerning the fail. Do you have a
> NCR/Symbios controller on the mother board? Or is it a seperate adapter?
> I have two NCR adapters gathering dust (Tyan 825). I don't like them,

I used a Tyan 825 for 6 months and have had experienced only 2 GROSS
ERROR(s). I have moved hundreds of GB with it.
The documentation is wrong about termination set-up.

> they seem to be somewhat unforgiving and cause crashes (YMMV and no SCSI
> adapter jihads please, this is just my personal observation, I could be
> wrong about this for reasons I'll mention). If controller is a seperate
> adapter, you should at least try another model.

I currently use a Promise SCSI ULTRA with 53C875 chip (11 days).
The documentation is not clear about termination set-up. I had to guess
the right set-up for Wide + Narrow internal devices.
I only replaced the board, all cables and devices are unchanged.
I have done heavy tests with it under 2.0.27 and 2.1.13 with an enhanced
version of the driver that uses some new features of the NCR53C875.
I've probably moved hundreds of GB with my 2 HD (Atlas Wide + IBMS12) and
my CDROM Tosh 3401B working at the same time.
Config: memory mapped + 8 tags.

For the moment, ZERO problem.

> Also, there are two forms of the NCR scsi support and in one of those
> forms there is a choice for io-port or memory mapped control. Try the
> choice that forces io-port control. It might be hard to get through a
> compile if your disk system is failing though.

In my opinion (and experience), both memory mapped and io mapped works,
at least with i386 architecture and serious chip set and cpu.

> Lastly, and probably most importantly, _PERHAPS_ the disk itself is the
> problem, this can cause scsi accesses to go bonkers. Remember, there are
> two participants in a transfer, the target and the initiator. The disk
> plays a major role in disk operation (don't mean to be patronizing, but
> often the controller gets the blame when the disk itself is the problem).
> One factor that can kill disks is heat, the 7200 rpm disks are
> particularly bad (in general) though other disks are also bad (low power
> dissipation has been a factor for my recent disk purchases). I have a
> Seagate Baracuda 15150W that *must* be cooled by a fan dedicated to that
> purpose. As a rule of thumb, the disk must not be uncomfortably warm. If
> you have ever stood near a rack with 100 or so disks in it on a cold day
> or in a temperature controlled lab, you know what I mean, such a rack
> makes a superb space heater.

Agreed about heat problems with high-end hard disks.
However, in my opinion, heat problem is a general problem. _All_ components
are concerned.
Cool disks + hot chips crashes as well.