| Hi Jean-Pierre,
Yep, V4.3 is a vintage version!
Not sure I know an answer, but here are a few questions I would ask:
1) What is the rtVAX-300 in? A KAV30, or third party like the AEON
VME300?
2) Have they written their own VMEbus backplane network driver? Or
are they simply writing data to the VMEbus at the time they are doing
a ker$send to a remote system across the ether?
3) Do they have the local debugger built in? I would make sure they
do as this may give you a better glimpse at exceptions raised while
at elevated ipl. Make sure there is a physical console attached.
4) The KAV30 support was integrated into VAXELN V4.4 and had numerous
changes made to the KAV30 kernel at that time. (Before then there
was the optional KAV30 Toolkit). I know changes were made to AST
handling and the like.
5) Does anything else continue to run at the time of the "hang"?
6) Is it visible on the network (e.g., NCP> TELL mynode SHOW EXEC)?
7) Are they using Internet services? If so, can they ping the node?
8) Are they elevating IPL anywhere in their code?
9) Does a VMEbus analyzer show anything abnormal when they do
writes to the VMEbus?
Perhaps some of these ideas may shed some more light on the problem.
Regards,
Alan
|
| Solution :
Edit ELN$:EZPROCESS.PAS
const
.
.
.
datalink_desc_max = (rcv_desc_max * 10) + xmt_desc_max;
--
.
.
.
Search procedure transmit_message
Replace :
if desc = nil
then
goto return;
by
if desc = nil
then
begin
allocate_buffer(desc, cb);
if desc = nil
then
goto return;
end;
And this does the trick for the customer (the target has run over 22
hours without failures). They stress the EZDRIVER, hence the 10
multiplier in datalink_desc_max.
Best regards,
Philippe
|