hello managers,
the summary is quite late, because I wasn't able to solve the
problem yet. I received mail from 4 kind soles. I'll summerice
their suggestions shortly:
-------- alan_at_nabeth.cxo.dec.com (Alan Rollow): --------
> See what the hard errors. If you have DECevent installed use
> it to see what the error log has to say. If not, use uerf(8)
> with the option "-o full". Device errors will has Request
> Sense data associated with them, which is at the end of the
> listing of the entry. Protocol errors tend not to. If you're
> getting protocol errors something is wrong with the bus.
>
> Common things are:
>
> o Not enough termination
> o Too much termination
> o Too much cable length
> o Bad connectors
> o Bad cables
> o Insane devices
> o Insane controller
and he pointed out, that event error messages were missing in my
mail. unfortunately there wasn't anything usefull in the uerf-log.
both devices worked perfectly on the very same machine, when the
other one was not connected. when trying to boot with both dev.
attached, there is no event recorded - the boot stops to erarly.
-------- Thomas Leitner <tom_at_finwds01.tu-graz.ac.at>: --------
thomas replied in german, so I'll not quote directly. he
suggested to ">>> test scsi" at boot prompt and check the
version numbers of the streamer and the alpha.
both are pretty new and so is the firmware. the test of the
scsi-bus indeed reported errors: write requests seemed to
fail. (?)
-------- Wesley Darlington <w.darlington_at_am.qub.ac.uk>: --------
> This has probably been said already, but it sounds a little
> bit like you are exceeding scsi length limitations. What is
> it, about 3m if there are less than four disks on the bus or
> 1.5m if there are more than four disks.
>
> And that includes all internal cabling. Perhaps you are using
> cables that are just too long. Get some 0.5m cables?
>
> Is it possible that the raid _and_ the tape drive have
> internal termination turned on? This doesn't sound like the
> answer, but I guess it's a straw worth clutching at! :-)
the internal cabeling of the raid is indeed very huge. and i
didn't recognize one drive, which is attached internaly to
the second scsi bus. So I guess it's indeed the cable length ...
-------- Dr. Tom Blinn <tpb_at_zk3.dec.com>: --------
>You seem to be assuming (always a dangerous proposition) that simply because
>both your Sony DDS drive and your CMD TECH RAID controller appear to work OK
>individually with your system's SCSI controller, that everything will work
>OK if you hook both devices onto the same SCSI bus. You also failed to
>state the system models for the two systems, and the SCSI controller types.
>
>There are many things that could be wrong. It's possible that one or the
>other of the two SCSI devices (the DDS tape and RAID controller) does not in
>fact correctly implement the SCSI-2 specification, and in particular does
>not work well on a bus with other devices. We see this happen more often
>that we'd like in system testing.
>
>It's possible that there's a problem in the SCSI controller support for the
>later (V4.0C) release that wasn't present in the older (V3.2G) release.
>
>If you've got V4.0C on the second system, then I believe you've got one of
>the Personal AlphaStation systems, and the second SCSI controller likely is
>an NCR810 (since as far as I know that's the only supported configuration).
>What is the SCSI controller on the older (V3.2G) system? What exactly are
>the two systems? This can make a big difference.
>
>Last but not least, the V4.0x releases have device information for things
>like DDS tapes in a separate "dynamic device recognition" database that is
>used to influence a number of things related to SCSI I/O. It's possible you
>can get your setup to work with the right entries in the ddr database, but I
>have no idea what you'll need to put there to get the Sony DDS3 drive to
>work along with the other devices on the bus. In V3.2G, this information if
>provided would have been in the form of changes to one of the cam_ files in
>the system configuration directories where you build the kernel. This is a
>change from V3.2x to V4.0x, and there were others as well.
>
>Good luck..
>Tom
Well. Sorry for leaving out so much information. And I guess I didn't
make
myself clear: both devices work on the very same machine when the other
one
is not connected. since there is another drive on the same bus, I'll try
to
connect the streamer to the internal scsi.
-------------------------------------------------------------
thanx for you help!
yt,
andreas bunten
ps: my original request:
> hello managers,
>
> I couldn'd find anything appropriate in the archive, so I'm asking
> all of you.
>
> imagine this setup:
> -------------------
>
> Alpha 1 (DU 3.2G): connected to DDS3 streamer (sony) on second
> scsi bus: working properly
> Alpha 2 (DU 4.0c): connected to RAID (CMD TECH CRD-500) on second
> scsi bus: also working properly
>
> we don't want to backup over the network, so the streamer goes to
> Alpha 2. But now it won't boot anymore.
>
> Error messages while booting:
> -----------------------------
>
> Active CCB at time of error
> CCB request completed with an error
> cam_logger: CAM_ERROR packet
> cam_logger: bus 2 target 0 lun 0
> cdisk_complete
> Retries Exhausted
> Hard Error Detected
> This is repeated over an over - the machine won't come up.
>
> things I already checked:
> ------------------------
>
> the streamer has ID 5. the RAID is ID 2 lun 0 and lun 1.
> which means there isn't a conflict (at least no simple one)
> and there is no "target 0 lun 0 at bus 2"! Alpha 2 boots,
> if only one of the two (streamer or raid) is connected.
> then the streamer (or the raid) is working fine. We tried
> active and passive termination on the bus.
> Any help welcome and I will of course write a summery.
>
> yt,
> andreas bunten
Received on Mon Feb 02 1998 - 12:07:43 NZDT