[662] in linux-scsi channel archive
Re: 53c825 dies w/o ftape's buffers? huh?
daemon@ATHENA.MIT.EDU (Drew Eckhardt)
Thu Oct 5 20:25:57 1995
To: Michael Adas <mja@telecom.wisc.edu>
cc: linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Wed, 04 Oct 1995 22:50:02 CDT."
<Pine.LNX.3.91.951004224010.5468A-100000@venus.telecom.wisc.edu>
Date: Thu, 05 Oct 1995 14:02:37 -0600
From: Drew Eckhardt <drew@qualcomm.com>
In message <Pine.LNX.3.91.951004224010.5468A-100000@venus.telecom.wisc.edu>, mj
a@telecom.wisc.edu writes:
>In the mean time, I guess CONFIG_FTAPE makes the whole shebang work,
>and it only robs me of 96k. I'm about to go to 24 or 32 meg, so 96k
>isn't a huge concern; but it'd be nice to find out if the NCR card can
>be coerced into working without CONFIG_FTAPE. Any comments Drew?
There are a few systems where on ocassion, instructions fetched by the NCR
chip end up with one corrupt 32 bit word that doesn't match what was
at the memory location referenced, sometimes resulting in an ILLEGAL
INSTRUCTION interrupt.
I believe that the same thing causes the existing issue queue (Bad PCI
bus-mastering memory read) problem on some systems running older driver
releases. I also think that it's a possibility with the newer
driver which does more memory accesses of this type to handle
disconnect/reconnect where command structures disappear from the
driver's linked list of disconnected commands.
In a lot of cases, people have had success changing their PCI configuration
to disable broken things in their chipset (write back caching for example)
and swapping PCI peripherials out for other types or revisions, especially
boards (Early TSENG ET4000W32p, 928p, etc) which are known to have problems.
Even if you can get things to work, I'd start playing with this because
there's nothing to say the problem isn't going to surface silently someplace
else, like when you're writing information to disk.
