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>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15686.48913.150407.307190>