Subject: Re: 340 can't locate second SCSI HD on boot.
To: None <squonk@drizzle.net, jim@mpn.cp.philips.com>
From: Steve Peurifoy <sp128@ibm.net>
List: port-hp300
Date: 05/27/1998 21:24:32
Apologies to those who have already heard me babble about this issue
several times before.

    mb == Mike Begley

    mb> I'm trying to get a second SCSI disk attached to my 340.
    mb> the disk is a seagate ST32430N.
    mb> When I boot the machine with this drive attached, I get the message:

    mb> st: wrong specs: type 0 qual 0 version 1

I've not seen the "st: wrong specs: ..." but I know from painful experience
that this particular disk (among others) will intermittently take longer
than the 2 ms allotted in the driver for the selection phase and this could
cause it to be unrecognized (if you're lucky) or cause silent FS corruption
in subsequent use (if you aren't).  If you're going to use this disk, I
*strongly* suggest increasing the timeout in scsi.c:issue_select() per the
workaround in PR/3769 or equivalent.  Once that is done, I've found the
disk to work very well.  You may want to make this change in both the kernel
proper and in the boot loader driver.  Of course, it's possible that you're
encountering some entirely different problem.

    jr == Jim Reid

    jr> FWIW, I have a similar problem with my 425. It doesn't see the second
    jr> SCSI disk at boot time, though the autoconf stuff doesn't say anything
    jr> about wrong specs for a SCSI tape drive. By trial and error, I found
    jr> that making the boot PROM probe for boot devices made the second disk
    jr> visible. So, when I reboot, I hold down the space key, wait for the
    jr> PROM probe to complete and select the usual NetBSD boot disk. When it
    jr> boots, it sees the second disk.

    jr> I suspect there's something not quite right in the kernel's boot code
    jr> which means that the SCSI bus doesn't get properly reset - but the
    jr> PROM code does reset it OK - or something like that.

I've seen these symptoms as well at times.  I don't know what determines
the selection delay on these disks, but I speculate that once the bootrom
has "poked" the drive, it responds more quickly on the next attempt.  In
any case, increasing the timeout eliminated these problems for me.

On older vintage machines with rev C1 bootroms, sometimes the bootrom
itself won't recognize some of these drives due to its ~1 ms timeout.
Once upon a time I got curious/desperate enough to disassemble enough
of the bootrom to track down where the timeout was set and burned a new
set of roms with a 10 ms timeout.  Case solved.  Ya gotta want to boot
from the disk pretty bad to go that far though.  On the off chance that
anyone else runs into that obstacle, I could see about digging up the
image and making it available if there's sufficient interest.

-Steve