From owner-freebsd-current Wed Mar 21 15: 9:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 183AC37B71F for ; Wed, 21 Mar 2001 15:09:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2LN9eG49273; Wed, 21 Mar 2001 15:09:40 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 21 Mar 2001 15:09:13 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: RE: boom in a syscalll Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21-Mar-01 Matthew Jacob wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; lapic.id = 00000000 > fault virtual address = 0x14 NULL pointer deref.. > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc019d7fa > stack pointer = 0x10:0xc8f45ea4 > frame pointer = 0x10:0xc8f45eb0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 331 (bash) > kernel: type 12 trap, code=0 > > CPU0 stopping CPUs: 0x00000002... stopped. > Stopped at propagate_priority+0x6e: cmpl 0x14(%esi),%ebx > db> t > propagate_priority(c8b4c100) at propagate_priority+0x6e (kgdb) l *propagate_priority+0x6e 0xc019fdce is in propagate_priority (../../kern/kern_mutex.c:201). 201 MPASS(p->p_magic == P_MAGIC); Well, err, maybe this line, considering none of the rest of my line numbers match up I doubt it is this one. :( Could you pull up kgdb on your kernel.debug and find out which line this died in? It could either be that p is NULL (which could be an unintialized mutex that a mtx_lock later blocked on.) In fact, this is quite likely just using a mutex that hasn't been init'd. Might want to add in some code to try to display the description of a mutex if p == NULL (though it is probably invalid, too.) Another take might be to add assertions to the start of mtx_lock_flags() and mtx_lock_spin_flags() that panic if mtx_lock == 0. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message