Luigi Rizzo [EMAIL PROTECTED] wrote: > Cleanup and document the implementation of firmware(9) based on > a version that i posted earlier on the -current mailing list, > and subsequent feedback received. >
At least for me, firmware(9) has been broken ever since the kld_mtx was replaced with an sx lock last June. The problem is that there is an exclusive lock of kld_sx taken when loading a driver, and then firmware_get() triggers another xlock of it, leading to a deadlock: db> tr 707 Tracing pid 707 tid 100087 td 0xffffff001871bcd0 sched_switch() at sched_switch+0xec mi_switch() at mi_switch+0x14d sleepq_wait() at sleepq_wait+0x58 cv_wait_unlock() at cv_wait_unlock+0x131 cv_wait() at cv_wait+0x2c _sx_xlock() at _sx_xlock+0x51 linker_reference_module() at linker_reference_module+0x2d firmware_get() at firmware_get+0xda mxge_attach() at mxge_attach+0x787 device_attach() at device_attach+0x292 pci_driver_added() at pci_driver_added+0xe0 devclass_add_driver() at devclass_add_driver+0xc8 driver_module_handler() at driver_module_handler+0xad module_register_init() at module_register_init+0x84 linker_load_module() at linker_load_module+0xaf5 kern_kldload() at kern_kldload+0xa2 kldload() at kldload+0x84 syscall() at syscall+0x266 Xfast_syscall() at Xfast_syscall+0xab I've been using a patch (http://people.freebsd.org/~gallatin/firmware_sx_recurse.diff) which works around the problem. Do you think it would be possible to commit this? Thanks, Drew _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
