From owner-freebsd-current@FreeBSD.ORG Tue Feb 1 16:58:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DE9106564A; Tue, 1 Feb 2011 16:58:14 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE3A18FC0A; Tue, 1 Feb 2011 16:58:13 +0000 (UTC) Received: by wyf19 with SMTP id 19so7150152wyf.13 for ; Tue, 01 Feb 2011 08:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=sQ5bP7xdKT8izHvhl4panYqfktRVo2TkYdUsPuvNDLY=; b=FX6q4P56NiYuF+MwAJMytHJJ3bJReTq3yLpJWS9Nd+gSNDrofsRrtmquXCYJpxOWj8 gqkkHUAU4RxxWjucBjgwhJOHBiZrvp9Gp+y9aJt/nQYr7VlLG5k9K4LaUXKqLPx6xzsz /jXEYx8Eu1IOB3g+RwF8UzHbh4P3jGp9RlEek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Z1gG9Jvi1jKHnZevKKvi7yUqd7lWPB8gculkSi96YE4eU2jMEE0v+imz2FcxY5ihVF c5VTrhEaGA9qqyBkQii7IrXxO9A8IDRuL8skmsMzYcgWzaaxgLZRXkInZ03Xz2RAhVUh hLfu8/uxmxPHNPG6BeI8vLEqfr+ldSHx9DhUo= MIME-Version: 1.0 Received: by 10.216.179.140 with SMTP id h12mr7590550wem.40.1296579492553; Tue, 01 Feb 2011 08:58:12 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.216.62.203 with HTTP; Tue, 1 Feb 2011 08:58:12 -0800 (PST) Date: Tue, 1 Feb 2011 08:58:12 -0800 X-Google-Sender-Auth: WoVy8Fo_rXFO32m54BmyKhR2lj0 Message-ID: From: mdf@FreeBSD.org To: John Baldwin , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Panic with mca trap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:58:14 -0000 On a piece of hardware trying to verify basic build tests, we got an MCA exception that then panic'd the kernel due to WITNESS/INVARIANTS interaction. panic @ time 1296563157.510, thread 0xffffff0005540000: blockable sleep lock (sleep mutex) 128 @ /build/mnt/src/sys/vm/uma_core.c:1872 Stack: -------------------------------------------------- kernel:witness_checkorder+0x7a2 kernel:_mtx_lock_flags+0x81 kernel:uma_zalloc_arg+0x256 kernel:malloc+0xc5 kernel:mca_record_entry+0x30 kernel:mca_scan+0xc9 kernel:mca_intr+0x79 kernel:trap+0x30b kernel:witness_checkorder+0x66 kernel:_mtx_lock_spin_flags+0xa4 kernel:witness_checkorder+0x2a8 kernel:_mtx_lock_spin_flags+0xa4 kernel:tdq_idled+0xe8 kernel:sched_idletd+0x5b kernel:fork_exit+0x9b That's this bit of code in uma_zalloc_arg(): #ifdef INVARIANTS ZONE_LOCK(zone); uma_dbg_alloc(zone, NULL, item); ZONE_UNLOCK(zone); #endif I don't know uma(9) well enough to know the best workaround. Clearly there are times we can be in uma_zalloc_arg() and taking a regular mutex is not acceptable. But what to do for the uma_dbg_free() call so it's happy, and whether to guard taking the ZONE lock with M_NOWAIT or td_critnest > 0 or both is outside my current knowledge. I don't expect we'll see this panic again any time soon, but it would be nice to fix the story for WITNESS of when an M_NOWAIT allocation can be done. Thanks, matthew