Re: panic: resource_list_add: resource entry is busy
On May 23, 2014, at 8:07 AM, John Baldwin wrote: > On Monday, May 19, 2014 4:12:50 pm Hans Petter Selasky wrote: >> On 05/18/14 23:03, Hans Petter Selasky wrote: >>> Hi, >>> >>> First call: >>> >>> resource_list_add: >> >> Hi, >> >> It appears that the /dev/pccard.X is opened and reading some CIS data >> from the device before any driver has been attached. The attached patch >> solves the panic I've seen. Not sure if the patch is correct. > > Oops, your patch was dropped in my reply, but it just disables > pccard_scan_cis() while a device is probing. Hmmm, that seems like it would break PC Card probing entirely… Otherwise, how would we get here? The stack traces earlier in the thread suggest that would be the case…. What’s the other thing reading /dev/pccard.X though? > Warner, the issue here is that pccard_scan_cis() can do a > bus_alloc_resource() > for SYS_RES_MEMORY rid 0 of a pccard device concurrently with > pccard_function_init(). Hans patch might be along the right track, though > we might want to make /dev/pccard.X block until pccard_function_init() > finishes rather than causing pccard_scan_cis() to fail. What do you think? Yes. I’d say it a bit differently. Only one pccard_scan_cis should be in flight at a time. http://people.freebsd.org/~imp/patch-queue/cismtx should do the trick. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: panic: resource_list_add: resource entry is busy
On Monday, May 19, 2014 4:12:50 pm Hans Petter Selasky wrote: > On 05/18/14 23:03, Hans Petter Selasky wrote: > > Hi, > > > > First call: > > > > resource_list_add: > > Hi, > > It appears that the /dev/pccard.X is opened and reading some CIS data > from the device before any driver has been attached. The attached patch > solves the panic I've seen. Not sure if the patch is correct. Oops, your patch was dropped in my reply, but it just disables pccard_scan_cis() while a device is probing. Warner, the issue here is that pccard_scan_cis() can do a bus_alloc_resource() for SYS_RES_MEMORY rid 0 of a pccard device concurrently with pccard_function_init(). Hans patch might be along the right track, though we might want to make /dev/pccard.X block until pccard_function_init() finishes rather than causing pccard_scan_cis() to fail. What do you think? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: resource_list_add: resource entry is busy
On 05/18/14 23:03, Hans Petter Selasky wrote:
Hi,
First call:
resource_list_add:
Hi,
It appears that the /dev/pccard.X is opened and reading some CIS data
from the device before any driver has been attached. The attached patch
solves the panic I've seen. Not sure if the patch is correct.
--HPS
diff --git a/sys/dev/pccard/pccard_cis.c b/sys/dev/pccard/pccard_cis.c
index dbd7165..2914a37 100644
--- a/sys/dev/pccard/pccard_cis.c
+++ b/sys/dev/pccard/pccard_cis.c
@@ -133,6 +133,10 @@ pccard_scan_cis(device_t bus, device_t dev, pccard_scan_t fct, void *arg)
/* allocate some memory */
+ if (device_get_state(dev) == DS_NOTPRESENT) {
+ return (-1);
+ }
+
/*
* Some reports from the field suggest that a 64k memory boundary
* helps card CIS being able to be read. Try it here and see what
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: resource_list_add: resource entry is busy
Hi, First call: resource_list_add: KDB: stack backtrace: #0 0x8089e5f6 at kdb_backtrace+0x66 #1 0x808960f0 at resource_list_add+0x50 #2 0x805ea939 at pccard_function_init+0x279 #3 0x805ebede at pccard_probe_and_attach_child+0x7e #4 0x805ec6ce at pccard_driver_added+0x5e #5 0x808951b5 at devclass_driver_added+0x75 #6 0x80895cf3 at devclass_add_driver+0x103 #7 0x8084f1e8 at module_register_init+0xa8 #8 0x80846cde at linker_load_module+0x85e #9 0x808473f4 at kern_kldload+0xb4 #10 0x80847504 at sys_kldload+0x84 #11 0x80c4a4aa at amd64_syscall+0x5ea #12 0x80c34b47 at Xfast_syscall+0xf7 resource_list_add: resource entry is busy Second call: KDB: stack backtrace: #0 0x8089e5f6 at kdb_backtrace+0x66 #1 0x8089610a at resource_list_add+0x6a #2 0x805ea939 at pccard_function_init+0x279 #3 0x805ebede at pccard_probe_and_attach_child+0x7e #4 0x805ec6ce at pccard_driver_added+0x5e #5 0x808951b5 at devclass_driver_added+0x75 #6 0x80895cf3 at devclass_add_driver+0x103 #7 0x8084f1e8 at module_register_init+0xa8 #8 0x80846cde at linker_load_module+0x85e #9 0x808473f4 at kern_kldload+0xb4 #10 0x80847504 at sys_kldload+0x84 #11 0x80c4a4aa at amd64_syscall+0x5ea #12 0x80c34b47 at Xfast_syscall+0xf7 Seems like there is a duplicate resource? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: resource_list_add: resource entry is busy
On 05/17/14 14:14, John Baldwin wrote: On 5/16/14, 12:21 PM, Hans Petter Selasky wrote: Hi, I see the following panic: panic: resource_list_add: resource entry is busy When trying to kldload an older pccard driver. The call comes from the driver_added bus method somewhere down the tree. Loading the module before the kernel boots fixes the problem temporarily. Any bells ringing or patch suggestions? Seeing this on 9-stable, also believed that the same issue exists with 10-current. Something is doing a duplicate resource_list_add() for the same RID. The trace will tell you where the second resource_list_add() is occurring. Some tracing should let you see where the first one occurs. Hi, Here is the backtrace. Is this information sufficient to debug further: KDB: stack backtrace: #0 0x8089e5d6 at kdb_backtrace+0x66 #1 0x808960f7 at resource_list_add+0x57 #2 0x805ea939 at pccard_function_init+0x279 #3 0x805ebede at pccard_probe_and_attach_child+0x7e #4 0x805ec6ce at pccard_driver_added+0x5e #5 0x808951b5 at devclass_driver_added+0x75 #6 0x80895cf3 at devclass_add_driver+0x103 #7 0x8084f1e8 at module_register_init+0xa8 #8 0x80846cde at linker_load_module+0x85e #9 0x808473f4 at kern_kldload+0xb4 #10 0x80847504 at sys_kldload+0x84 #11 0x80c4a48a at amd64_syscall+0x5ea #12 0x80c34b27 at Xfast_syscall+0xf7 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: resource_list_add: resource entry is busy
On 5/16/14, 12:21 PM, Hans Petter Selasky wrote: > Hi, > > I see the following panic: > > panic: resource_list_add: resource entry is busy > > When trying to kldload an older pccard driver. The call comes from the > driver_added bus method somewhere down the tree. Loading the module > before the kernel boots fixes the problem temporarily. > > Any bells ringing or patch suggestions? > > Seeing this on 9-stable, also believed that the same issue exists with > 10-current. Something is doing a duplicate resource_list_add() for the same RID. The trace will tell you where the second resource_list_add() is occurring. Some tracing should let you see where the first one occurs. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: resource_list_add: resource entry is busy
Hi, I see the following panic: panic: resource_list_add: resource entry is busy When trying to kldload an older pccard driver. The call comes from the driver_added bus method somewhere down the tree. Loading the module before the kernel boots fixes the problem temporarily. Any bells ringing or patch suggestions? Seeing this on 9-stable, also believed that the same issue exists with 10-current. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
