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>
next in thread | previous in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505142350.QAA06172>