>Number:         4174
>Category:       port-pmax
>Synopsis:       starting X on pmax using serial console panics kernel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 27 19:20:02 1997
>Last-Modified:
>Originator:     Jonathan Stone
>Organization:
	
>Release:        1997-09-01
>Environment:
	
System: NetBSD Reno.DSG.Stanford.EDU 1.2G NetBSD 1.2G (GENERIC) #19: Sat Aug 30 01:09:13 PDT 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax


>Description:
	starting X on pmax using serial console panics kernel.

>How-To-Repeat:
	set up a decstation with NetBSD with both a framebufer,
	mouse, and keyboard.  
	Change the PROM evinroinment variable to use  a serial console
	(e.g., "setenv console s" on a 5000 series machine.)
	attach a serial console.
	Boot the system.
	Then start an X server (assuming that fonts, etc. are proplery
	configured).
	The kernel panics when the Xserver attempts to mmap() the
	framebuffer and shared-event X input queue.

>Fix:
	A work-around  is to not use the serial console on
	a headful machine. I seem to be the only one who runs
	into this, when doing Xws-compatiblity  hacking.

	The kernel stack traceback shows that the Xserver's mmap()
	has gone off into non-framebuffer-land.
	I guess checking the  rcons init code is the first step.

	Maybe the framebuffer mmap() code is blindly using
	state set up by rcons (which is done only for framebuffer
	consoles)?
>Audit-Trail:
>Unformatted: