From owner-freebsd-doc@FreeBSD.ORG Thu Apr 3 13:08:22 2014 Return-Path: Delivered-To: freebsd-doc@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 ESMTPS id 25D46B14 for ; Thu, 3 Apr 2014 13:08:22 +0000 (UTC) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bs1.fjl.org.uk", Issuer "bs1.fjl.org.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9448FAA0 for ; Thu, 3 Apr 2014 13:08:21 +0000 (UTC) Received: from [192.168.1.35] (host86-150-244-211.range86-150.btcentralplus.com [86.150.244.211]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id s33D8DlC060839 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Thu, 3 Apr 2014 14:08:13 +0100 (BST) (envelope-from frank2@fjl.co.uk) Message-ID: <533D5D3F.5020409@fjl.co.uk> Date: Thu, 03 Apr 2014 14:08:15 +0100 From: Frank Leonhardt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-doc@freebsd.org Subject: Re: Downplaying a serious issue References: <861txffcgh.fsf@shell.gmplib.org> <20140403035800.GR14379@glenbarber.us> <86k3b697nt.fsf@shell.gmplib.org> <20140403113605.GZ14379@glenbarber.us> In-Reply-To: <20140403113605.GZ14379@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 13:08:22 -0000 On 03/04/2014 12:36, Glen Barber wrote: > On Thu, Apr 03, 2014 at 09:47:02AM +0200, Torbjorn Granlund wrote: >> Glen Barber writes: >> >> It is not a doc problem. >> >> The issue is specific to certain hardware configurations, and unless >> anyone has made any breakthroughs that I am unaware of, the cause is >> still unknown. >> >> It happens on: >> >> AMD piledriver running Linux+KVM >> AMD piledriver running Linux+Xen >> Intel Nehalem running NetBSD+Xen >> Intel Sandybridge running NetBSD+Xen >> Intel Haswell running NetBSD+Xen >> AMD K10 Barcelona running NetBSD+Xen >> AMD Bulldozer running NetBSD+Xen >> > We need more specifics. > >> I've seen the laughable claim that this is a "bug in Virtualbox", and now >> the major downplay at http://www.freebsd.org/releases/10.0R/errata.html, >> where this is a minor hardware specific problem. >> >> I have not found one piece of PC hardware where it does not happen under >> virtualisation. Please let me know some configuration where FreeBSD/i386 >> works under a type 1 virtualiser? Perhaps Bhyve is FreeBSD-compatible? >> > Does not happen on my VirtualBox host. > > Glen > I've been following this discussion with some alarm, but have now looked at the Errata: ------------------------------------------ "FreeBSD/i386 10.0-RELEASE running as a guest operating system onVirtualBoxcan have a problem with disk I/O access. It depends on some specific hardware configuration and does not depend on a specific version ofVirtualBoxor host operating system. It causes various errors and makes FreeBSD quite unstable. Although the cause is still unclear, disabling unmapped I/O works as a workaround." etcetera ------------------------------------- I don't read this as "down-playing" - it's up front about saying that there's a problem with every version of VirtualBox. It would, of course, be useful to add that it doesn't work with other named emulators too (for a virtual machine IS emulating the I/O hardware). My concern was that this bug may be present on the real hardware too. I suspect more people would be running an i386 version as a VM than on real metal these days. Does the problem exist on previous releases? It seems to me that, after research, the list of confirmed incompatible configurations need to be expanded, especially to encompass other known-to-fail emulations. A list of "confirmed" problem environments would make readers wary about untested emulators too. Incidentally, I don't see this as a bug in FreeBSD. A hypervisor is supposed to transparent to the OS, emulating the hardware that the OS thinks it has, to perfection. This is a broken VM, as clearly it's not behaving as the real hardware would. Or is it? Regards, Frank.