From owner-freebsd-emulation@FreeBSD.ORG Sat Sep 6 22:17:29 2008 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C02D5106566C for ; Sat, 6 Sep 2008 22:17:29 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAAC8FC18 for ; Sat, 6 Sep 2008 22:17:29 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 1B7B3191A30; Sun, 7 Sep 2008 00:17:26 +0200 (CEST) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m86MF6GD040798; Sun, 7 Sep 2008 00:15:06 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m86MF6NS040797; Sun, 7 Sep 2008 00:15:06 +0200 (CEST) (envelope-from nox) Date: Sun, 7 Sep 2008 00:15:06 +0200 (CEST) From: Juergen Lock Message-Id: <200809062215.m86MF6NS040797@saturn.kn-bremen.de> To: kostikbel@gmail.com X-Newsgroups: local.list.freebsd.emulation In-Reply-To: <20080906152929.GB2038@deviant.kiev.zoral.com.ua> References: <20080830113448.GA2152@dchagin.dialup.corbina.ru> <20080906104659.GA2113@dchagin.dialup.corbina.ru> Organization: home Cc: freebsd-emulation@freebsd.org Subject: Re: Linux applications core if running (k)qemu 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: Sat, 06 Sep 2008 22:17:29 -0000 In article <20080906152929.GB2038@deviant.kiev.zoral.com.ua> you write: >-=-=-=-=-=- > >On Sat, Sep 06, 2008 at 02:46:59PM +0400, Chagin Dmitry wrote: >> On Tue, Sep 02, 2008 at 03:56:33PM -0500, Sean C. Farley wrote: >> > On Sat, 30 Aug 2008, Chagin Dmitry wrote: >> > >> > >On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote: >> > >>I am having trouble with kqemu.ko and linux.ko. If I run qemu with >> > >>the following command, Linux applications (chroot, acroread, ls) will >> > >>start core dumping: >> > >> qemu-system-x86_64 -m 512 \ >> > >> -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \ >> > >> -std-vga -parallel none -serial none -monitor stdio \ >> > >> -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime >> > >> >> > >>Loading kqemu.ko does not cause the problem, but the cores start a >> > >>little after WinXP starts running. Unloading kqemu.ko does not help; >> > >>the cores still happen but more randomly. I even tried unloading all >> > >>linux modules and reloading them without luck. It takes a reboot. >> > >> >> > >>Packages: >> > >>qemu-devel-0.9.1s.20080620_1 >> > >>kqemu-kmod-devel-1.4.0.p1 >> > >>linux_base-f8-8_4 >> > >> >> > >>sysctl: >> > >>compat.linux.osrelease: 2.6.16 >> > >> >> > >>dmesg: >> > >>kqemu version 0x00010400 >> > >>kqemu: KQEMU installed, max_locked_mem=1792492kB. >> > >> >> > >>System is 7-STABLE as of r181963 with or without the patch to fix RT >> > >>signals from Chagin. >> > > >> > >Interestingly... Sean, can you provide ktrace/kdump log of coring >> > >apps? thnx! >> > >> > Here they are (good and bad): >> > http://www.farley.org/freebsd/tmp/linuxulator_vs_kqemu/ >> > >> > The good trace is after the bad trace. I just kept running ktrace >> > /compat/linux/bin/date over and over until I got a good trace. Before >> > loading kqemu and running qemu, there were no core dumps. Also, I >> > compared two bad traces and they were basically the same except for PID >> > and a couple of addresses (still very close in value). >> > >> >> Most likely it is a tls problem again, some days ago kib@ has made MFC >> r182684, probably it will help.. > >I doubt it. This seems to be an ingenious kqemu bug. As far as I remember, >it tries to use GDT/LDT. This probably has unwanted interaction with >PCB_GS32BIT. Wow. That corner of the code had escaped me so far, and yes this (in amd64/linux32) looks like it won't like kqemu's seperating of the gdts on SMP indeed. (it stores a pointer to &gdt[GUGS32_SEL] in pcb_gs32p and lets linux processes manipulate the segment pointed to by it, and when kqemu is (or was) running this won't be used by all cpus, see older threads like http://lists.freebsd.org/pipermail/freebsd-emulation/2008-May/004902.html for the reasons.) What I wonder tho is, won't this also cause problems without kqemu when there are linux processes running on multiple cpus that manipulate this segment because the gdt is then shared between the cpus? (like, linux process on cpu 0 changes the segment, then linux process on cpu 1 comes along and changes it again and then the linux process on cpu 0 will pick it up from cpu 1?) At least I must have somehow assumed the shared gdt wouldn't be changed later because of reasons like this... Anyway, fixing this will require changes to the kernel, I don't see how kqemu could fix it by itself alone. :( Sorry, Juergen