Panic resource_list_alloc 7.2 stable

[John Baldwin]

On Wednesday 10 June 2009 1:15:16 pm M. Warner Losh wrote:
> In message: <200906101307.37181.jhb at freebsd.org>
>             John Baldwin <jhb at freebsd.org> writes:
> : On Wednesday 10 June 2009 12:45:03 pm Robert wrote:
> : > On Wed, 10 Jun 2009 10:38:36 -0400
> : > John Baldwin <jhb at freebsd.org> wrote:
> : > 
> : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote:
> : > > > On Mon, 8 Jun 2009 10:45:39 -0400
> : > > > John Baldwin <jhb at freebsd.org> wrote:
> : > > > 
> : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote:
> : > > > > > Greetings
> : > > > > > 
> : > > > > > This problem seems the same as this one from May of this year
> : > > > > > 
> : > > > > > 
> : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html
> : > > > > > 
> : > 
> : > <clip older message stuff>
> : > 
> : > > > > 
> : > > > I have installed 7.2 on the laptop because it would panic whenever
> : > > > going into multiuser. I would prefer to be on stable.
> : > > > 
> : > > > Here is dmesg.boot. I hope that is what you wanted.
> : > > 
> : > > Hmm, can you get the stack trace from the dump that you have?  I'm
> : > > curious which device driver is triggering the panic.
> : > > 
> : > 
> : > (kgdb) bt
> : > #0  doadump () at pcpu.h:196
> : > #1  0xc07e4b47 in boot (howto=260)
> : > at /usr/src/sys/kern/kern_shutdown.c:418 #2  0xc07e4e19 in panic
> : > (fmt=Variable "fmt" is not available. )
> : > at /usr/src/sys/kern/kern_shutdown.c:574 #3  0xc080d6f6 in
> : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180,
> : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290)
> : > at /usr/src/sys/kern/subr_bus.c:2739 #4  0xc06a2057 in
> : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3,
> : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290)
> : > at /usr/src/sys/dev/pci/pci.c:3586 #5  0xc080d57c in bus_alloc_resource
> : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295,
> : > count=1, flags=12290) at bus_if.h:263 #6  0xc058ef4c in
> : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180,
> : > callbacks=0xd528a9e4, argp=0xc2a65000)
> : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7  0xc058f91c in
> : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80)
> : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8  0xc076f26a in
> : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903
> : 
> : Hmmm, ok.  So the problem appears to be that the cardbus code that parses 
the 
> : CIS wants to allocate a resource belonging to a cardbus card device that 
has 
> : already been allocated by that device's driver.  Warner, what is the best 
way 
> : to handle this do you think?  Does the bus_alloc_resource() method for a 
> : cardbus bus need to proxy resource requests to the CIS resource perhaps?
> 
> I thought I already fixed this.  We snag the cardbus CIS now on attach
> rather than at open time.  We just need to MFC it.

Oh, ok, that would make sense.  Is it easy to merge to 7?

> The problem isn't that we're allocating a resource that the device
> owns, so much, as that there are technical hurdles to accessing the
> CIS after the initial parsing....

*nod*

-- 
John Baldwin