From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 01:24:34 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 32DD716A41C for ; Sat, 18 Jun 2005 01:24:34 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D850843D48 for ; Sat, 18 Jun 2005 01:24:32 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id j5I1Ns1n096241; Fri, 17 Jun 2005 18:23:54 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id j5I1NlNk096240; Fri, 17 Jun 2005 18:23:47 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Martin Cracauer In-Reply-To: <20050617194638.A13394@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> <20050617.152524.71154336.imp@bsdimp.com> <20050617173008.A11142@cons.org> <20050617184104.A12956@cons.org> <20050617194638.A13394@cons.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 17 Jun 2005 18:23:47 -0700 Message-Id: <1119057827.16634.1.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org, Warner Losh 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 01:24:34 -0000 On Fri, 2005-06-17 at 19:46 -0400, Martin Cracauer wrote: > 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 ?? () Assuming that those ??s are in the radeon module, this is a new backtrace to me. There's been one happening to some people where pmap_mapdev fails to allocate enough memory, which results in a panic, but I haven't been able to reproduce it here. My systems are working just fine on fresh -current :( -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org