Re: 6.0-current panic: loading radeon module

From: Martin Cracauer <cracauer_at_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....

Warner