From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 05:32:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG 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 D6DC316A41C for ; Sat, 18 Jun 2005 05:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FFAC43D49 for ; Sat, 18 Jun 2005 05:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5I5UtUZ090683; Fri, 17 Jun 2005 23:30:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Jun 2005 23:30:55 -0600 (MDT) Message-Id: <20050617.233055.41723867.imp@bsdimp.com> To: cracauer@cons.org From: Warner Losh In-Reply-To: <20050617194638.A13394@cons.org> References: <20050617173008.A11142@cons.org> <20050617184104.A12956@cons.org> <20050617194638.A13394@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 18 Jun 2005 05:32:44 -0000 From: Martin Cracauer Subject: Re: 6.0-current panic: loading radeon module Date: Fri, 17 Jun 2005 19:46:39 -0400 > Hmmmmm, this doesn't look quite right. I am probably missing the > debug info from within the radeon module. But since I don't have the > base address for the module I'm not sure how to add its symbols when > debugging the vmcore. > > Let me know how useful this is. > > Martin > > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc052db30 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 > #2 0xc052ddf4 in panic (fmt=0xc06caa94 "from debugger") > at ../../../kern/kern_shutdown.c:553 > #3 0xc0450711 in db_panic (addr=-1066780860, have_addr=0, count=-1, > modif=0xf5a3d770 "") at ../../../ddb/db_command.c:435 > #4 0xc04506a8 in db_command (last_cmdp=0xc0737444, cmd_table=0x0, > aux_cmd_tablep=0xc06fcdf4, aux_cmd_tablep_end=0xc06fcdf8) > at ../../../ddb/db_command.c:349 > #5 0xc0450770 in db_command_loop () at ../../../ddb/db_command.c:455 > #6 0xc0452305 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 > #7 0xc05462df in kdb_trap (type=12, code=0, tf=0xf5a3d904) > at ../../../kern/subr_kdb.c:471 > #8 0xc06a5bcb in trap_fatal (frame=0xf5a3d904, eva=3221094400) > at ../../../i386/i386/trap.c:826 > #9 0xc06a593f in trap_pfault (frame=0xf5a3d904, usermode=0, eva=3221094400) > at ../../../i386/i386/trap.c:749 > #10 0xc06a5561 in trap (frame= > {tf_fs = -1067122680, tf_es = -1056702424, tf_ds = 40, tf_edi = 256, tf_esi = -533393408, tf_ebp = -173811368, tf_isp = -173811408, tf_ebx = 130740224, tf_edx = 1015808, tf_ecx = -134217728, tf_eax = -533393149, tf_trapno = 12, tf_err = 2, tf_eip = -1066780860, tf_cs = 32, tf_eflags = 590470, tf_esp = 0, tf_ss = -137695232}) at ../../../i386/i386/trap.c:439 > ---Type to continue, or q to quit--- > #11 0xc069538a in calltrap () at ../../../i386/i386/exception.s:139 > #12 0xc0650008 in ufs_setattr (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:564 > #13 0xc069fe39 in nexus_activate_resource (bus=0xc2703d00, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at ../../../i386/i386/nexus.c:419 > #14 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #15 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #16 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #17 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #18 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #19 0xc04addaa in pci_alloc_resource (dev=0xc2821080, child=0xc2821000, > type=3, rid=0xf5a3db2c, start=0, end=4294967295, count=1, flags=6) > at ../../../dev/pci/pci.c:1753 > #20 0xc0543a88 in bus_alloc_resource (dev=0x0, type=3, rid=0xf5a3db2c, > start=0, end=4294967295, count=1, flags=6) at bus_if.h:262 > #21 0xc2b9a273 in ?? () This is your problem. dev == 0 isn't allowed here. I'm surprised it gets as far as it does. But I'm not entirely sure I believe it because dev is supposed to have its parent taken to walk up the tree. And there's no way that ufs attr is being called from nexus resource manager.... Warner