Date: Fri, 24 Jun 2005 16:41:24 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@freebsd.org Cc: cracauer@cons.org, Warner Losh <imp@bsdimp.com> Subject: Re: 6.0-current panic: loading radeon module Message-ID: <200506241641.25433.jhb@FreeBSD.org> In-Reply-To: <20050617.233055.41723867.imp@bsdimp.com> References: <20050617173008.A11142@cons.org> <20050617194638.A13394@cons.org> <20050617.233055.41723867.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 18 June 2005 01:30 am, Warner Losh wrote:
> From: Martin Cracauer <cracauer@cons.org>
> 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 <return> to continue, or q <return>
> > 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....
gdb's just confused again. Note that the dev for pci_alloc_resource() is the
same as the child for nexus_activate_resource().
line 419 of nexus.c is a call to pmap_mapdev(). We've gotten pmap_mapdev()
panics at work if the AGP aperture was cranked up a lot (256 MB for example)
and there wasn't a lot of contiguous KVA available. That was on 4.x though.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506241641.25433.jhb>