From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:05:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31853106566B; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0720A8FC08; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B316846B03; Fri, 22 Jul 2011 08:05:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4CD378A02C; Fri, 22 Jul 2011 08:05:28 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Fri, 22 Jul 2011 08:05:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <201107211153.23979.jhb@freebsd.org> <201107211837.07442.jkim@FreeBSD.org> In-Reply-To: <201107211837.07442.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107220805.27479.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 08:05:28 -0400 (EDT) Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend 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: Fri, 22 Jul 2011 12:05:29 -0000 On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote: > On Thursday 21 July 2011 11:53 am, John Baldwin wrote: > > On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: > > > On 07/20/11 09:04, John Baldwin wrote: > > > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > > > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > > > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > > > >>>> Hi, > > > >>>> > > > >>>> While testing some other things, I found -CURRENT from > > > >>>> yesterday doesn't work with the em0 in my VirtualBox 4.0.8 > > > >>>> (a little out of date admittedly). It worked Friday or > > > >>>> Saturday I think. Anyone else seen this or should I open a > > > >>>> PR? Has the code changed or am I perhaps misremembering > > > >>>> dates? The error reported is: > > > >>>> > > > >>>> em0: Unable to allocate bus resource: memory > > > >>>> em0: Allocation of PCI resources failed > > > >>> > > > >>> This is due to a bug in VirtualBox's BIOS implementation. > > > >>> Someone should file > > > >>> a bug report with VirtualBox to ask them to fix their BIOS. > > > >>> The problem is that they claim that the Host-PCI bridge in > > > >>> their system only decodes addresses 0xa0000-0xbffff (i.e. the > > > >>> VGA window) via the "Producer" resources in the _CRS method > > > >>> of the Host-PCI bridge device. This tells the OS that all > > > >>> the existing PCI devices are using invalid memory address > > > >>> ranges but that there is also no available address space to > > > >>> allocate for PCI devices such as em0. > > > >>> > > > >>> You can workaround this by setting > > > >>> "debug.acpi.disabled=hostres" until VirtualBox fixes their > > > >>> code. I'm happy to provide further clarification to an > > > >>> existing VirtaulBox bug report if needed. > > > >> > > > >> Thanks a lot for the analysis! I've talked to one of the > > > >> virtualbox developers about that but they are not aware of > > > >> such problems with Linux or Windows guests yet. So they are > > > >> currently unsure if it's a VirtualBox or FreeBSD fault and if > > > >> it's their fault why it works fine with other guests. I'm also > > > >> unsure because I haven't heard of that problem before and now > > > >> multiple people complain. That looks more like a FreeBSD > > > >> related problem on current or stable. > > > >> > > > >> I think it would be good if someone could try to reproduce > > > >> that with emulators/virtualbox-ose-legacy which is 3.2.12 to > > > >> get some vbox dev look into the problem again. > > > > > > > > FreeBSD just started honoring this setting in the BIOS this > > > > week and ignored it previously. Can you get an acpidump from > > > > within VirtaulBox? I might be able to point to a bug in it > > > > directly if so. > > > > > > Thanks for the info! I've attached the acpidump and also posted a > > > copy here: > > > > > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz > > > > > > in case the mailing list eats it. > > > > Hmm, so there does look to be a reasonable _CRS method. Oh, I > > think I see what I don't like: > > > > DWordMemory (ResourceProducer, PosDecode, > > MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // > > Granularity > > 0x00000000, // Range Minimum > > 0xFFDFFFFF, // Range Maximum > > 0x00000000, // Translation Offset > > 0x00000000, // Length > > ,, _Y01, AddressRangeMemory, TypeStatic) > > It should be using MinFixed, not MinNotFixed. > > Actually, I am responsible for this: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox- ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content- type=text%2Fplain > > I believe this patch was submitted upstream later. > > > Author: jhb > > Date: Thu Jul 21 20:43:43 2011 > > New Revision: 224254 > > URL: http://svn.freebsd.org/changeset/base/224254 > > > > Log: > > Allow non-fixed endpoints for a producer address range if the > > length of the resource covers the entire range. Some BIOSes > > appear to mark endpoints as non-fixed incorrectly (non-fixed > > endpoints are supposed to be used in _PRS when OSPM is allowed to > > allocate a certain chunk of address space within a larger range, I > > don't believe it is supposed to be used for _CRS). > > No, _CRS can use MinNotFixed (and MaxNotFixed). You can find similar > examples from ACPI spec. Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is > 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked "illegal". Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and less or equal to _MAX. That explicitly states that this is _only_ for _PRS. Thus, the only valid combination for _CRS for _MIF and _MAF with a length != 0 is to have both endpoints fixed. Further, note that for the case were _LEN is zero, all valid cases are described by a block starting thus: Variable size, variable location resource descriptor for _PRS. Given this, the _only_ valid combination for _CRS is Length != 0, and _MIF == _MAF == 1. All other resources in _CRS are illegal. BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 on page 260). -- John Baldwin