virtualbox.org

Discuss the 5.1.18 release here.
You can download the release here.

Just for the record, 5.1.18 should make it the fastest incremental release in the last 4 years, with 7 days only after the 5.1.16 release. Previous record was held by 5.1.2 (9 days after 5.1.0).

For the people that keep a record of stuff like that...

Windows guest fails into BSOD as well as with 5.1.16:
0x0000005a: ACPI BIOS in the system is not fully compliant with the ACPI specification.
Host: FreeBSD 10.3 Release
Guest:Windows Server 2008 R2 Datacenter

Looks like the problem is caused by VM RAM size:
- if VM RAM less than 64GB - all ok
- if VM RAM more than 64GB - BSOD

The only error in vboxsvc log is:

Code: Select all

00:07:46.759067 nspr-4   ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={77faf1c0-489d-b123-274c-5a95e77ab286} aComponent={ProgressProxy} aText={Error info is not available, operation is still in progress}, preserve=false aResultDetail=0

VM log is attached.

The host has 256 GB RAM.
With VirtualBox 5.1.14 everything works correct (with VM RAM size up to 128GB).

Is there any idea how to fix/workaround this problem in 5.1.18?

Thank you

Your log shows only 2.GB free RAM
00:00:00.017890 Host RAM: 262015MB (255.8GB) total, 2738MB (2.6GB) available

Maybe the freebsd build has a problem in this area?

It is strange as native FreeBSD sysmon says:

Code: Select all

Mem: 22M Active, 888M Inact, 109G Wired, 2648K Cache, 140G Free

And now one guest with 60GB of RAM is running.

Actually, VirtualBox web manager always displays about 1..4GB of free RAM while FreeBSD tells that almost all memory is free (when no guest is running). But I was able to run a guest with up to 150GB RAM... until 5.1.16.

Will try to find something on FreeBSD forum...
Or simply rollback to 5.1.14 once again. It looks like nothing useful for me in new versions. Only problem with RAM size.

Selin wrote:It is strange as native FreeBSD sysmon says:
Code: Select all
Mem: 22M Active, 888M Inact, 109G Wired, 2648K Cache, 140G Free
And now one guest with 60GB of RAM is running.

Actually, VirtualBox web manager always displays about 1..4GB of free RAM while FreeBSD tells that almost all memory is free (when no guest is running). But I was able to run a guest with up to 150GB RAM... until 5.1.16.

Will try to find something on FreeBSD forum...
Or simply rollback to 5.1.14 once again. It looks like nothing useful for me in new versions. Only problem with RAM size.

I think I know the problem. Could you try

Code: Select all

VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0

with 5.1.18 and check if your guest boots without BSOD?

Why do you use the ICH9 chipset (manual says "Note that the ICH9 support is experimental and not recommended...")? Why do you use 10 VCPUs on a system which has 6 cores (manual says "You should not, however, configure virtual machines to use more CPU cores than you have available physically (real cores, no hyperthreads)"? Of course it's great to live on the edge, but you're asking for problems...

Klaus, you were looking too fast, it seems to be a dual CPU system:
00:00:01.170131 CPUM: Physical host cores: 12

Not today

At least a Xeon E5-1650 v3 should not be used in anything but a single socket server. The log message is misleading, it's showing the logical CPU count (which includes hyperthreading).

So this would be a Virtualbox "logging bug" here?

I was used to the logs showing the number of logical / physical cpu cores correctly.

It's not a new bug, but clearly a bug. The information about the core/thread count should be available...

frank wrote:I think I know the problem. Could you try
Code: Select all
VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0

Thanks! Will try on weekend.
Could you share a bit more details - what this command do?

klaus wrote:Why do you use the ICH9 chipset?

I don't know. It is by historical reason.
With VirtualBox 5.1.14 and earlier there was no problem with this.

klaus wrote:manual says "You should not, however, configure virtual machines to use more CPU cores than you have available physically (real cores, no hyperthreads)"

Thanks. I really missed this nuance.
Wonder to know - why HT cores shall not be used by virtual machines?

Looks like I have to re-read whole manual once again...

klaus wrote:It's not a new bug, but clearly a bug. The information about the core/thread count should be available...

Klaus, I feel that you needed to continue that sentence but somehow it got cut short. What did you mean "should be available" ?

socratis wrote:
klaus wrote:It's not a new bug, but clearly a bug. The information about the core/thread count should be available...
Klaus, I feel that you needed to continue that sentence but somehow it got cut short. What did you mean "should be available" ?

I meant "should be available if the code would use the right query function". VirtualBox gets full core/thread/... information from the OS (which means that even the AMD Bulldozer/Piledriver/Steamroller/Excavator generation CPUs on Windows will often be shown with half the official core count - because Microsoft decided that this is the way to report such CPUs in the recent Windows versions, IIRC they started that in some Windows 7 update). VirtualBox even offers quite detailed information with

VBoxManage show hostinfo

, distinguishing between 'processor [online] count' and 'processor [online] core count'.

Selin wrote:
frank wrote:I think I know the problem. Could you try
Code: Select all
VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0
Thanks! Will try on weekend.
Could you share a bit more details - what this command do?

This command disables the announcement of an ACPI resource which is buggy in case of a huge memory. Have a look at the following line from your VBox.log file:

Code: Select all

00:00:01.075779 ACPI: enabling 64-bit prefetch root bus resource 0x0000002024000000..0x0000000fffffffff

I hope it's obvious that the former value is bigger than the latter

virtualbox.org

Discuss the 5.1.18 release

Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release

Re: Discuss the 5.1.18 release