From owner-freebsd-current@FreeBSD.ORG Mon May 26 17:09:40 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 3792F37B401 for ; Mon, 26 May 2003 17:09:40 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC4043F75 for ; Mon, 26 May 2003 17:09:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from dialup-67.30.96.194.dial1.sanjose1.level3.net ([67.30.96.194] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19KS25-0000yQ-00; Mon, 26 May 2003 17:09:38 -0700 Message-ID: <3ED2AC75.3408574E@mindspring.com> Date: Mon, 26 May 2003 17:08:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Liesner References: <20030526120106.S488@gravy.homeunix.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f756173a69883f23852795e101607816350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@freebsd.org Subject: Re: panic since changes to kern_umtx.c 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: Tue, 27 May 2003 00:09:40 -0000 Bryan Liesner wrote: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > 0xc0136be7 is in heap_up (../../../cam/cam_queue.c:345). > 345 if (queue_array[i]->priority == queue_array[j]->priority) Pretty much the only way this can happen is for i or j to be out of range, or for queue_array[?] to be NULL (the first element in a cam_pinfo is "priotity", so this corresponds to the offset of 0 from the start of the struct for that member). I would have to say that this is probably the result of a bogus wakeup, or more general corruption of kernel memory as a result of Jeff's move to a seperate queue mutex for calling from user space. Actually, the one suspicious thing is that it walks the thread list in the proc without holding the proc lock; the block comment above this code is not true any more now, e.g.: /* * Since we own the mutex and the proc lock we are free to inspect * the blocked queue. It must have one valid entry since the * CONTESTED bit was set. */ [ ... ] FOREACH_THREAD_IN_PROC(td->td_proc, td0) if (td0 == (struct thread *)blocked) break; The same unprotected (broken) loop occurs in both _umtx_lock() and _umtx_unlock(). It's strange that it would show up in cam, but at least it's repeatable. 8-). -- Terry