From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 16:53:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 381AD16A4CF for ; Fri, 15 Apr 2005 16:53:54 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EA5243D2F for ; Fri, 15 Apr 2005 16:53:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 27464 invoked from network); 15 Apr 2005 16:53:53 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 15 Apr 2005 16:53:51 -0000 Received: from [131.106.58.7] (p180.n-lapop01.stsn.com [12.129.240.180]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3FGrfDl045911; Fri, 15 Apr 2005 12:53:44 -0400 (EDT) (envelope-from jhb@FreeBSD.org) In-Reply-To: <20050415063120.G93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17e130c77e0927c73945b43884069d10@FreeBSD.org> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Fri, 15 Apr 2005 12:53:40 -0400 To: Andre Guibert de Bruet X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 16:53:54 -0000 On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: > Hi, > > While attempting to change from 90x60 to VESA_132x60... > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc051d257 > stack pointer = 0x28:0xe900ca18 > frame pointer = 0x28:0xe900ca38 > 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 = 85 (swi4: clock sio) > [thread pid 85 tid 100076 ] > Stopped at _mtx_lock_flags+0x47: cmpl $0xc0708208,0(%ebx) > db> tr > Tracing pid 85 tid 100076 td 0xc5014d80 > _mtx_lock_flags(0,0,c06e611e,127,e900cac4) at _mtx_lock_flags+0x47 > vm_fault(c1059000,c0100000,2,0,c5014d80) at vm_fault+0x28e > trap_pfault(e900cb9c,0,c0100000,2,c0100000) at trap_pfault+0x166 > trap(c5010008,28,c0530028,c0100000,c7084000) at trap+0x350 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06919b6, esp = 0xe900cbdc, ebp = 0xe900cc00 --- > generic_bcopy(c537c828,0,c537c80c,0,c0000,c06d240e,18a) at > generic_bcopy+0x1a > vga_txtdraw(c537c800,0,c0000,0,5cbf1d40) at vga_txtdraw+0xee > scrn_update(c537c800,1,c0730120,8,c06d4127) at scrn_update+0x2b2 > scrn_timer(c50d7000,0,c06d4127,107,c067317d) at scrn_timer+0x239 > softclock(0,0,c06d0909,256,c07300e0) at softclock+0x242 > ithread_loop(c5018400,e900cd38,c06d06f4,30c,c5018400) at > ithread_loop+0x159 > fork_exit(c0510b8f,c5018400,e900cd38) at fork_exit+0xc2 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe900cd6c, ebp = 0 --- > db> ps > -- snip-- > 85 c50367f0 0 0 0 000020c [CPU 0] swi4: clock sio > -- snip -- > > I have both the debug kernel and a 3.5GB memory dump on hand, in case > there is additional information that I haven't listed in this email > that may aid in fixing this issue. > > The EIP points to: > > (gdb) l *0xc051d257 > 0xc051d257 is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:268). > 263 void > 264 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int > line) > 265 { > 266 > 267 MPASS(curthread != NULL); > 268 KASSERT(m->mtx_object.lo_class == > &lock_class_mtx_sleep, > 269 ("mtx_lock() of spin mutex %s @ %s:%d", > m->mtx_object.lo_name, > 270 file, line)); > 271 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER > | LOP_EXCLUSIVE, > 272 file, line); > > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0526951 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:397 > #2 0xc0526cdd in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:553 > #3 0xc045026d in db_fncall (dummy1=1016, dummy2=0, dummy3=3, > dummy4=0xe900c820 "\f") at /usr/src/sys/ddb/db_command.c:531 > #4 0xc045001c in db_command (last_cmdp=0xc0728064, cmd_table=0x0, > aux_cmd_tablep=0xc06f2678, aux_cmd_tablep_end=0xc06f267c) > at /usr/src/sys/ddb/db_command.c:349 > #5 0xc045010d in db_command_loop () at > /usr/src/sys/ddb/db_command.c:455 > #6 0xc0451f9d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:221 > #7 0xc05432f5 in kdb_trap (type=0, code=0, tf=0xe900c9d8) > at /usr/src/sys/kern/subr_kdb.c:421 > #8 0xc0693d09 in trap_fatal (frame=0xe900c9d8, eva=0) > at /usr/src/sys/i386/i386/trap.c:801 > #9 0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:724 > #10 0xc06935f8 in trap (frame= > {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi = > -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252, > tf_ebx = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368, > tf_trapno = 12, tf_err = 0, tf_eip = -1068379561, tf_cs = 32, > tf_eflags = 66178, tf_esp = -1067131464, tf_ss = -1056600064}) at > /usr/src/sys/i386/i386/trap.c:414 > #11 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0xc0510008 in idle_setup (dummy=0x0) at > /usr/src/sys/kern/kern_idle.c:89 > #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048, > fault_type=2 '\002', fault_flags=0) at > /usr/src/sys/vm/vm_fault.c:295 You have a truly unique nested panic here that I haven't seen in a long time. Somehow vm_map_lookup() is returning success, but it is setting fs.first_object to NULL. > #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0, > eva=3222274048) > at /usr/src/sys/i386/i386/trap.c:713 > #15 0xc06935f8 in trap (frame= > {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi = > -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp = > -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488, > tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962, > tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at > /usr/src/sys/i386/i386/trap.c:414 > #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #17 0xc5010008 in ?? () > #18 0x00000028 in ?? () > #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000) > at /usr/src/sys/kern/kern_sysctl.c:1440 > #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432, > flip=0) > at /usr/src/sys/dev/syscons/scvgarndr.c:196 I'm not sure why you are bcopy'ing a bad KVA here. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org