Date: Fri, 22 Jul 2011 12:19:24 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Steve Wills <swills@freebsd.org>, freebsd-current@freebsd.org, Bernhard Froehlich <decke@freebsd.org> Subject: Re: em problem in virtualbox since the weekend Message-ID: <201107221219.27322.jkim@FreeBSD.org> In-Reply-To: <201107220805.27479.jhb@freebsd.org> References: <4E263EFE.3040200@FreeBSD.org> <201107211837.07442.jkim@FreeBSD.org> <201107220805.27479.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 22 July 2011 08:05 am, John Baldwin wrote: > 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. I was sure that my patch is okay because I found an example in the 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN == 0. So, I thought it wasn't strictly for _PRS. I'll ask Intel guys for clarification. > BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 > on page 260). Hmm... Maybe I mis-interpreted the table somehow. Note the original code was _MIF == _MAF == 1, and _LEN > 0 but _LEN != (_MAX - _MIN) + 1: -------------- DwordMemory( // Consumed-and-produced resource // (all of low memory space) ResourceProducer, // bit 0 of general flags is 0 PosDecode, // positive Decode MinFixed, // Range is not fixed MaxFixed, // Range is fixed Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Min (calculated dynamically) 0xffdfffff, // Max = 4GB - 2MB 0x00000000, // Translation 0xdfdfffff, // Range Length (calculated // dynamically) , // Optional field left blank , // Optional field left blank MEM3 // Name declaration for this // descriptor ) -------------- Intel ACPI Component Architecture ASL Optimizing Compiler version 20110527-64 Copyright (c) 2000 - 2011 Intel Corporation vbox.dsl 1103: 0xdfdfffff, // Range Length (calculated Error 4118 - ^ Length is not equal to fixed Min/Max window ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 Optimizations -------------- Both _MIN and _LEN are dynamically calculated, so I guess the simplest fix should have been: --- vbox.dsl.orig 2011-07-22 12:01:33.000000000 -0400 +++ vbox.dsl 2011-07-22 12:03:41.000000000 -0400 @@ -1100,7 +1100,7 @@ 0xffdfffff, // Max = 4GB - 2MB 0x00000000, // Translation - 0xdfdfffff, // Range Length (calculated + 0xffe00000, // Range Length (calculated // dynamically) , // Optional field left blank , // Optional field left blank This should have satisfied the table without breaking too much. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107221219.27322.jkim>