>On January 9, you wrote:
>> >On January 9, you wrote:
>> >> Good. Also, to check if the drive is OK, press <TEST> <WRITE LOCK>.
>> >> Doing this on a stopped disk checks some logic. Also try this on a
>> >> running disk to do additional tests. They should complete with a
>> >> display of "T 00" if everything is okay. (It might take a while...)
>> >
>> >  Ok, I'll try this in a few minutes.
>> 
>> Do that.
>
>  Ok, I tried it...it reported "T 00" for the drive both running and
>stopped.

Good. The drive is okay then.

>> Do you get it to find *any* drives?
>
>  Nope...Still no luck.  I even tried moving it from the "0" connector
>on the kda50 distribution panel to the "1" connector, tried it again,
>then tried it with the drive id set to 0001, still no luck.
>
>  I would, at this point, start blaming blown hardware, but I get the
>same results from two SI subsystems and an ra90, and two different
>kda50 board sets, all from drastically different sources.  That's too
>much of a coincidence for me.
>
>  Incidentally, if I try to boot the machine from dua0 while closely
>watching the LEDs on the drive (I'm pretty sure it's not bootable but
>I just wanted to see if it'd try to execute a read), it sits there for
>a few seconds and says "DEVOFFLINE".
>
>  Does the "drive" identifier in the kernel config file actually
>correlate with the unit id on the drive?  Meaning, if I have a "drive
>9" configured in the kernel, will I have to select id 0009 on the
>ra90, even though it's still on controller 0 at 772150?

I think it should correlate to the physical unit number.
In configuration, you specify on which controller it is, and what
number it has.

>  Sorry I'm being so clueless here...rl02s are no problem..even
>rk05s...but these dang ra90s are too much for my brain. :)

No problems... :-)

	Johnny