From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:50:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1F310656DA; Tue, 17 Feb 2009 22:50:23 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 677F98FC14; Tue, 17 Feb 2009 22:50:23 +0000 (UTC) (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.14.2/8.14.2) with ESMTP id n1HMoMtt018218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 17:50:22 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu n1HMoMtt018218 Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id n1HJQFAx077974; Tue, 17 Feb 2009 14:26:15 -0500 (EST) (envelope-from gallatin) Date: Tue, 17 Feb 2009 14:26:15 -0500 From: Andrew Gallatin To: current@freebsd.org Message-ID: <20090217142615.A77950@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.9-RELEASE-p1 on an i386 Cc: Subject: r187880 causes fatal trap 30 when unloading drivers 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, 17 Feb 2009 22:50:47 -0000 I'm seeing a panic when I unload if_mxge. I suspect it was caused by the recent change to allocate apic vectors on a per-CPU basis. I see the panic only when running an SMP kernel, and only on our 8-way opterons (a dual-core athlon64 is fine). This is on a box with 2 NICs. Every time I unload my driver, 2 CPUs panic at the same time slightly after unloading the driver. It occurs both when I use a single MSI, or legacy interrupts. Untangling the garbled jibberish, I see this on console: Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0xffffffff807ded46 stack pointer = 0x10:0xfffffffe40063b70 frame pointer = 0x10:0xfffffffe40063b80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 11 (idle: cpu2) trap number = 30 Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffff807ded46 stack pointer = 0x10:0xfffffffe40068b70 frame pointer = 0x10:0xfffffffe40068b80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 11 (idle: cpu1) trap number = 30 I cannot get a dump, and ddb shows that it is sitting in the acpi acpi_cpu_c1() function. I saw a similar report a little while back (http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003141.html). Following John's suggestion later in the thread, I tried backing out r187880, and I can again unload drivers. FWIW, I'm fairly certain the unhandled IRQ is not coming from the NIC. The NIC will not generate interrupts when it is not ifconfig'ed up. Given that, and how I usually see kldunload finish before the panic happens, I wonder if it might be a clock interrupt that is triggering the trap. Drew