On 10-Jun-2002 Kenneth D. Merry wrote: > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > ends up calling vm_map_entry_create(), same problem as above. > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls malloc() with M_WAITOK. > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls uma_zalloc() with M_WAITOK. > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls MALLOC() with M_WAITOK in various places. > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > with M_WAITOK. > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > vm_map_find(), which through several calls calls vm_map_entry_create(). > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > which does a uma_zalloc() with M_WAITOK. > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > ithread_add_handler() through several layers of indirection. > ithread_add_handler() calls malloc with M_WAITOK.
ti_attach() doesn't need to hold its lock while doing these things. Don't actually enable the logical network device until all the setup for it is done. > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > uma_zalloc with M_WAITOK. > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > function), which calls kmem_alloc_pageable(). See number 1 above, same > problem here with vm_map_entry_create(). > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > gets called, which calls vm_map_entry_create(), which calls > uma_zalloc() with M_WAITOK. > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > called through a slightly different path from the same root malloc() > call in jumbo_vm_init(). Same as above with regards to ti_attach(). > - the bus_setup_intr(), or rather the kthread code in general apparantly > isn't safe to be called while holding a mutex. This is the cause of the > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. Yes. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
