From owner-freebsd-emulation@FreeBSD.ORG Thu Jul 12 18:07:52 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9372616A41F; Thu, 12 Jul 2007 18:07:52 +0000 (UTC) (envelope-from craig@yekse.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 78D1013C4BB; Thu, 12 Jul 2007 18:07:52 +0000 (UTC) (envelope-from craig@yekse.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 40BA0115C2; Thu, 12 Jul 2007 13:07:52 -0500 (CDT) Date: Thu, 12 Jul 2007 13:07:50 -0500 From: Craig Boston To: Juergen Lock , attilio@freebsd.org, freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org Message-ID: <20070712180750.GB77654@nowhere> Mail-Followup-To: Craig Boston , Juergen Lock , attilio@freebsd.org, freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org References: <20070702203027.GA45302@saturn.kn-bremen.de> <46925324.9010908@freebsd.org> <3bbf2fe10707091140h6cdc7469nac5be03a8c8a60cb@mail.gmail.com> <200707092000.29768.dfr@rabson.org> <200707092149.l69LnXe9023835@saturn.kn-bremen.de> <20070712175252.GA77654@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712175252.GA77654@nowhere> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: experimental qemu-devel port update, please test! X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 18:07:52 -0000 On Thu, Jul 12, 2007 at 12:52:52PM -0500, Craig Boston wrote: > For some reason when the ioctl is issued, curproc points to a totally > bogus proc structure. curthread seems to be sane as far as I can tell, > but the process it claims to belong to is full of junk. Aha! The problem isn't that curproc is garbage, but rather that it's being interpreted wrong. struct proc has some extra fields when KSE is #defined. KSE recently became a kernel option and was put in the DEFAULTS file, so everyone's kernel has it defined. But kqemu is being compiled without it. I compiled with -DKSE and now kqemu works! This seems like it would be a common problem for modules compiled outside the kernel tree. Is there an established way to get the standard configuration options? I'm thinking also about other options like SMP, that for instance changes the way mutexes work. Craig