%IPB-W-NOSUCHDEVICE, unknown debug or dump device.

[Steven Schweda]

I've started trying to shift my HP[E] Hobbyist systems to VSI
Community. While working toward shifting my main rx2600, I hit a
problem on my spare/experimental rx2600 when trying to boot from the new
I640842L3OE DVD:

fs5:\EFI\BOOT> BOOTIA64.EFI

%VMS_LOADER-I-TRANSFER: Starting VSI OpenVMS...
%IPB-W-NOSUCHDEVICE, unknown debug or dump device.
[And the system hangs until reset.]

The DVD was loaded in:

Disk DKC600:, device type TOSHIBA DVD-ROM SD-M1711, is online, mounted, software
write-locked, file-oriented device, shareable, available to cluster, error
logging is enabled.

Which was connected to an add-in PCI SCSI card (where I had had a DLT
drive connected before):

Device PKC0:, device type SYM53C896 LVD SCSI, is online, error logging is
enabled.

All of which worked fine in the normal VMS environment. Clearly, the
EFI stuff could find "fs5:\EFI\BOOT\BOOTIA64.EFI".

I moved the SCSI cable from the DLT drive which had been connected to
that SCSI card to the DVD-ROM drive, because that was easy. The add-in
SCSI card is there because connecting a slow SCSI device to the built-in
external SCSI port on the rear of the rx2600 slows down the PKB bus,
which is where the top-most ("2") disk is attached.

It likely has been some years since I actually needed to boot either
of these systems from a VMS installation DVD, but it must have been
done, as they're both running V8.4, and I doubt that I ever put a VMS
installation DVD onto a hard disk (or anything else).

An old (V8.3-1H1) HP[E] installation DVD failed the same way (without
the "%VMS_LOADER-I-TRANSFER: Starting VSI OpenVMS..." line).

More in desperation than hope, I tried connecting the DVD-ROM drive
to the built-in external SCSI port. That worked as expected.

So, apparently, VMS itself and the EFI firmware are able to cope with
that add-in SCSI card, but there's some limitation in the "VMS_LOADER"
which stops it from working there.

I realize that this is old hardware on a dead-end development path,
but, if someone who knew something had a few minutes to kill, and adding
the appropriate table entry (or whatever) were easy, then I wouldn't
object to being able to use a different (add-in) SCSI interface instead
of the sub-optimal built-in one next time.

Does any of this look at all familiar to anyone? (Or is my antique
hardware unique, too?)

[Steven Schweda]

Hmmm. It's been a while, and I had forgotten that I had augmented
SYS$SYSTEM:SYS$USER_CONFIG.DAT on that system:

! Added on 16-FEB-2010 22:30 manually by SMS.
! LSI Logic SCSI card SYM21040-33, with LSI53C1010-33 chip.
! Like SYS$CONFIG.DAT for "id = 0x00211000" ("-66" variant?).
! CLUE CONFIG: 10401000.00201000
! Subsystm DeviVend
device = "LSI Logic 1010 Ultra160"
name = PK
driver = sys$pkw160driver.exe
adapter = PCI
id = 0x00201000
boot_class = DK
boot_flags = HW_CTRL_LTR, UNIT_0
flags = SCSI, PORT, BOOT
end_device


Perhaps what is really needed is another entry in the official
SYS$CONFIG.DAT file to support my unofficial (cheap/Ebay) SCSI card?
A shame that the EFI-ware seems able to cope better than the
higher-level OS.

And a better explanation from HELP /MESSAGE:

REX $ help /mess NOSUCHDEVICE
%MSGHLP-F-NOTFOUND, message not found in Help Message database