From owner-cvs-src@FreeBSD.ORG Tue Jun 5 17:12:50 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6434A16A46B for ; Tue, 5 Jun 2007 17:12:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id A93A513C45A for ; Tue, 5 Jun 2007 17:12:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so258007uge for ; Tue, 05 Jun 2007 10:12:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=P6IcLqfhESNPhKGF4XKblF6ij+JCYT+71dP/wB2ltzwXjNTmQiUuaIGUuSQgD0rsXYYfm/szToEFL/wHBFQ2LkKTOCcAScPwQ2SyAwuFN7oQCVdVgNkPVtZX03TAp9MSfVWWWGGbuyZFrksXWiaaiwhjOiQN4xPfI9DZJ1nSCek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FD4KykficGe8XT0wVwOCMkFXLw1DL95j9vp4gMGTyp05jtwgfM9aIWJTRJthzCqR/wnWvYh4ceWBzOAwa9KQWXxJ4exlNTTyPpR6ycZGlh2bombcqM9NTjeXLYE6kodh04b9IjBCEIUIbaApqjkbjnJMnIK03XMr4lo2eGmF1L0= Received: by 10.78.56.19 with SMTP id e19mr2560999hua.1181063568206; Tue, 05 Jun 2007 10:12:48 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Tue, 5 Jun 2007 10:12:47 -0700 (PDT) Message-ID: <3bbf2fe10706051012h3d322a8fka35b9580b21ce22d@mail.gmail.com> Date: Tue, 5 Jun 2007 19:12:47 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kostik Belousov" In-Reply-To: <20070605164740.GY2268@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200706051420.l55EKEih018925@repoman.freebsd.org> <20070606003412.W35544@besplex.bde.org> <20070605150005.GW2268@deviant.kiev.zoral.com.ua> <20070605150521.GX2268@deviant.kiev.zoral.com.ua> <20070606011022.R35623@besplex.bde.org> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com> <20070605164740.GY2268@deviant.kiev.zoral.com.ua> X-Google-Sender-Auth: 969e4179277a5c63 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Bruce Evans Subject: Re: cvs commit: src/sys/kern kern_mutex.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2007 17:12:50 -0000 2007/6/5, Kostik Belousov : > On Tue, Jun 05, 2007 at 05:43:03PM +0200, Attilio Rao wrote: > > 2007/6/5, Attilio Rao : > > >2007/6/5, Bruce Evans : > > >> > > >> I get a "spin lock held too long" panic during (an interrupt in?) acpi > > >> initialization on booting non-PREEMPTION SCHED_4BSD SMP. Haven't tried > > >> other cases. > > > > > >Do you have a backtrace or any other debugging stuffs available? > > > > Mmm, I think I got the bug. > > basically, in kern_mutex.c::_mtx_unlock_sleep(), in the not-preemptive > > case what happens at some point is: > > > > td = curthread; > > if (td->td_critnest > 0 || td1->td_priority >= td->td_priority) > > return; > > > > thread_lock(td1); > > if (!TD_IS_RUNNING(td1)) { > > ... > > > > mi_switch(SW_INVOL, NULL); > > ... > > } > > thread_unlock(td1); > > > > Which is wrong beacause td1 is not curthread and really curthread > > should be locked too when context switching. > > > > To a first look the idea is that td and td1 should be locked both, but > > I just want more time to look better at it. > > With the following patch, I get the > panic: mutex sched lock recursed at .../kern_synch.c:379 > with backtrace > mi_switch > _mtx_unlock_sleep > _mtx_unlock_flags > vm_pagezero > > > diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c > index e0592a8..bf44229 100644 > --- a/sys/kern/kern_mutex.c > +++ b/sys/kern/kern_mutex.c > @@ -670,7 +670,9 @@ _mtx_unlock_sleep(struct mtx *m, int opts, const char *file, int line) > "_mtx_unlock_sleep: %p switching out lock=%p", m, > (void *)m->mtx_lock); > > + thread_lock(td); > mi_switch(SW_INVOL, NULL); > + thread_unlock(td); > if (LOCK_LOG_TEST(&m->lock_object, opts)) > CTR2(KTR_LOCK, "_mtx_unlock_sleep: %p resuming lock=%p", > m, (void *)m->mtx_lock); After I back home I realized there is only sched_lock currently... not yet per-cpu locks :) So we should just disable this code for the moment (or forever). Attilio -- Peace can only be achieved by understanding - A. Einstein