| A long time ago, we received a warning about vms 5.4-3
and the DEMFA. As it seems to be similar, you could check
this mail.
Hope this helps
Patrick
From: VMSINT::BECKER 10-OCT-1991 08:23:25.87
To: DELNI::G_NIELSEN
CC: GAMACHE,PANNER,SALKEWICZ
Subj: Problem w/ 5.4-3 and DEMFA, kit available, need you to distribute
George,
A problem has been discovered with V5.4-3 and FXDRIVER/DEMFA.
It is a VMS system bug, rather than an FXDRIVER or DEMFA problem.
It results in a system crash. The fix is available as a set of
images, all of which take the form SYSLOAxxx.EXE. These SYSLOAs
are for 6000/9000 class machines running V5.4-3. These images have
been put into a kit for installation on a V5.4-3 system. The kit is
available on the Enet as:
Directory BULOVA::SYS$KITS:[VMS0543]
FXFIX.A;2 882
Total of 1 file, 882 blocks.
Any customer running V5.4-3 and DEMFA should get these images. The
VMS SSB submission for V5.4-3 is history, so there is no way to
make the distribution of these images "easy" from the SSB. We need
to get the word out through all the support channel. Feel free to
forward this.
Since the problem only exists for the customers running the
DEMFA, we would like to propose that these images somehow be
distributed with the DEMFA for the time being. Will you please make
this happen?
The nature of the problem is that FXDRIVER needs to allocate
a seperate page from the System Control Block. This page is used
to configure the interrupt vectors for the DEMFA which do not work
with other devices we suppport. The SYSLOA for a given machine
initializes a data structure cell with the address of a routine
FXDRIVER can call to get this special SCB page allocated. The problem
is that under V5.4-3, the memory that holds the routine that FXDRIVER
wants to call can be deallocated and reused. The new SYSLOAs have that
routine moved to where it can't be deallocated. The crashes are
fairly random, but most have the FXDRIVER call through the
data structure left hanging on the stack. What I mean is there will
be a return address to FXDRIVER on the stack and the instruction
before that return address is where the trouble starts and looks like:
FXDRIVER+????? JSB @28(R0)
This may or may not be at the very top of the stack. It all
depends on what the (new and random) code/data in that memory is/does.
It is possible that the stack contents could get destroyed as well,
and that this hint would not apply, if for example the first thing
that the "random" code does is POP a bunch of stuff off the stack.
Please let us know ASAP if you believe you will have
difficulties in distributing this kit.
Thanks.
Amy
|