Date: Sun, 14 May 1995 16:50:04 -0700 From: Pierre Beyssac <pb@fasterix.freenix.fr> To: freebsd-bugs Subject: kern/416: page fault in syscons.c:scopen() Message-ID: <199505142350.QAA06172@freefall.cdrom.com> In-Reply-To: Your message of Mon, 15 May 1995 01:43:24 %2B0200 <199505142343.BAA00550@fasterix.frmug.fr.net>
index | next in thread | previous in thread | raw e-mail
>Number: 416
>Category: kern
>Synopsis: page fault in syscons.c:scopen()
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs (FreeBSD bugs mailing list)
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun May 14 16:50:03 1995
>Originator: Pierre Beyssac
>Organization:
Pierre Beyssac
>Release: FreeBSD 2.0-BUILT-19950515 i386
>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.
>Audit-Trail:
>Unformatted:
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505142350.QAA06172>