[3174] in linux-scsi channel archive
Re: AHA1542CF suddenly stopped working! Help!
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Tue Feb 3 01:40:31 1998
Date: Mon, 2 Feb 1998 22:34:54 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: libove@felines.org
CC: redhat-list@redhat.com, linux-scsi@vger.rutgers.edu
In-reply-to: <Pine.LNX.3.96.980203004450.746A-100000@panther.felines.org>
(message from Jay Vassos-Libove on Tue, 3 Feb 1998 00:50:07 -0500
(EST))
Date: Tue, 3 Feb 1998 00:50:07 -0500 (EST)
From: Jay Vassos-Libove <libove@felines.org>
I have recently added a Pentium 133 to my (old) collection. I plugged an
ISA bus Adaptec AHA1542CF in to it, added a couple of drives, and away I
went. It was working great, until a few hours ago.
I did not do anything to it. I shut the system down, added some more RAM,
turned it back on, and all was great. Then I shut it down to take out the
video board so that I could read the chipset numbers off of it, put the
board back in, turned it back on, and since then (despite a dozen power
cycles and board pulls) all I can get it to do is to load the Linux
kernel, and get as far as probing the SCSI bus and it always gets the
error:
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0,
lun 0 Test Unit Ready 00 00 00 00 00
I have removed the second device from the bus (Hitachi DK516C) - no
effect. I have removed the first device from the bus (Seagate Medalist
Pro ST52160N) - no effect. I have removed both devices from the bus and
put a different device on the bus as device zero (HP 307M old thing) - no
effect.
Clearly, it isn't the specific device(s) on the bus that is the cause of
this problem. Software did not change. The data on the drives is okay --
I moved one of them to another system with a compatible controller
(AHA2842VL) and it mounts happily and is in use presently.
What could have happenned which
- allows the hardware self test, including disk surface verification, to
work find
- allows the SCSI Controller DMA test to run loops and loops without error
+ yet results in the Linux kernel booting only as far as the AHA1542
driver, and then wiping out as described above
+ given that I have not changed anything!
Heelllppppp!!!!!!!!
Thanks ...
If the AHA1542 interrupt is not getting through, either due to being broken or
due to the BIOS having reassigned something that could explain this behavior.
The built-in DMA and surface analysis firmware does not need interrupts to
function.
Leonard
