From pb@fasterix.freenix.fr  Sun May 14 16:46:17 1995
Received: from jabba.fdn.org (jabba.fdn.org [193.55.4.70])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA05831
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 14 May 1995 16:46:14 -0700
Received: (from uucp@localhost) by jabba.fdn.org (8.6.8/8.6.9) with UUCP id BAA25880 for FreeBSD-gnats-submit@freebsd.org; Mon, 15 May 1995 01:46:09 +0200
Received: (pb@localhost) by fasterix.frmug.fr.net (8.6.11/fasterix-941011) id BAA00550; Mon, 15 May 1995 01:43:24 +0200
Message-Id: <199505142343.BAA00550@fasterix.frmug.fr.net>
Date: Mon, 15 May 1995 01:43:24 +0200
From: Pierre Beyssac <pb@fasterix.freenix.fr>
Reply-To: pb@fasterix.freenix.fr
To: FreeBSD-gnats-submit@freebsd.org
Subject: page fault in syscons.c:scopen()
X-Send-Pr-Version: 3.2

>Number:         416
>Category:       kern
>Synopsis:       page fault in syscons.c:scopen()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    sos
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 14 16:50:03 1995
>Closed-Date:    Fri Jun 21 00:37:56 PDT 1996
>Last-Modified:  Fri Jun 21 00:39:22 PDT 1996
>Originator:     Pierre Beyssac
>Release:        FreeBSD 2.0-BUILT-19950515 i386
>Organization:
Pierre Beyssac
>Environment:

	Current kernel.

>Description:

Page fault line 362 of syscons.c :

    tp->t_state |= TS_CARR_ON;
    tp->t_cflag |= CLOCAL;
    if (!console[minor(dev)])
--->	console[minor(dev)] = alloc_scp();
    return((*linesw[tp->t_line].l_open)(dev, tp));

I can't figure out why writing, not reading console[minor(dev)], triggers
the page fault. Maybe the value of minor(dev) is clobbered when returning
from alloc_sp(), because it is cached in register esi. Here's the relevant
disassembly :

0xf0189e44 <scopen+200>:	andl   $0xffff00ff,%esi
0xf0189e4a <scopen+206>:	cmpl   $0x0,0xf01a10cc(,%esi,4)
0xf0189e52 <scopen+214>:	jne    0xf0189e60 <scopen+228>
0xf0189e54 <scopen+216>:	call   0xf018d4b0 <alloc_scp>
0xf0189e59 <scopen+221>:	movl   %eax,0xf01a10cc(,%esi,4)
0xf0189e60 <scopen+228>:	movl   0x54(%ebx),%eax

panic: page fault
#3  0xf016f850 in trap_pfault (frame=0xefbffd34, usermode=0)
    at ../../i386/i386/trap.c:610
#4  0xf016f517 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 3079, 
      tf_esi = 7, tf_ebp = -272630400, tf_isp = -272630436, 
      tf_ebx = -263412224, tf_edx = 0, tf_ecx = 16000, tf_eax = 0, 
      tf_trapno = 12, tf_err = 2, tf_eip = -266935425, tf_cs = 8, 
      tf_eflags = 66050, tf_esp = -266808025, tf_ss = 0})
    at ../../i386/i386/trap.c:290
#5  0xf0168631 in calltrap ()
#6  0xf0189e59 in scopen (dev=3079, flag=3, mode=8192, p=0xf0518900)
    at ../../i386/isa/syscons.c:362
#7  0xf016829f in cnopen (dev=3079, flag=3, mode=8192, p=0xf0518900)
    at ../../i386/i386/cons.c:129

(note that the panics don't always occur on dev=3079. The previous
one was with dev=3077).

console[0..7]:
{0xf01a0fa4, 0x0, 0xf04caa00, 0x0, 0xf04ca800, 0x0, 0x0, 0x0}

Note also that the above stack dump might be truncated, because
it does not quite match the following panic message which indicates
an address in bzero().

Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0x0
fault code		= supervisor write, page not present
instruction pointer	= 0x8:0xf016e37f
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 226 (getty)
interrupt mask		= 

>How-To-Repeat:

Configure a kernel with syscons and MAXCONS=8
Configure /etc/ttys with 8 gettys on ttyv0-7.
Reboot.
About half of the time when init starts the gettys, you will
get a panic on one of the scopen().

>Fix:

Removing one of the gettys _seems_ to be a good workaround. Not a fix,
obviously.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->sos 
Responsible-Changed-By: pst 
Responsible-Changed-When: Thu Feb 8 11:23:20 PST 1996 
Responsible-Changed-Why:  
State-Changed-From-To: open->closed 
State-Changed-By: sos 
State-Changed-When: Fri Jun 21 00:37:56 PDT 1996 
State-Changed-Why:  

Actually this has been fixed looong ago, I think it was an 
intermittent error between updates of different parts of the 
kernel. 
>Unformatted:


