FreeAXP not detecting disks

Hi all,

I've been experiencing this problem for years but never had the need to really solve it, until now.


When trying to add three new disks, I create the image files as described in the manual/guide but the disks are not recognized by Tru64.

Output from srm:

halted CPU 0

halt code = 5
HALT instruction executed
PC = fffffc0000697af0
>>>sh dev
dka0.0.0.6.0 DKA0 HSZ22 d11x
dka100.1.0.6.0 DKA100 RRD42 4.5d
dka200.2.0.6.0 DKA200 HSZ22 d11x
dka300.3.0.6.0 DKA300 HSZ22 d11x
dka400.4.0.6.0 DKA400 HSZ22 d11x
dva0.0.0.0.1 DVA0
ewa0.0.0.11.0 EWA0 92-2B-34-D3-F5-2E
pka0.7.0.6.0 PKA0 SCSI Bus ID 7
>>>


Shows the three new disks DKA200, DKA300 and DKA400.


After booting Tru64:

bash-4.3# scu sh edt

CAM Equipment Device Table (EDT) Information:

Bus/Target/Lun Device Type ANSI Vendor ID Product ID Revision N/W

---

---

---

---

---

---

---
0 0 0 Direct SCSI-2 DEC HSZ22 d11x W
0 1 0 CD-ROM SCSI-2 DEC RRD42 4.5d W
0 2 0 Direct SCSI-2 DEC HSZ22 d11x W
0 3 0 Direct SCSI-2 DEC HSZ22 d11x W
0 4 0 Direct SCSI-2 DEC HSZ22 d11x W

bash-4.3#


But in hwmgr the following is shown:

bash-4.3# hwmgr show scsi

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH

---

26: 0 GOLIATH disk none 2 1 dsk0 [0/0/0]
27: 1 GOLIATH cdrom none 0 1 cdrom0 [0/1/0]
28: 2 GOLIATH disk none 0 3 dsk1 [0/2/0]
bash-4.3#


There's no trace of the new disks. Keep in mind this has been happening to me for years, it's not something new.

The shown excerpts are from one FreeAXP instance running on:


FreeAXP 4.0.0.653
Windows 10 Home
Desktop PC
8GB RAM
1TB SSD


The exact *same* problem occurs in an FreeAXP instance running on my laptop:


FreeAXP 3.0.0.620
Windows 10 Home
Lenovo Laptop
8 GB RAM
1TB SSD



Any suggestions how to make the new disks visible to Tru64?


Crusti

Since you are using 'hwmgr', this must be a V5.x release of Tru64. (what version is it ?)

Normally, I would expect V5 systems, especially later V5.1x systems, to pick up new disks automagically. However, it dosesn't/didn't always work that way.

Older releases often need a helping hand :

# hwmgr -scan scsi <<< scan the bus(ses) from a hw db perspective.
and
# dsfmgr -k <<< creates new /dev entries ...
# dsfmgr -v or dsfmgr -v -F <<< fixes/verifies they're all present
# hwmgr -view dev <<< should show the hw db view

Also, things behave differently, or are incomplete when running single-user. So those are best run from run level 2 or 3.

John M

Normally you'd see something like this :

# hwmgr -view dev
HWID: Device Name Mfg Model Location

---

4: /dev/kevm
25: /dev/disk/dsk0c DEC RZ28 bus-0-targ-0-lun-0
27: /dev/disk/cdrom0c DEC RRD44 bus-0-targ-4-lun-0
28: /dev/disk/dsk2c DEC RZ28 bus-0-targ-6-lun-0
# hwmgr -sho scsi

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH

---

25: 0 vectis disk none 2 1 dsk0 [0/0/0]
26: 1 vectis disk none 0 1 (null)
27: 2 vectis cdrom none 0 1 cdrom0 [0/4/0]
28: 3 vectis disk none 2 1 dsk2 [0/6/0]
29: 4 vectis disk none 0 1 (null)
30: 5 vectis cdrom none 0 1 (null)

This example has two driives and a CD, and shows 'null' entries for drive now deleted @ HWIDs 26, 29 and 30.

Finally, its probably paranoia on my part, but if you've set root's shell to something other than the 'default' /bin/sh, I'd change it back; to use other shells (eg. bash) run it as a sub-shell, never as root's login shell ... various scripts will break ...

John M

Hi there

Thanks for your reply, John M. I have been tinkering with this today and I solved the issue.

When adding disk images, the same serial numbers may get generated for these disks (or no serial number at all). As soon as there are two disks of the same type with the same serial number, they get recognized as only one disk with multiple paths.

To distinguish multipaths, add the -full option to hwmgr:


$ hwmgr show scsi -full
...
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH

---

29: 3 LALLO disk none 0 2 dsk2 [0/3/0]

WWID:0410001f:"DEC HSZ22 SRL0600"


BUS TARGET LUN PATH STATE

---

0 3 0 valid
0 5 0 valid

...
$

There are two disks actually, disk 0.3 with 2 GiB and disk 0.5 with 9Gib, but both have serial number SRL0600 and hence are considered to be the same disk.


Editing the serial_num field of the disk image in FreeAXP and entering a unique random string for every disk of the same type solves this issue:


# scu sh edt

CAM Equipment Device Table (EDT) Information:

Bus/Target/Lun Device Type ANSI Vendor ID Product ID Revision N/W

---

---

---

---

---

---

---
0 0 0 Direct SCSI-2 DEC RZ74 427H W
0 1 0 CD-ROM SCSI-2 DEC RRD42 4.5d W
0 2 0 Direct SCSI-2 DEC HSZ22 d11x W
0 3 0 Direct SCSI-2 DEC HSZ22 d11x W
0 4 0 Direct SCSI-2 DEC RZ28 D41C W
0 5 0 Direct SCSI-2 DEC HSZ22 d11x W

# hwmgr show scsi

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH

---

26: 0 LALLO disk none 2 1 dsk0 [0/0/0]
35: 1 LALLO cdrom none 0 1 cdrom0 [0/1/0]
36: 2 LALLO disk none 0 1 dsk1 [0/2/0]
37: 3 LALLO disk none 0 1 dsk2 [0/3/0]
38: 4 LALLO disk none 0 1 dsk3 [0/4/0]
39: 5 LALLO disk none 0 1 dsk4 [0/5/0]
#


I tested this on the desktop PC and laptop and now everything works fine.


Thank you!


Crusti

The serial number behavior is documented in section 5.4.1. of the Release Notes and section 7.7.6.4 of the User Guide.