[2478] in linux-scsi channel archive
Re: Problems with AHA2940AU
daemon@ATHENA.MIT.EDU (R.O. =?ISO-8859-1?Q?Bl=E4ttner" ?=)
Wed Sep 17 13:08:39 1997
Date: Wed, 17 Sep 1997 17:08:26 +0200
From: "R.O. =?ISO-8859-1?Q?Bl=E4ttner" ?= <rolf.blaettner@nuernberg.netsurf.de>
To: tgoltz@mediaone.net
CC: linux-scsi@vger.rutgers.edu
----------------------------------------
At Mon, 15 Sep 1997 18:40:02 +0200 myself,
R.O. Blaettner <rolf.blaettner@nuernberg.netsurf.de>
wrote:
> Tom Goltz <tgoltz@mediaone.net> wrote at Sun, 14 Sep 1997 23:38:50
> -0400:
>
> > I'm having trouble with an Adaptec AHA 2940AU (Narrow, Ultra) controller in
> > a Dell Dimension P100t computer system. The SCSI bus has a Fujitsu 4gb HD,
> > a NEC SCSI CD-ROM and an HP DAT drive. The harddrive and CD-ROM work
> > great, but almost anything I do to the tape drive generates the following
> > information:
>
> > I'm running 2.0.31 (Prepatch-9)
>
> > Any suggestions?
>
> > First I've enclosed the bootup information for the machine:
>
> > Sep 14 12:19:30 minerva kernel: Console: 16 point font, 400 scans
>
> [ ... deleted ... ]
>
> > Sep 14 12:19:30 minerva kernel: aic7xxx: <Adaptec AHA-2940A Ultra SCSI host
> > adapter> at PCI 15
> > Sep 14 12:19:30 minerva kernel: scsi0 : Adaptec AHA274x/284x/294x
> > (EISA/VLB/PCI-Fast SCSI) 4.1/3.2
> > Sep 14 12:19:30 minerva kernel: scsi : 1 host.
> > Sep 14 12:19:30 minerva kernel: Vendor: FUJITSU Model: M2954S-512
> > Rev: 0147
> > Sep 14 12:19:30 minerva kernel: Type: Direct-Access
> > ANSI SCSI revision: 02
> > Sep 14 12:19:30 minerva kernel: Detected scsi disk sda at scsi0, channel 0,
> > id 0, lun 0
>
> O.K., FUJITSU DISK is seen at SCSI-Id 0
>
> > Sep 14 12:19:30 minerva kernel: Vendor: NEC Model: CD-ROM DRIVE:500
> > Rev: 2.8
> > Sep 14 12:19:30 minerva kernel: Type: CD-ROM
> > ANSI SCSI revision: 02
> > Sep 14 12:19:30 minerva kernel: Detected scsi CD-ROM sr0 at scsi0, channel
> > 0, id 1, lun 0
>
> O.K., NEC CDROM is seen at SCSI-Id 1
>
>
> > Sep 14 12:19:30 minerva kernel: Vendor: HP Model: C1533A
> > Rev: A612
> > Sep 14 12:19:30 minerva kernel: Type: Sequential-Access
> > ANSI SCSI revision: 02
>
> ?!?, HP DAT is seen, but no message about it's SCSI-Id
>
> > Sep 14 12:19:30 minerva kernel: scsi : detected 1 SCSI tape 1 SCSI cdrom 1
> > SCSI disk total.
> > Sep 14 12:19:30 minerva kernel: SCSI device sda: hdwr sector= 512 bytes.
> > Sectors= 8498506 [4149 MB] [4.1 GB]
>
> [ ... deleted ... ]
>
> > About 20 seconds after I issue the 'mt -f /dev/st0 erase' command, I get
> > the following:
>
> > Sep 14 12:21:52 minerva kernel: scsi : aborting command due to timeout :
> > pid 2612, scsi0, channel 0, id 0, lun 0 Write (6) 05 c0 83 02 00
>
> Here, a write to SCSI-Id 0 fails (what is at ID 0: DISK or DISK and DAT
> ?)
>
> My suggestion: possibly Your HP-DAT drive uses SCSI-Id 0 too ?
> This would result to conflict with Your DISK.
> Check the jumpering of HP-DAT drive - if it's jumpered to ID 0,
> You have to change this to 2,3,4,5, or 6 (the controller itself
> is normally at ID 7).
>
> [ ... deleted ... ]
>
> > Tom Goltz
> > Software Engineering Services
> > (508) 863-1175
> > tgoltz@computer.org
>
> Hope, I could help You !
>
> - Rolf -
========================================
At Tue, 16 Sep 1997 21:57:41 -0400, Tom Goltz <tgoltz@mediaone.net>
gave me answer (not via this linux-scsi list):
> At 06:40 PM 9/15/97 +0200, you wrote:
> >?!?, HP DAT is seen, but no message about it's SCSI-Id
> >My suggestion: possibly Your HP-DAT drive uses SCSI-Id 0 too ?
> >This would result to conflict with Your DISK.
> >Check the jumpering of HP-DAT drive - if it's jumpered to ID 0,
> >You have to change this to 2,3,4,5, or 6 (the controller itself
> >is normally at ID 7).
>
> It's a good thought, I don't know why the address didn't show (it may have
> been trimmed at some point as I pasted the messages), but it's assigned
> SCSI ID 3. Typically an address conflict like that doesn't just impact one
> of the devices, but usually renders both catatonic.
>
> Tom Goltz
> Software Engineering Services
> (508) 863-1175
> tgoltz@computer.org
========================================
Now, I've a suggestion how SCSI ID's may not
be the same as they appear to be:
------------------------------
Hi, Tom !
You wrote Your DAT having SCSI ID 3. That sounds perfectly good.
Because I don't know how You've cabled or jumpered the ID pins of Your
devices I'll tell You my story of ill ID's - maybe it helps You, maybe
Your problem has another reason ?
(1) My story:
I'd a couple of SCSI disks, a MO-drive, an old QIC tape (it was at a
time before I bought the HP 1537 DAT). I'd arranged the devices in
two external SCSI cases with those funny SCSI ID coding switches on
the outside (with numbers 0..7). I'd given distinct ID's to my
devices: Disks: 0, 1, 2, Tape and MOD 3 and 4, for example - I don't
remember the exact settings now anymore.
So far so good (I thought ...).
But, there were permanently ridiculous errors while accessing the
disks :-( :-( sometimes I even couldn't boot.
- First, I thought to have (a) bad disk(s). I tested for bad blocks,
found some :-( .. rearranged them by painfully re-building filesystems
while excluding those bad blocks by sorting their numbers into the file
system's bad block list. Sometimes I lost a valuable amount of data
because I couldn't back-up without errors. And so on...
- Secondly, I tried newer versions of Linux kernel and/or aic7xxx
driver too ... not significantly changing things. :-(
- Finally, one of the disks died (bearing damage, couldn't spin up
to full speed anymore). I bought a new one. As my wife (she's a
quite good E-engineer :-) and myself did a re-arrangement of devices
in those boxes, she detected the reason of all those evil troubles !!
(2) First, a short explanation:
From such a coding switch there are 4 wires leading to the ID jumper
pins of the device. One wire is black (ground) and connected to one
row of the 2x3 pin array (more accurate: it shorts the 3 pins in
one row). The other 3 wires are colored and lead each to one of the
pins in the other row, each representing one of the 3 ID bits.
(3) Now, my MISTAKE:
I'd TWISTED the ID connector at one of the disks !
Thusly, I'd shortened the disk's ID bit pins by the "black row" of the
cable connector and, vice versa, connected the disk's "ground pin row"
to the cable connector's "colored" coding bit row ... :-([
@!<^!&=~!# GRRRrrrrrrrrrrrrrrrrrrrrrmpf !! Aaaargghhhhh !!
(Should read as all evil cursed words You ever may remember)
The results of this ugly twist I never could realize exactly until now,
because sometimes it worked, othertimes it didn't.
... must either depend on the time sequence of accessses to the various
devices, or on voltage levels, the temperature, the moon phase, or the
number of black holes in the Milky Way ...? :-) DUNNO
(4) Conclusion:
So, in case You probably use the same sort of coding switches,
I would suggest to have a sharp look at the ID pin cable connectors..
with kind regards from ol'Germany, wishing You much success
- Rolf -
--------------------
P.S. Folks, please forgive me the huge volume of this posting !
I only want to help Tom and all of You to avoid the same
troubles I had to deal with.
And I couldn't explain things in fewer words 'cause of my
poor knowledge of how to write a good, compact English.
Please, no flames :-)
----------------------------------------
dipl.phys. Rudolf Otto Blaettner
Am Schuetzengraben 28 A
D 91074 Herzogenaurach
Germany
rolf.blaettner@nuernberg.netsurf.de
--------------------------------------------------------------------------------
