From owner-freebsd-current Tue Feb 6 8: 3:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from jbloom.jbloom.org (reyim.ne.mediaone.net [24.218.251.241]) by hub.freebsd.org (Postfix) with ESMTP id A1E6F37B401; Tue, 6 Feb 2001 08:02:58 -0800 (PST) Received: from acm.org (localhost [127.0.0.1]) by jbloom.jbloom.org (8.11.2/8.11.2) with ESMTP id f16G2u025104; Tue, 6 Feb 2001 11:02:57 -0500 (EST) (envelope-from bloom@acm.org) Message-ID: <3A80202F.6DAA1328@acm.org> Date: Tue, 06 Feb 2001 11:02:55 -0500 From: Jim Bloom Reply-To: bloom@acm.org X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: current@FreeBSD.org Subject: Re: Kernel Panic from Yesterday's CVSup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom bloom@acm.org PS: Here is the original message. It was cut and pasted from the logs since your message is sitting in another OS on a dual boot machine. On 06-Feb-01 Jim Bloom wrote: > I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is > occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create > a > core dump. Here is a hand transcription of what I see. > > Mounting root from ufs:/dev/ad0s1a > pccard: card inserted, slot 0 > pccard: card inserted, slot 1 > kernel trap 9 with interrupts disabled > > Fatal trap 9: general protection fault while in kernel mode > instruction pointer = 0x8:0xc0270ad8 > stack pointer = 0x10:0xc2fb4f50 > frame pointer = 0x10:0xc2fb4f64 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 16 (irq14:ata0) > kernel: type 9 trap, code=0 > Stopped at sw1b+0x77: ltr %si > > backtrace > sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. > ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. > fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d > fork_trampoline() at fork_trampoline+0x8 > > I don't have WITNESS or INVARIANTS at this time and don;t have a serial > console > so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message