Re: em problem in virtualbox since the weekend
I have same problems with em and ahci. Now in VirtialBox I temporarily set net iface to PCNet-PCI II (Am79C970A). It works with if_le driver. VirtualBox 4.1, recent FreeBSD 9. -- View this message in context: http://freebsd.1045724.n5.nabble.com/em-problem-in-virtualbox-since-the-weekend-tp4614403p4630323.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Monday, July 25, 2011 6:46:44 am timp wrote: I have same problems with em and ahci. Now in VirtialBox I temporarily set net iface to PCNet-PCI II (Am79C970A). It works with if_le driver. VirtualBox 4.1, recent FreeBSD 9. So are you having problems with the latest FreeBSD 9? Can you capture a verbose dmesg if so? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
Hmm, it was a few days ago. Something like Unable to allocate bus resource: memory Today I rebuilt latest kernel world and now em and ahci works! 2011/7/25 John Baldwin j...@freebsd.org On Monday, July 25, 2011 6:46:44 am timp wrote: I have same problems with em and ahci. Now in VirtialBox I temporarily set net iface to PCNet-PCI II (Am79C970A). It works with if_le driver. VirtualBox 4.1, recent FreeBSD 9. So are you having problems with the latest FreeBSD 9? Can you capture a verbose dmesg if so? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
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 0xa-0xb (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, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // 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
Re: em problem in virtualbox since the weekend
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 0xa-0xb (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, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // 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
Re: em problem in virtualbox since the weekend
On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: On Friday 22 July 2011 08:05 am, John Baldwin wrote: 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. Hmm, that does seem to contradict the earlier section. I wonder if that example is just broken? It is supposed to be an example talking about assigning PCI bus numbers. Note that both of those examples do use a length of 0, so perhaps they are expecting the OS to ignore them? 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, 0x, // Granularity 0x, // Min (calculated dynamically) 0xffdf, // Max = 4GB - 2MB 0x, // Translation 0xdfdf, // 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: 0xdfdf, // Range Length (calculated Error4118 -^ 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.0 -0400 +++ vbox.dsl2011-07-22 12:03:41.0 -0400 @@ -1100,7 +1100,7 @@ 0xffdf, // Max = 4GB - 2MB 0x, // Translation - 0xdfdf, // Range Length (calculated + 0xffe0, // Range Length (calculated // dynamically) ,// Optional field left blank ,// Optional field left blank This should have satisfied the table without breaking too much. :-( Well, perhaps the best fix would be to set the length to 0 instead. Maybe the compiler is possibly broken here. The Fixed vs NotFixed matters in terms of what is actually presented to the OS once the _CRS method has run, not how _CRS may choose to populate the buffers. _CRS may dynamically calculate what the _MAX and _LEN fields are (this is very common), but the finished buffer that the OS sees is for a fixed resource range, so it should use Fixed for both endpoints. So for example, this is what I see on a test system here for the main PCI memory window region: DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x, // Granularity 0x,
Re: em problem in virtualbox since the weekend
On Friday 22 July 2011 01:41 pm, John Baldwin wrote: On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: On Friday 22 July 2011 08:05 am, John Baldwin wrote: 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. Hmm, that does seem to contradict the earlier section. I wonder if that example is just broken? It is supposed to be an example talking about assigning PCI bus numbers. Note that both of those examples do use a length of 0, so perhaps they are expecting the OS to ignore them? Now I think the example is broken. However, a lot of BIOS writers just copy and paste examples from the spec. without looking closely. In fact, I've seen many such cases. :-( 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, 0x, // Granularity 0x, // Min (calculated dynamically) 0xffdf, // Max = 4GB - 2MB 0x, // Translation 0xdfdf, // 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: 0xdfdf, // Range Length (calculated Error4118 - ^ 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.0 -0400 +++ vbox.dsl2011-07-22 12:03:41.0 -0400 @@ -1100,7 +1100,7 @@ 0xffdf, // Max = 4GB - 2MB 0x, // Translation - 0xdfdf, // Range Length (calculated + 0xffe0, // Range Length (calculated // dynamically) , // Optional field left blank ,// Optional field left blank This should have satisfied the table without breaking too much. :-( Well, perhaps the best fix would be to set the length to 0 instead. Maybe the compiler is possibly broken here. The Fixed vs NotFixed matters in terms of what is actually presented to the OS once the _CRS method has run, not how _CRS may choose to populate the buffers. _CRS may dynamically calculate what the _MAX and _LEN fields are (this is very common), but the finished buffer that the OS sees is for a fixed resource range, so it should use Fixed for both endpoints. So for example, this is what I see on a test system
Re: em problem in virtualbox since the weekend
On 07/21/11 15:10, Scot Hetzel wrote: On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin j...@freebsd.org wrote: 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, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // Length ,, _Y01, AddressRangeMemory, TypeStatic) This patch fixed the problem with my recent install of FreeBSD 9.0 on VirtualBox. Thanks for the fix. Same here, thanks! Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 0xa-0xb (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,
0x, // Granularity
0x, // Range Minimum
0xFFDF, // Range Maximum
0x, // Translation Offset
0x, // 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)
@@ -207,10 +207,12 @@ 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin j...@freebsd.org wrote:
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,
0x, // Granularity
0x, // Range Minimum
0xFFDF, // Range Maximum
0x, // Translation Offset
0x, // Length
,, _Y01, AddressRangeMemory, TypeStatic)
This patch fixed the problem with my recent install of FreeBSD 9.0 on
VirtualBox.
Thanks for the fix.
Scot
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)
@@ -207,10 +207,12 @@ 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
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 0xa-0xb (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, 0x, // Granularity 0x, // Range Minimum 0xFFDF, // Range Maximum 0x, // Translation Offset 0x, // 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. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On 7/20/2011 5:35 AM, Steve Wills wrote: 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 I also see this on a 4.0.4something installation. em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed So, you're not alone:) Nikos ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Wed, Jul 20, 2011 at 10:59 AM, Nikos Vassiliadis nv...@gmx.com wrote: On 7/20/2011 5:35 AM, Steve Wills wrote: 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 I also see this on a 4.0.4something installation. em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed So, you're not alone:) Nikos Same here. I've tried all possible NIC emulations to no avail. -- Good, fast cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
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 0xa-0xb (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. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
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 0xa-0xb (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. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On 2011-07-20 14:33, 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 0xa-0xb (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. This may or may not be related, apologies if it is not. My FreeBSD VirtualBox guest, running inside vbox under Windows, is having trouble mounting it's root partition, mountroot dies with error 19 (which is ENODEV, I've come to understand). I can also see in the dmesg prior to this ahci, ehci and ohci not being able to allocate resources properly, or something similar. Rebuilding the kernel with nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots and can find filesystems, etc.). It is probably so, that if there is a bug in vbox bios, the old pci code masks that bug, but the new version is more stringent and therefore dies on it. This can be the reason no one has seen this issue up until now. Why it works for Linux and Windows guests, I have no idea. I hope this helps someone, or at least can shed some light on the issue at hand. Regards! -- Niclas Zeising ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Wednesday, July 20, 2011 10:33:19 am Niclas Zeising wrote: On 2011-07-20 14:33, 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 0xa-0xb (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. This may or may not be related, apologies if it is not. My FreeBSD VirtualBox guest, running inside vbox under Windows, is having trouble mounting it's root partition, mountroot dies with error 19 (which is ENODEV, I've come to understand). I can also see in the dmesg prior to this ahci, ehci and ohci not being able to allocate resources properly, or something similar. Rebuilding the kernel with nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots and can find filesystems, etc.). It is probably so, that if there is a bug in vbox bios, the old pci code masks that bug, but the new version is more stringent and therefore dies on it. This can be the reason no one has seen this issue up until now. Why it works for Linux and Windows guests, I have no idea. I hope this helps someone, or at least can shed some light on the issue at hand. Yes, that is the same bug. The old PCI code is less stringent (but also less functional in other cases as a result). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 0xa-0xb (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. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOJ1UoAAoJEPXPYrMgexuhhngIAJ/gyw1DMCciYDOw2Ek53dCb Cx2zFFm32THagLFIewKSL7RDKr6fNcNWuAdfFm/zpKq8nGUjA16p9A4eoOvdVc5u MhAu7oPZlnx9pX1o/JRjW0mtWglrHvKMapsptzlGOmS8PZMQz9s+L+IvGhsY8+qV avQ0V/w/AwG+T7x/vaCPpPdDPubuxT7vO+A5x9r4aUtFbKWIzF/1rsbq3cjIiGXw ExMpcdDBGRyLsPpB4fzhjb/drOQMJAkO2PnPPkWDociWCnC8Da/qCr6keD1lZPtD wx0UnMd/pyzJKVAuf4+VcifABIJIZeRqStIH7CB1fOKhcT+HDwatbKrEFGSvEMs= =COvj -END PGP SIGNATURE- vbox-4.0.8.asl.gz.sig Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: em problem in virtualbox since the weekend
On Wed, Jul 20, 2011 at 8:33 AM, Bernhard Froehlich de...@freebsd.org wrote: 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. I saw the problem this weekend on a Linux host running virtualbox 3.2.8. I can ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
