From owner-freebsd-xen@FreeBSD.ORG Fri Jul 26 15:00:01 2013 Return-Path: Delivered-To: freebsd-xen@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E37F6AA5 for ; Fri, 26 Jul 2013 15:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B70FC2FF9 for ; Fri, 26 Jul 2013 15:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6QF01fM056678 for ; Fri, 26 Jul 2013 15:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6QF01Bw056677; Fri, 26 Jul 2013 15:00:01 GMT (envelope-from gnats) Date: Fri, 26 Jul 2013 15:00:01 GMT Message-Id: <201307261500.r6QF01Bw056677@freefall.freebsd.org> To: freebsd-xen@FreeBSD.org Cc: From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: kern/180788: [xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:00:02 -0000 The following reply was made to PR kern/180788; it has been noted by GNATS. From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= To: , Cc: Subject: Re: kern/180788: [xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot Date: Fri, 26 Jul 2013 16:53:04 +0200 This issue can be solved by reverting commit r244806. However this is not a long term option, r244806 just exposes a bug in Xen PV pmap code which should be fixed. It seems like Xen pmap is not able to cope with two processes sharing the same address space.