Date: Tue, 30 Jul 2002 12:12:26 -0500 From: Alan Cox <alc@cs.rice.edu> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Peter Wemm <peter@wemm.org>, John Baldwin <jhb@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <20020730171226.GA26599@cs.rice.edu> In-Reply-To: <15686.48913.150407.307190@grasshopper.cs.duke.edu> References: <XFMail.20020729175342.jhb@FreeBSD.org> <20020730000345.E0D9F2A7D6@canning.wemm.org> <15686.48913.150407.307190@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 30, 2002 at 12:30:09PM -0400, Andrew Gallatin wrote:
>
> 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.
Remove GIANT_REQUIRED from kmem_malloc() and try again. Seriously.
You may or may not trip over another similar assertion, but the odds
are that it will work well enough to test.
Alan
> 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
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?20020730171226.GA26599>