From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.periphs.scsi
Subject: Adaptec 1740 problem.
Date: 14 Sep 92 19:04:43 GMT
Distribution: comp
Organization: Naval Research Laboratory


	I am trying to track down a SCSI problem that is coming up with
linux.   The person who reported the problem is using an Adaptec AHA1740
and he is saying that the controller will read the wrong disk block every
so often.  

	He gave me a test program which generates all sorts of this
type of error on his machine.  The test program essentially generates
two identical directory trees, and then compares the files from one
tree to the other.  The wrong blocks do not always appear in the same
location if the test is repeated.

	I have had him try a few things with the kernel, and so far we
have discovered that the controller is apparently writing something
into the buffer that has been selected, but it is writing the wrong
thing into the buffer.  Judging from the contents, we appear to be
getting the wrong disk block.  We have not seen any evidence that the disk
itself has become corrupted because of this, but it is possible that
something might have slipped by unnoticed.

	In principle one might argue that there is a kernel bug in
linux.  I do not feel that this is the case because I gave a copy of
the test program to someone who has an aha1542b, and on this system
there were no problems with wrong blocks being returned.

Currently my best guess is that the problem is one of two things:

	1) We are treating the 1740 the same as a 1540 insofar as the hard disk
usage is concerned (i.e. identical code).  The kernel uses one outgoing
ccb/mailbox, and one incoming ccb/mailbox, and it waits for one command to
complete (and interrupt the system) before it queues another command.  I do not
believe that any error conditions are being reported, although the kernel is
set up to retry the read for certain types of errors, and if this were
happening we would not be aware of it.  The automatic request sense is enabled.
Is there some difference between the 1740 and 1540 that we need to take into
account???

	2) The 1740 is at bios level 1.34.  Could there be a firmware bug?
(Since linux is a virtual mode OS, we do not use the bios for anything except
for boot-time initialization.  The bios level could suggest something about the
firmware level that is on the board).

	If anyone has any constructive suggestions as to what the
problem could be I would be intersted in hearing them.  I have
enclosed his configuration at the end of this mail message

	Thanks in advance.  Please reply to eric@tantalus.nrl.navy.mil

-Eric


Central stuff:
    Tower case w/8 drive bays and 250-watt power supply
    Intel 32-bit 80486 CPU @33MHz
    Micronics EISA motherboard w/8 EISA slots and 64KB cache RAM standard
    Support for Weitek 4167-33 math co-processor (no chip yet)
    Phoenix 80486/EISA ROM BIOS PLUS Version 1.01.22-2
    16MB RAM, @70ns?
    2 serial ports, 1 parallel port

Peripherals:
    Adaptec AHA-1740 SCSI-2 controller (BIOS v1.34)
    Maxtor PO-12S 1.2GB SCSI-2 hard drive
    5.25" (1.2MB) internal floppy
    3.5" (1.44MB) internal floppy
    Colorado Jumbo 250 tape drive (thru floppy interface, I think)

Hard Drive Partitioning:
    64MB DOS, 807MB DOS extended, 62MB Linux, 64MB Linux (first
    two done by DOS FDISK, latter two done by hand using DOS DEBUG)

Wetware Interface:
    Sigma Designs L-View 1664x1200 120dpi 4-gray-scale monitor & card
    Northgate Computer Systems' OmniKey/101 (modified so CTRL to left of
        "A", CAPS LOCK left of SPC, etc)
    Standard Technologies Mouse (switchable Microsoft/Mouse system)
    Howtek Scanmaster (not hooked up yet)

--
Eric Youngdale
eric@tantalus.nrl.navy.mil