Re: em problem in virtualbox since the weekend

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.  Try this patch:

Index: acpi_pcib_acpi.c
===================================================================
--- acpi_pcib_acpi.c	(revision 224217)
+++ acpi_pcib_acpi.c	(working copy)
_at__at_ -207,10 +207,12 _at__at_ acpi_pcib_producer_handler(ACPI_RESOURCE *res, voi
 			length = res->Data.ExtAddress64.AddressLength;
 			break;
 		}
-		if (length == 0 ||
-		    res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED ||
-		    res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED)
+		if (length == 0)
 			break;
+		if (min + length - 1 != max &&
+		    (res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED ||
+		    res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED))
+			break;
 		flags = 0;
 		switch (res->Data.Address.ResourceType) {
 		case ACPI_MEMORY_RANGE:

-- 
John Baldwin