From owner-freebsd-current@FreeBSD.ORG Mon Nov 3 08:38:14 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 9FAA516A4CE; Mon, 3 Nov 2003 08:38:14 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF0A443FDD; Mon, 3 Nov 2003 08:38:11 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id hA3GaTVv071889; Mon, 3 Nov 2003 17:36:29 +0100 (CET) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.10/8.12.10/Submit) id hA3GaTPH071888; Mon, 3 Nov 2003 17:36:29 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200311031636.hA3GaTPH071888@spider.deepcore.dk> In-Reply-To: To: John Baldwin Date: Mon, 3 Nov 2003 17:36:29 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: current@FreeBSD.org Subject: Re: NULL td passed to propagate_priority() when using xmms... 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: Mon, 03 Nov 2003 16:38:14 -0000 It seems John Baldwin wrote: > > On 01-Nov-2003 Soren Schmidt wrote: > > It seems Sean Chittenden wrote: > >> Howdy. I'm not sure if this is a ULE bug or a KSE bug, or both, but, > >> for those interested (this is using ule 1.67, rebuilding world now), > >> here's my stack. I couldn't figure out where td was being set to > >> NULL. :( Oh! Where is TD_SET_LOCK defined? egrep -r didn't turn up > >> anything. -sc > > > > Its not ULE, I'm running 4BSD and has gotten this on boot for over a > > week now, rendering -current totally useless... > > Having a kernel panic with INVARIANTS on would really help narrow down > where the bug is. doesn't produce anything it seems, but I do have this traceback: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04b8f3b stack pointer = 0x10:0xcd619bc4 frame pointer = 0x10:0xcd619bd8 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 = 3 (g_up) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x8b: cmpl 0x24(%ebx),%ecx db> trace propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr iority+0x8b _mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249 bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47 biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28 fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 --- db> -Søren