| Author |
FreeAXP not detecting disks |
fdsaiz
Member
Posts: 9
Joined: 23.07.20 |
| Posted on March 27 2021 22:12 |
|
|
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 |
|
|
| Author |
RE: FreeAXP not detecting disks |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
| Posted on March 28 2021 05:42 |
|
|
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
|
|
|
| Author |
RE: FreeAXP not detecting disks |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
| Posted on March 28 2021 05:46 |
|
|
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. |
|
|
| Author |
RE: FreeAXP not detecting disks |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
| Posted on March 28 2021 05:49 |
|
|
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 |
|
|
| Author |
RE: FreeAXP not detecting disks |
fdsaiz
Member
Posts: 9
Joined: 23.07.20 |
| Posted on March 29 2021 01:10 |
|
|
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 |
|
|
| Author |
RE: FreeAXP not detecting disks |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on March 29 2021 04:25 |
|
|
|
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. |
|
|
| Author |
RE: FreeAXP not detecting disks |
fdsaiz
Member
Posts: 9
Joined: 23.07.20 |
| Posted on March 29 2021 05:13 |
|
|
|
Bruce Claremont wrote:
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.
Hi Bruce
That's absolutely correct. The problem is that serial numbers are not generated for each disk image created and thus you end up with the "shadowed" disks (they are there, but shadowed by the first disk with the repeated serial number).
Here you have a screenshot of an FreeAXP instance running with 3 newly created disks (HSZ22) and with the same serial number "SRL0600":
https://ibb.co/g6QqSkb
So if using Tru64 starting from version 5.X, I need to manually set a unique serial number to each disk image. Then everything is ok.
Crusti |
|
|
| Author |
RE: FreeAXP not detecting disks |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on March 30 2021 04:12 |
|
|
|
Avanti 3.0.0.620 and higher addressed the duplicate serial number generation issue. What version of FreeAXP are you running? |
|
|
| Author |
RE: FreeAXP not detecting disks |
fdsaiz
Member
Posts: 9
Joined: 23.07.20 |
| Posted on March 30 2021 06:06 |
|
|
|
Bruce Claremont wrote:
Avanti 3.0.0.620 and higher addressed the duplicate serial number generation issue. What version of FreeAXP are you running?
I'm running the latest version, 4.0.0.653. |
|
|
| Author |
RE: FreeAXP not detecting disks |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on March 31 2021 04:30 |
|
|
|
Just to be clear, you are using FreeAXP to generate the disks, correct? I.E. You define a new disk image within the FreeAXP configuration utility. When launched, FreeAXP creates the disk image file. |
|
|
| Author |
RE: FreeAXP not detecting disks |
fdsaiz
Member
Posts: 9
Joined: 23.07.20 |
| Posted on March 31 2021 08:54 |
|
|
|
Bruce Claremont wrote:
Just to be clear, you are using FreeAXP to generate the disks, correct? I.E. You define a new disk image within the FreeAXP configuration utility. When launched, FreeAXP creates the disk image file.
Yes. If memory serves, the exact procedure was:
*Run FreeAXP
*Add new root disk (disk 0.0) as HSZ22 with autocreate
*Add CDROM drive (virtual Windows drive with Tru64 V5.1.B-3)
*Add 3 more disks as HSZ22 with autocreate
*Start the emulator hitting the "Play" button on top.
Then just boot from the CDROM drive, install Tru64 and when booted for the first time, the last 3 disks appear with the same serial number. |
|
|
| Author |
RE: FreeAXP not detecting disks |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on April 01 2021 02:12 |
|
|
|
Thanks. Our documentation needs some improvement regarding Tru64 UNIX and V5 disk serial numbers. |
|
|
| Author |
RE: FreeAXP not detecting disks |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
| Posted on May 03 2021 05:20 |
|
|
Tru64 UNIX V5 Disk Serial Number Issue
Older versions of Tru64 UNIX do not care about disk serial numbers. Tru64 UNIX V5 does care. V5 wants unique serial numbers for each disk.
Avanti deals with this issue in two ways.
1) By default, if a serial number field is left blank in the Avanti configuration file, a unique serial number is generated for the disk using the format SRL0<hex-pci-id>0<hex-scsi-id>.
2) The user can enter a unique serial number in the serial number field of a disk's advanced properties using the Configuration Utility. Disk serial number can by any unique value except in the case of HSZ22 disks. More on HSZ disks below.
NOTE: Once a Tru64 UNIX configuration is built, do not modify the disk serial numbers. Doing so may cause Tru64 UNIX to think a disk has been changed out and invalidate the configuration.
The exception to the above rule is HSZ disks. HSZ disks require a specially formatted serial number. Furthermore, HSZ disk uniqueness is further defined by the disk size. Thus, it is possible to have three HSZ disks of different sizes with duplicate serial numbers and V5 will treat them as unique disks. Three HSZ disks of the same size with duplicate serial numbers will be treated as three paths to a single volume, which ends badly. The same scenario is not a problem on V3 and V4 because they do not support multi-pathing.
When creating a custom disk size using the Avanti Configuration Utility, the disk type is assigned to HSZ22. If the disk serial number is left blank in the configuration file, FreeAXP assigns a fixed serial number to the HSZ disk: 00000002198505070c012c21bba00300. The structure of this serial number is important, as V5 recognizes it as a valid HSZ disk.
Unfortunately, if multiple HSZ disks are defined with blank serial number fields, they all get the same serial number: 00000002198505070c012c21bba00300. This is a bug in Avanti. This bug was not uncovered for many years, as HSZ disks with different sizes still appear unique to V5. It was only when a user defined several HSZ disks with the same size and blank serial number fields that the problem was diagnosed.
Automating a fix for this bug is problematic due to the large number of existing Tru64 UNIX installations. Hence, the fix for the HSZ duplicate serial number issue is a manual one. Here are the options:
- Vary the size of each HSZ disk and leave the serial number field blank. As long as all HSZ disk sizes are unique, V5 will accept them, even with duplicate serial numbers.
- Document the serial numbers used on a legacy HSZ installation and use them in the serial number fields of the Avanti configuration. |
|
|
