6.0-current panic: loading radeon module
Eric Anholt
eta at lclark.edu
Sat Jun 18 01:24:34 GMT 2005
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 <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 ?? ()
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 at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
More information about the freebsd-current
mailing list