From owner-freebsd-current@FreeBSD.ORG Fri Apr 15 22:42:28 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 6073F16A4CE for ; Fri, 15 Apr 2005 22:42:28 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D14FE43D58 for ; Fri, 15 Apr 2005 22:42:27 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11562 invoked from network); 15 Apr 2005 22:42:27 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 15 Apr 2005 22:42:27 -0000 Received: from [131.106.58.175] (p181.n-lapop01.stsn.com [12.129.240.181]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3FMgKnv047772; Fri, 15 Apr 2005 18:42:21 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andre Guibert de Bruet Date: Fri, 15 Apr 2005 18:23:38 -0400 User-Agent: KMail/1.8 References: <20050415063120.G93987@lexi.siliconlandmark.com> <17e130c77e0927c73945b43884069d10@FreeBSD.org> <20050415155645.H93987@lexi.siliconlandmark.com> In-Reply-To: <20050415155645.H93987@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504151823.39629.jhb@FreeBSD.org> 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 22:42:28 -0000 On Friday 15 April 2005 04:44 pm, Andre Guibert de Bruet wrote: > On Fri, 15 Apr 2005, John Baldwin wrote: > > On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote: > >> (kgdb) bt > > > > >> #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. > > This vm_map_lookup call would be performed before the callout that gets us > here, right? Yes. it's earlier in the vm_fault() function. > >> #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. > > tf_eip in #15 points to i386/i386/support.s:490. This would seem to > indicate that frame #16 is our call to generic_bcopy... Oh, I know it's calling bcopy(). My point is that I don't see anything obviously wrong with the call to bcopy() in vga_txtdraw(). > How do we get from ogetkerninfo to generic_bcopy? I don't see ogetkerninfo > getting called anywhere in the syscons driver. As you suggested, it looks > like we're overlapping a vm fault over our humble syscons code path. The ogetkerninfo is a red herring because gdb doesn't know how to handle trap frames correctly. > Where to from here? Well, if you can reproduce this you can start looking at what is being passed to bcopy() in the vga function to try and figure out what is happening. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org