Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!AC.UK!SYSMGR%UK.AC.KCL.PH.IPG
From: SYSMGR%UK.AC.KCL.PH.IPG@AC.UK.UUCP
Newsgroups: mod.computers.vax
Subject: YFDRIVER etc.
Message-ID: <8702171229.AA02894@ucbvax.Berkeley.EDU>
Date: Tue, 17-Feb-87 07:30:59 EST
Article-I.D.: ucbvax.8702171229.AA02894
Posted: Tue Feb 17 07:30:59 1987
Date-Received: Wed, 18-Feb-87 03:26:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 28
Approved: info-vax@sri-kl.arpa

>> VMS wizards help ... system crashes using VAXNET ...
 
> ... VAXNET is the culprit ...
 
Unless VAXNET uses $CMKRNL privelage, this can't be the case. The problem
is that VMS crashes on the interrupt stack at IPL 4 with YFDRIVER addresses on
the stack. Unless the user program is interfering with the device database
or suchlike, there must be either a hardware problem or a bug in VMS
in YFDRIVER or TTDRIVER.
 
Unfortunately, the hardware is an Emulex DHV11 look-alike, which leads to
the classic finger-pointing situation between two companies who don't like
each other. What I'd do is get hold of a real DEC DHV11 and see if the
problem goes away. If it does, the Emulex board is faulty (or, worse,
doesn't properly emulate the DEC product). If you can still crash VMS
using DEC hardware, SPR it (and keep on at DEC until they fix it).
 
There was a bug in VMS 4.2 TTDRIVER which caused this sort of problem, fixed
in 4.3. I was writing a pseudoterminal driver at the time and took a lot
of time to find the exact problem. It would not surprise me at all
if there are other similar bugs still lurking in DECs terminal drivers. I'm
still on VMS 4.3 so I can't investigate the problem any further.
 
Nigel Arnot (Dept. Physics, Kings college, Univ. of London;  U.K)
 
Bitnet/NetNorth/Earn:   sysmgr@ipg.ph.kcl.ac.uk (or) sysmgr%kcl.ph.vaxa@ac.uk
       Arpa         :   sysmgr%ipg.ph.kcl.ac.uk@ucl-cs.arpa