Date: Tue, 30 Jul 2002 12:30:09 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@wemm.org> Cc: John Baldwin <jhb@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <15686.48913.150407.307190@grasshopper.cs.duke.edu> In-Reply-To: <20020730000345.E0D9F2A7D6@canning.wemm.org> References: <XFMail.20020729175342.jhb@FreeBSD.org> <20020730000345.E0D9F2A7D6@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes: <..> > The single beneficial thing we can do that is also really low hanging fruit > is to make as many drivers as we can INTR_MPSAFE and move the checking of > the hardware interrupt status register outside of giant. <..> > The catch is that pci_read_config() etc is not mpsafe yet since it uses the > shared pci configuration space window with no locking at all... :-] > (This should be simple to fix as well, except acpi is involved too now). Another catch appears to be that the mbuf codes needs callers of m*_get* to hold Giant, so that it can call kmem_malloc() to expand the mb_map. Here's a panic from my driver running INTR_MPSAFE on a WITNESS-enabled kernel panic: mutex Giant not owned at ../../../vm/vm_kern.c:312 cpuid = 1; lapic.id = 01000000 Debugger("panic") Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db> tr Debugger(c0336e3a,1000000,c0336028,da096b54,c01d7792) at Debugger+0x55 panic(c0336028,c0336192,c034a960,138,da096b88) at panic+0xfd _mtx_assert(c0370980,1,c034a960,138,da096bb4) at _mtx_assert+0xbc kmem_malloc(c1579000,1000,1,1fa,c033969e) at kmem_malloc+0x2d mb_pop_cont(c03a5560,1,c156dee0,283,0) at mb_pop_cont+0xa8 mb_alloc(c03a5560,1,1,0,0) at mb_alloc+0x1ec m_gethdr(1,1,c03a44c0,c4259a14,c1597f00) at m_gethdr+0x34 gm_bsd_ether_rxeof(c4259000,3c,9790,c0372100,0) at gm_bsd_ether_rxeof+0xcd gm_handle_claimed_interrupt(c44e4000,c4541100,c4512400,da096ce0,c455cc1f) at gm_handle_claimed_interrupt+0x180 gm_intr(c44e4000,da096d0c,c01ce9c2,c44e4000,0) at gm_intr+0x28 gm_freebsd_intr(c44e4000,0,c0334294,230,c421bac0) at gm_freebsd_intr+0xb ithread_loop(c4512400,da096d48,c0333f91,355,0) at ithread_loop+0x182 fork_exit(c01ce840,c4512400,da096d48) at fork_exit+0xaf fork_trampoline() at fork_trampoline+0x1a db> What's the prognosis for kmem_malloc() getting out from under Giant? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15686.48913.150407.307190>