Re: em problem in virtualbox since the weekend

From: Jung-uk Kim <jkim_at_FreeBSD.org>
Date: Fri, 22 Jul 2011 12:19:24 -0400
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
_at__at_ -1100,7 +1100,7 _at__at_
 
                      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
Received on Fri Jul 22 2011 - 14:19:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC