Date: Wed, 31 Jul 2002 17:26:10 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Alan Cox <alc@cs.rice.edu> Cc: Peter Wemm <peter@wemm.org>, John Baldwin <jhb@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <15688.22002.772933.316104@grasshopper.cs.duke.edu> In-Reply-To: <20020730171226.GA26599@cs.rice.edu> References: <XFMail.20020729175342.jhb@FreeBSD.org> <20020730000345.E0D9F2A7D6@canning.wemm.org> <15686.48913.150407.307190@grasshopper.cs.duke.edu> <20020730171226.GA26599@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox writes:
> On Tue, Jul 30, 2002 at 12:30:09PM -0400, Andrew Gallatin wrote:
> > 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.
(I also removed the GIANT_REQUIRED in vm_map_lock() as you suggested
in private email)
It gets a little further, but then trips over GIANT_REQUIRED in
vm_page_alloc():
panic(c0335f88,c03360f2,c034bcb2,34a,c1579000) at panic+0xfd
_mtx_assert(c03708e0,1,c034bcb2,34a,16a3) at _mtx_assert+0xbc
vm_page_alloc(c03cc440,16a3,0,1,c15a2000) at vm_page_alloc+0x3c
kmem_malloc(c1579000,1000,1,1fa,c03395fe) at kmem_malloc+0x1b5
mb_pop_cont(c03a54c0,1,c156dee0,283,0) at mb_pop_cont+0xa8
mb_alloc(c03a54c0,1,1,0,0) at mb_alloc+0x1ec
m_gethdr(1,1,c03a4420,c4205a7c,c1597400) at m_gethdr+0x34
gm_bsd_ether_rxeof(c4205000,34,52fe,c03720a0,0) at gm_bsd_ether_rxeof+0xcd
<...>
If I whack that one too, I see this:
../../../kern/kern_synch.c:454: sleeping with "myri" locked from /home/gallatin/gm/gm1/drivers/freebsd/ifnet/gm_bsd_ether_arch.h:112
lock order reversal
1st 0xc4203140 myri (myri) @ /home/gallatin/gm/gm1/drivers/freebsd/ifnet/gm_bsd_ether_arch.h:112
2nd 0xc03708c0 Giant (Giant) @ ../../../vm/vm_object.c:381
panic: mutex Giant not owned at ../../../vm/vm_page.c:597
cpuid = 1; lapic.id = 01000000
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> show locks
exclusive sleep mutex myri r = 0 (0xc4203140) locked @ /home/gallatin/gm/gm1/drivers/freebsd/ifnet/gm_bsd_ether_arch.h:112
db> tr
Debugger(c0336d7a,1000000,c0335f68,d7c5bafc,c083aa00) at Debugger+0x55
panic(c0335f68,c03360d2,c034bc92,255,0) at panic+0xfd
_mtx_assert(c03708c0,1,c034bc92,255,c0fb6758) at _mtx_assert+0xbc
vm_page_insert(c0fb6758,c03cc420,16a4,0,16a4) at vm_page_insert+0x36
vm_page_alloc(c03cc420,16a4,0,1,c15a3000) at vm_page_alloc+0x306
kmem_malloc(c1579000,1000,1,1fa,c03395de) at kmem_malloc+0x1b5
mb_pop_cont(c03a54a0,1,c156c120,283,0) at mb_pop_cont+0xa8
mb_alloc(c03a54a0,1,1,0,0) at mb_alloc+0x1ec
m_gethdr(1,1,c03a4400,c4203b4c,c158e100) at m_gethdr+0x34
gm_bsd_ether_rxeof(c4203000,34,7b3c,c0372040,0) at gm_bsd_ether_rxeof+0xcd
<...>
I get the feeling I should stop now, and revert my tree. FWIW, this
is a roughly 1-week old src tree. So I'm missing any improvements
you've made in the last week. Would cvs updating from this afternoon
make much of a difference?
For what its worth, this *seems* to work OK on a non-WITNESS,
non-INVARIENTs kernel.
Thanks,
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?15688.22002.772933.316104>