[114] in linux-scsi channel archive
[SOLVED] Re: Lockups with aha1542cf
daemon@ATHENA.MIT.EDU (Kai Harrekilde-Petersen)
Fri Mar 24 02:43:55 1995
From: Kai Harrekilde-Petersen <khp@pip.dknet.dk>
To: pe1chl@wab-tis.rabobank.nl
Date: Wed, 22 Mar 1995 14:37:49 +0100 (MET)
Cc: linux-scsi@vger.rutgers.edu (Linux SCSI mailing list)
In-Reply-To: <9503200836.AA13130@sys3.pe1chl.ampr.org> from "Rob Janssen reading Linux mailinglist" at Mar 20, 95 09:36:43 am
Well, thanks to everyone who gave me a hand on solving my lockup problem.
It appears that Rob's suggestion is right: the IBM disk fouls up when it is
allowed to do disconnect/reconnects.
I did a little test seires to isolate/provoke the problem:
I first checked that the DAT disconnected right: it sure did, from the light
of the controller LED (i am able to ls/du/whatever the disk while the tape
is rewinding).
Then I tried a simple `tar -c --totals --checkpoint /', without any other
activity on the system (save the usual daemons). It got to checkpoint 5840
(ie ~58Mbyte) before it locked up. WHen the lock occured, I could hear the
tape suddenly try to wind the tape a bit, and then stop dead. The green LED
on the tape drive (which usually tells that i've inserted a tape), went
blank, while the yellow LED (which says the drive is active, doing
something), was lit. The LED on the 1542cf was lit too.
OK, nothing unusual in this, so I rebooted to DOS, and using aspi4dos and a
ported GNUtar for aspi, I was able to back up the ~25 Meg on my dos
partition without a hitch. This pointed a bit towards Linux, but it could
also just be a case of "luck" on DOS' side.
As I had previously noted that if I ran something in parallel with tar,
which accessed the disk, the scsi bus would hang far quicker. Hence, I
booted to Linux and started the following in two consoles:
1) tar -c --totals --checkpoint /
2) while true; do du / > /dev/null; ls -lAR / > /dev/null; done
... and sure enough: the tar process didn't make it past checkpoint 150
before the scsi bus was locked up again.
So this clearly had something to do with the disk. OK, BRST (Big Red Switch
Time), and into the adaptec setup and switch off disconnect/reconnect for
the disk. Reboot into Linux (wait for e2fsck to clean up <Zzzzzz>), and try
out the tar and du/ls stuff again. (wait 30 minutes) ... it worked! not a
hitch! GREAT!!!!!!
Now, i'm just wondering whether this disconnect/reconnect thing is a bug, or
just a "missing feature" of the disk (if it's a bug, i'm in for a replace
/upgrade of some kind). Or should I just ignore the disconnect thing?
Kai
--
Kai Harrekilde-Petersen <khp@pip.dknet.dk> Linux: choice of a GNU generation
>> Inside every little problem there's a BIG problem, struggling to get out <<
===== Please do not use my old account <khp@login.dknet.dk> as it's void =====
