From owner-freebsd-current@FreeBSD.ORG Wed Dec 31 02:38:37 2003 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 9D8DF16A4CE; Wed, 31 Dec 2003 02:38:37 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BA443D3F; Wed, 31 Dec 2003 02:38:36 -0800 (PST) (envelope-from d@diefree.com) Received: from diefree.com ([24.6.31.57]) by comcast.net (rwcrmhc11) with ESMTP id <2003123110383601300k0hgte>; Wed, 31 Dec 2003 10:38:36 +0000 Message-ID: <3FF2A7BD.5000901@diefree.com> Date: Wed, 31 Dec 2003 02:41:01 -0800 From: Dan Hulme User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031206 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Dec 2003 04:55:56 -0800 cc: freebsd-current@freebsd.org Subject: Re: ACPI causes page fault/panic upon reboot 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: Wed, 31 Dec 2003 10:38:37 -0000 John Baldwin wrote: >Can you build a debug kernel, reproduce the panic, and then do a list >from gdb on your kernel.debug of the instruction pointer? For example, >from the above you do: > >gdb -k kernel.debug >l *0xc05fd8c5 > > First I should say that turning off acpi seemed to fix the problem. However, the problem appears to be in dc0. Ok, rebuilt my kernel with makeoptions DEBUG=-g options DDB Rebooted, did a trace when it went to the db prompt.: *********************** Shutting down ACPI Fatal trap 12: page fault while in kernel mode fault virtual address = 0x18 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0603bc5 stack pointer = 0x10:0xd032cc90 frame pointer = 0x10:0xd032ccc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 19 (irq9: rl0 dc0 acpi0) kernel: type 12 trap, code=0 Stopped at dc_rxeof+0x1b5: movl %edx,0x18(%eax) db>trace dc_rxeof(c33bb000,0,c0700bbe,c43,c33bb000) at dc_rxeof+0x1b5 dc_intr(c33bb000,0,c06f4d21,21f,c333d388) at dc_intr+0x100 ithread_loop(c1843980,d032cd48,c06f4be6,311,0) at ithread_loop+0x162 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd032cd7c, ebp = 0 --- ***************** Did a gdb -k kernel.debug, and listed the code: ***************** (kgdb) l *0xc0603bc5 0xc0603bc5 is in dc_rxeof (../../../pci/if_dc.c:2804). 2799 * If we are on an architecture with alignment problems, or 2800 * if the allocation fails, then use m_devget and leave the 2801 * existing buffer in the receive ring. 2802 */ 2803 if (dc_quick && dc_newbuf(sc, i, 1) == 0) { 2804 m->m_pkthdr.rcvif = ifp; 2805 m->m_pkthdr.len = m->m_len = total_len; 2806 DC_INC(i, DC_RX_LIST_CNT); 2807 } else 2808 #endif ***************** I hope this helps. -Dan