| Perhaps not the right conference for this, however, there is a more
general issue. O/S & Firmware matching.
VMS is implementing for V7.2 a firmware revision check that looks for
the minimum revision for the platform, and tells the user if they are
below the minimum revision (in fact, will refuse to run unless
explicitly overridden by the user).
However, to make things truly work, we are asking the firmware folks to
impose some new discipline on the version naming. That is, if the
major ident is used to indicate compatability changes, we can handle
both upgrade and downgrade issues. That is, we will know that the
firmware is compatable with a release because the major ident matches.
If the major ident is not the same, then we would know that the firmware
is not compatable with the version of the O/S.
So. Now that workstations has diffused the firmware folk into
individual hardware groups, who is the decision maker for AlphaStation
firmware issues? It would be nice if we can get this agreed to by both
the Server and Workstation groups.
|
|
Hi Fred,
I understand the Minimum version issue, but we have expereinced
issues that are related to maximum versions. Meaing, customer is on
Alphastation, AlphaServer, or older DEC3000's with OpenVMS V6.1 or
DUnix V3.2C and wanting to update to a current release of firmware, say
off the V3.8 AXP Firmware CD, then problems start. The problems I have
worked on both DUnix and OpenVMS are typically the Graphics options not
being seen, or malfunctioning in some way. We can resolve these issues
by having the customer downgrade their firmware back to where they were
prior to the upgrade to the most current release, or by having them
upgrade the Operating System. According to the Firmware Release Notes
for the systems I have checked, they support a wide range of Operating
systems, ie V6.1 - V7.1 for the AXP Firmware V6.9 on the DEC3000. So,
my questions are these...
1) Should the curent releases of Firmware work with older versions of
the OS ?
2) Is there any regression testing performed on systems with the
lastest firmware and older versions of the OS ?
Regards,
Dave Bechtold
DTN 343-1216
FYI
This particular customer issue noted in .0 is resolved. I found a V6.2
SYS$GXADRIVER image that worked with V6.1 OS.
Actually the SYS$GXADRIVER.EXE image ident info for the image that
worked follows.
image name: "SYS$GXADRIVER"
image file identification: "DW T6.2-950128"
image file build identification: "X5Z2-FT2-0000"
link date/time: 23-MAY-1995 13:02:58.57
linker identification: "T11-11"
I'm not sure where this image is from, it doesn't appear to be from the
VMS V6.2 kit. Maybe Open3D V2.5 or other source.
Also, I did find that the Server ACCVIO's but somehow recovers and
continues. I have placed the SERVER Log file info below.
DECW$SERVER_0_ERROR.LOG
This is the DECwindows X11 display server for OpenVMS AXP V6.1-940402
compiled on Apr 2 1994 at 12:12:02
Main address = 00032328
Activating extension image DECW$SVEXT_Adobe_DPS_Extension,
extension name: Adobe-DPS-Extension, entry address 0033C2A8
Activating extension image DECW$SVEXT_Xie,
extension name: Xie, entry address 004BE6D0
.
.
.
DECWINDOWS DigitalEquipmentCorp. AXP, Release 6.1
Shareable Image DDX GX, InitOutput loaded at 007DA000
sfbvmsScreenInit: Init SFB screen number 0
DEC-XTRAP: AddExtension assigned Major Opcode '137'
DEC-XTRAP: Vers. 3.3-0 successfully loaded
MultibufferExtensionInit: Drawlib not loaded.
5-FEB-1997 10:42:48.6 Calling the dispatcher...
5-FEB-1997 10:42:52.4 %SYSTEM-F-ACCVIO, access violation, reason
mask=04, virtual address=01FFF160, PC=00000004, PS=00000000
Request opcode 74 is ignored due to internal runtime error c for client
2 (#error = 1)
Mapped Images...
START END LENGTH IMAGE NAME
----- --- ------ ----------
10000 301ff 201ff DECW$SERVER_MAIN
32000 1a3bff 171bff DECW$SERVER_DIX
208000 2481ff 401ff DECW$SECURITY_VMS
1a4000 206410 62410 DECW$TRANSPORT_COMMON
80810310 8081c990 c680 SYS$BASE_IMAGE
7fde4000 7fe45fff 61fff DECC$SHR
7fbc4000 7fd15fff 151fff DPML$SHR
7fb44000 7fb75fff 31fff LIBOTS
7fae4000 7fb35fff 51fff LIBRTL
7fb84000 7fbb5fff 31fff CMA$TIS_SHR
80802ad8 808040b8 15e0 SYS$PUBLIC_VECTORS
33c000 4bd3ff 1813ff DECW$SVEXT_ADOBE_DPS_EXTENSION
4be000 58f3ff d13ff DECW$SVEXT_XIE
590000 5c03ff 303ff DECW$SVEXT_DEC_XTRAP
5c2000 6023ff 403ff DECW$SVEXT_MULTI_BUFFERING
604000 6645ff 605ff DECW$SERVER_DEC_3DLIB
668000 728bff c0bff DECW$TRANSPORT_DECNET
72a000 72b3ff 13ff DECC$MSG
72c000 7329ff 69ff SHRIMGMSG
734000 7441ff 101ff DECW$TRANSPORTMSG
746000 7863ff 403ff DECW$TRANSPORT_LOCAL
788000 7c83ff 403ff DECW$TRANSPORT_TCPIP
7da000 80a3ff 303ff DECW$SERVER_DDX_GX
80c000 86c9ff 609ff DECW$SERVER_DDX_SFB
86e000 8de9ff 709ff DECW$SERVER_DDX_CFB8
8e0000 9307ff 507ff DECW$SERVER_DDX_MFB
Exception Call stack dump follows:
PC IMAGE+offset of call
-- --------------------
841f4c DECW$SERVER_DDX_SFB + 35f4c
84785c DECW$SERVER_DDX_SFB + 3b85c
181688 DECW$SERVER_DIX + 14f688
e0e14 DECW$SERVER_DIX + aee14
daf38 DECW$SERVER_DIX + a8f38
b2f40 DECW$SERVER_DIX + 80f40
********** marking the end of call stack dump **********
********************************************************
5-FEB-1997 10:42:53.2 vmsScreenClose: Closing screen down
5-FEB-1997 10:42:53.3 DECWINDOWS DigitalEquipmentCorp. AXP, Release
6.1
Shareable Image DDX GX, InitOutput loaded at 007DA000
sfbvmsScreenInit: Init SFB screen number 0
DEC-XTRAP: AddExtension assigned Major Opcode '137'
DEC-XTRAP: Vers. 3.3-0 successfully loaded
MultibufferExtensionInit: Drawlib not loaded.
5-FEB-1997 10:42:54.8 Calling the dispatcher...
<End of info>
|
| Ah, that is what I am talking about. We have the technology to do
minimum revision checking today. However, what we do not have today
is the ability to do "compatability" testing. This is very visible
when customers try to down-rev the O/S.
The issue here is that to do this, you need to have the ability to
determine if the firmware version is compatable with the O/S. Because
currently the major ident has no rules (it can change on whim, for
instance because the minor ident was larger than 10), we cannot key on
the major ident for compatability.
If simple versioning rules are applied, where the major ident is
changed only when a incompatabilty occurs, and the minor ident is used
for changes that do not break compatabilty (new drivers, bugfixes,
etc). Then you will get what you are asking for. Not exactly "Max
Version" but "Compatable Version" support. Until then, all we can do
on the O/S side is minimum revision checking.
|
|
The answers to your 2 questions are:
1) Yes... but there are problems. The console group(s) have no
experience or mechanisms to support multiple streams, and ship
multiple versions. So, if for instance, a incompatable change
occurs in the firmware, they have no way to say, add a new boot
driver to the current firmware, and to a previous incompatable
version.
So, it's in everyones best interest to maintain backward
compatability if possible, and resist making incompatable changes.
2) No. I am not aware of any formal testing of arbitrary version
checking with different baselevels of the O/S and firmare. In
general, I believe only the shipping versions are checked.
|