From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.att,comp.terminals.tty5620
Subject: Re: layers panics 3B2-400
Date: 3 Oct 92 22:29:05 GMT
Followup-To: comp.sys.att
Organization: U.S. Army Ballistic Research Lab, APG MD.

In article <1992Oct2.004546.227@kopachuk.uucp> dcb@kopachuk.uucp (David Breneman) writes:
>I'm in the process of setting up a 5620 terminal on a 3B2-400
>running SVR3.1.  I've loaded release 2.0 of the DMD Core Utilities.
>/usr/dmd/bin is in my PATH.  When I enter ``layers'', the
>screen on the 5620 goes all-green, then textured-green, then
>I get this error message on the console:
>TRAP
>proc = 4022A150 psw = 1472B
>pc = 400223C1
>PANIC: KERNEL MMU FAULT (F_ACCESS)
>SYSTEM FAILURE, etc.

(You also need to set the environment variable DMD=/usr/dmd.)

The change in 5620 screen indicates that the terminal was placed
into layers (xt) mode.  Certainly the host kernel "should" never
panic..  "layers" makes use of the following relevant kernel
facilities:
	terminal handler -- needs to be placed in 8-bit transparent
	mode for the xt/download protocol (5620 needs to match, and
	RECEIVE FLOW should be OFF).
	xt multiplexed pseudodevice driver -- provides a packet
	protocol with 7 data channels and 1 control channel multiplexed
	onto the original tty device.  The protocol includes checksums
	and error recovery.  The xt driver is intimately dependent on
	the particular release of the kernel and you should NOT replace
	whatever came with your system with the version from the Core
	package.
	ioctls -- actually handled by the xt driver, there are a few
	special ioctls that "layers" uses to control xt operation.
"layers" also will use "32ld" (or possibly "dmdld") to download
terminal-resident process images associated with windows (overriding
the default resident terminal emulator).

>I currently have MAXUP set at 25 in the kernel, and the documentation
>says layers can generate more than 25 processes, but would this
>cause the system to panic?

No, and besides "layers" does not generate extra processes until you
open windows for them.

>Also, when I look in the /dev/xt >directory, only devices 004 005 006
>and 007 are owned by me.  The others are still owned by root.

It's puzzling that any of them are owned by your UID.  That would
imply that "layers" opened several windows before dying.  These
should all be changed back to "root".  If you have a .mpxrc, .layersrc,
or other initial window configuration file, temporaily rename it to
something innocuous.  Some versions of "layers" may insist on creating
an initial window, but if yours doesn't then you will obtain further
evidence about just where along the process your kernel dies.

>I can't find (F_ACCESS) in any of my documentation.

Me either, but it sounds a lot like what would be SIGSEGV in user mode,
i.e. an invalid memory access attempt.  That would imply some error in,
most likely, the xt driver code, perhaps an incompatibility with the
current release of the rest of the kernel (especially the tty subsystem).

>BTW, all the demos run fine.  Anybody know what's going on here?

The standalone demos do not use the xt driver.  Standalone downloads
occur via a different protocol on the original tty port, starting
with a special escape sequence.