From owner-freebsd-current@FreeBSD.ORG Sun Jun 27 01:31:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C15A516A4CE; Sun, 27 Jun 2004 01:31:23 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4561843D45; Sun, 27 Jun 2004 01:31:23 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i5R1U25v014615; Sun, 27 Jun 2004 11:30:02 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i5R1U0nl029124; Sun, 27 Jun 2004 11:30:01 +1000 Date: Sun, 27 Jun 2004 11:29:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040627111227.V1642@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: SMP turbulence: "kernel trap 12 with interrupts disabled" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 27 Jun 2004 01:31:24 -0000 On Sat, 26 Jun 2004, Robert Watson wrote: > On Sat, 26 Jun 2004, David Wolfskill wrote: > > > Daily builds of -STABLE & -CURRENT went fine today, both on (UP) laptop > > and SMP "build machine," but the subsequent boot of -CURRENT on the SMP > > machine didn't go so well -- even a single-user boot died thus: > > I ran into this also -- I got a panic when I hit a key on the serial > console, as that caused the sio intr to preempt the ACPI idle loop and > resulted in unhappiness somehow. I found that when I disabled the tunable > that turns off HTT, it worked fine. Likewise, if I used 4BSD it was fine. > It's unclear to me what the cause is. This looks like phk's roto-tilling of com->hotchar to com->tp->t_hotchar. Hitting a key on a serial console that has not been opened from userland is the most deterministic way to demonstrate the brokenness of this change in practice. com->tp is NULL until first open, and the null pointer access is especially easy to reach using a serial console since it is in the interrupt handler and interrupts are enabled before open on serial consoles to support trapping to the debugger on them. You probably need the options that give this early enabling to see the bug. They are: %%% #if defined(DDB) && (defined(BREAK_TO_DEBUGGER) || \ defined(ALT_BREAK_TO_DEBUGGER)) %%% Bruce