Discuss the 5.1.18 release
-
- Oracle Corporation
- Posts: 3362
- Joined: 7. Jun 2007, 09:11
- Primary OS: Debian Sid
- VBox Version: PUEL
- Guest OSses: Linux, Windows
- Location: Dresden, Germany
- Contact:
Discuss the 5.1.18 release
Discuss the 5.1.18 release here.
You can download the release here.
You can download the release here.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Discuss the 5.1.18 release
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...
For the people that keep a record of stuff like that...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Re: Discuss the 5.1.18 release
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:
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
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
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
- Attachments
-
- VBoxBSOD.zip
- (26.2 KiB) Downloaded 39 times
-
- Volunteer
- Posts: 2561
- Joined: 30. May 2007, 18:05
- Primary OS: Fedora other
- VBox Version: PUEL
- Guest OSses: XP, Win7, Win10, Linux, OS/2
Re: Discuss the 5.1.18 release
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?
00:00:00.017890 Host RAM: 262015MB (255.8GB) total, 2738MB (2.6GB) available
Maybe the freebsd build has a problem in this area?
Re: Discuss the 5.1.18 release
It is strange as native FreeBSD sysmon says:
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.
Code: Select all
Mem: 22M Active, 888M Inact, 109G Wired, 2648K Cache, 140G Free
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.
-
- Oracle Corporation
- Posts: 3362
- Joined: 7. Jun 2007, 09:11
- Primary OS: Debian Sid
- VBox Version: PUEL
- Guest OSses: Linux, Windows
- Location: Dresden, Germany
- Contact:
Re: Discuss the 5.1.18 release
I think I know the problem. Could you trySelin wrote:It is strange as native FreeBSD sysmon says:And now one guest with 60GB of RAM is running.Code: Select all
Mem: 22M Active, 888M Inact, 109G Wired, 2648K Cache, 140G Free
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.
Code: Select all
VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0
Re: Discuss the 5.1.18 release
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...
-
- Volunteer
- Posts: 2561
- Joined: 30. May 2007, 18:05
- Primary OS: Fedora other
- VBox Version: PUEL
- Guest OSses: XP, Win7, Win10, Linux, OS/2
Re: Discuss the 5.1.18 release
Klaus, you were looking too fast, it seems to be a dual CPU system:
00:00:01.170131 CPUM: Physical host cores: 12
00:00:01.170131 CPUM: Physical host cores: 12
Re: Discuss the 5.1.18 release
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).
-
- Volunteer
- Posts: 2561
- Joined: 30. May 2007, 18:05
- Primary OS: Fedora other
- VBox Version: PUEL
- Guest OSses: XP, Win7, Win10, Linux, OS/2
Re: Discuss the 5.1.18 release
So this would be a Virtualbox "logging bug" here?
I was used to the logs showing the number of logical / physical cpu cores correctly.
I was used to the logs showing the number of logical / physical cpu cores correctly.
Re: Discuss the 5.1.18 release
It's not a new bug, but clearly a bug. The information about the core/thread count should be available...
Re: Discuss the 5.1.18 release
Thanks! Will try on weekend.frank wrote:I think I know the problem. Could you tryCode: Select all
VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0
Could you share a bit more details - what this command do?
I don't know. It is by historical reason.klaus wrote:Why do you use the ICH9 chipset?
With VirtualBox 5.1.14 and earlier there was no problem with this.
Thanks. I really missed this nuance.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)"
Wonder to know - why HT cores shall not be used by virtual machines?
Looks like I have to re-read whole manual once again...
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Discuss the 5.1.18 release
Klaus, I feel that you needed to continue that sentence but somehow it got cut short. What did you mean "should be available" ?klaus wrote:It's not a new bug, but clearly a bug. The information about the core/thread count should be available...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Re: Discuss the 5.1.18 release
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 withsocratis wrote:Klaus, I feel that you needed to continue that sentence but somehow it got cut short. What did you mean "should be available" ?klaus wrote:It's not a new bug, but clearly a bug. The information about the core/thread count should be available...
VBoxManage show hostinfo, distinguishing between 'processor [online] count' and 'processor [online] core count'.
-
- Oracle Corporation
- Posts: 3362
- Joined: 7. Jun 2007, 09:11
- Primary OS: Debian Sid
- VBox Version: PUEL
- Guest OSses: Linux, Windows
- Location: Dresden, Germany
- Contact:
Re: Discuss the 5.1.18 release
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:Selin wrote:Thanks! Will try on weekend.frank wrote:I think I know the problem. Could you tryCode: Select all
VBoxManage setextradata VM_NAME VBoxInternal/Devices/acpi/0/Config/PciPref64Enabled 0
Could you share a bit more details - what this command do?
Code: Select all
00:00:01.075779 ACPI: enabling 64-bit prefetch root bus resource 0x0000002024000000..0x0000000fffffffff