From owner-freebsd-current@FreeBSD.ORG Tue Jul 17 22:23:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F82316A400; Tue, 17 Jul 2007 22:23:37 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id DE41E13C478; Tue, 17 Jul 2007 22:23:36 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l6HMNY7O078644 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 18:23:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 17 Jul 2007 15:26:41 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Divacky In-Reply-To: <20070717221327.GA60004@freebsd.org> Message-ID: <20070717152545.K92541@10.0.0.1> References: <20070716233030.D92541@10.0.0.1> <469D2688.7070000@kuehlbox.de> <20070717221327.GA60004@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, current@freebsd.org, Teufel Subject: Re: ULE/SCHED_SMP diff for 7.0 - panic on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2007 22:23:37 -0000 On Wed, 18 Jul 2007, Roman Divacky wrote: > On Tue, Jul 17, 2007 at 10:28:56PM +0200, Teufel wrote: >> Hi, >> >> cvsuped kernel sources about 20 mins ago and applied Jeff's new ule patch. >> System boots normaly up, but starting qemu with kqemu (either user or >> user and kernel space) results immediatly in kernel trap 12 >> applying Attilio's patch >> http://people.freebsd.org/~attilio/kqemu.diff fixed the kernel trap, >> but hangs: >> >> spin lock 0xc0bbf780 (shed lock 1) held by 0xc5114880 (tid 100003) too long >> panic: spin lock held too long >> cpuid = 0 > > this looks similar to what people are seeing on pointyhat building cluster. > > its definitely NOT related to kqemu desynced module/kernel. I have told attilio > about it. no response yet... > I see. The kqemu kernel module needs to be updated for 7.0. It locks sched_lock directly. This is no longer legal or valid. It is not holding the correct locks for ULE, only 4BSD. We will have to address this with the module author. Thanks, Jeff