From owner-freebsd-smp Tue Jul 30 9:30:45 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ACEB37B400; Tue, 30 Jul 2002 09:30:43 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF1743E5E; Tue, 30 Jul 2002 09:30:42 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA24072; Tue, 30 Jul 2002 12:30:41 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6UGU9X13457; Tue, 30 Jul 2002 12:30:09 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15686.48913.150407.307190@grasshopper.cs.duke.edu> Date: Tue, 30 Jul 2002 12:30:09 -0400 (EDT) To: Peter Wemm Cc: John Baldwin , freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers In-Reply-To: <20020730000345.E0D9F2A7D6@canning.wemm.org> References: <20020730000345.E0D9F2A7D6@canning.wemm.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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