From owner-cvs-src@FreeBSD.ORG Tue Jun 5 17:12:04 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 699C716A469 for ; Tue, 5 Jun 2007 17:12:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0738213C45E for ; Tue, 5 Jun 2007 17:12:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so257785uge for ; Tue, 05 Jun 2007 10:12:01 -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=TKDGPtOyt2+7NC3QHuD9agTu5tTS5L1sQ/RW+C7//iArV9B772fqDJulQ8K/ucLep1pCmUsR7ToBCi6unkpFZpmSERSFDxyfbMvwF/zRX2h26aPA16jazMy9vfCKvwxqLH/rgRu0lXnMiNo66I9ASEfu1FgTfXsCMFK7o8aBZmY= 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=Xoj329NWRjIh7IQr9SI4Te1oyCculh7BfTL39wh3Nr0pWwaF+Z8C8aZlC3zvnu33OR0hD41G3gzJ4BZAZb1qnZZ80Q7IxEsoUI0p884zX+fZet8g1544ZXv/I0Bfuc5L7DYtX5RTSRAmZJsB2/G4XPg13a4utZG1iO0DJT+brik= Received: by 10.78.205.7 with SMTP id c7mr2601078hug.1181063521648; Tue, 05 Jun 2007 10:12:01 -0700 (PDT) Received: by 10.78.120.9 with HTTP; Tue, 5 Jun 2007 10:12:01 -0700 (PDT) Message-ID: <3bbf2fe10706051012x76381687g98e034ceb47b3f26@mail.gmail.com> Date: Tue, 5 Jun 2007 19:12:01 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200706051230.21242.jhb@freebsd.org> 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> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com> <200706051230.21242.jhb@freebsd.org> X-Google-Sender-Auth: db4e3a26349aff14 Cc: Kostik Belousov , 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:04 -0000 2007/6/5, John Baldwin : > On Tuesday 05 June 2007 11:43:03 am 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. > > If this is the old #ifndef PREEMPTION manual preemption stuff, then just > remove it. I've been wanting to axe it for a while, rwlocks don't do the > manual preemption either, and if it is getting in the way it's best to just > purge it. Yes. More specifically, I always thought that code would just force a PREEMPTION point in the mtx_unlock(), instead it just happens in the !PREEMPTION case... is this a bug? I don't see why doing something like that in the !PREEMPTION point (but it can be I'm missing something :)). Attilio -- Peace can only be achieved by understanding - A. Einstein