Arch host, Win7 guest BSODs: BIOS not fully acpi compliant

[skoehler]

In the official 6.0.6 source tarball, the file Config.kmk contains the line

VBOX_SVN_REV_FALLBACK := $(patsubst %:,,  $Rev: 129722 $  )

So could it be the source tarball contains outdated sources? I used this one:
https://download.virtualbox.org/virtual ... .6.tar.bz2

[kylef]

Hopefully this isn't a double post...

I filed a bug report on the arch site for the virtualbox package. Hopefully we'll get to the bottom of it. These forums won't let me post a link yet...

[skoehler]

https://bugs.archlinux.org/task/62381

[socratis]

In the official 6.0.6 source tarball, the file Config.kmk contains the line ... So could it be the source tarball contains outdated sources?

I came to the same conclusion while troubleshooting an Arch host problem with a Win10-64 guest. The revision wasn't matching!

Then I took a look at the 6.0.4 one, and in the Config.kmk I see:

VBOX_SVN_REV_FALLBACK := $(patsubst %:,,  $Rev: 128164 $  )

while the official release is 6.0.4-128413.

We might need some clarification from the devs about that part...

[yan12125]

Where can I find sources for r130049? The current SVN trunk is only r77983:

Code: Select all

$ LC_ALL=C svn info
Path: .
Working Copy Root Path: /home/yen/tmp/vbox
URL: https://www.virtualbox.org/svn/vbox/trunk
Relative URL: ^/trunk
Repository Root: https://www.virtualbox.org/svn/vbox
Repository UUID: cfe28804-0f27-0410-a406-dd0f0b0b656f
Revision: 77983
Node Kind: directory
Schedule: normal
Last Changed Author: vboxsync
Last Changed Rev: 77983
Last Changed Date: 2019-04-02 18:26:01 +0800 (Tue, 02 Apr 2019)

I'd like to build r130049 from sources on Arch to see if the difference in versions is the key or not.

[socratis]

Where can I find sources for r130049?

That seems to be the mystery of the day!

The current SVN trunk is only r77983

Actually the "only" is misplaced in your sentece. The public trunk has nothing to do with the releases trunk, the public trunk is way ahead! What you're looking at the trunk is actually VirtualBox 6.1.x...

I'd like to build r130049 from sources on Arch to see if the difference in versions is the key or not.

Read my post above. I observed the same situation for 6.0.4 as well, but there were no complaints. Awaiting some sort of explanation from the developers about this revision discrepancy, which apparently no one has noticed before...

[WFV]

Let's see...

add one more to list
for now downgrade to 6.04 works. Win7pro64 guest on Arch host.
EDIT: removed cruft, didn't see page 2 of this thread.

[michael]

I will quickly clear up both issues (I had to check the Config.kmk one myself). First of all, what we have in the public Subversion repository is not quite the same as our internal sources. The public one is a near mirror of the internal one. But in the internal one we have a few closed source parts. The difference in the revision numbers is because 1) changes touching only closed source are not mirrored to the public repository and 2) the public one was started later, at the time when VirtualBox was first made open source, and does not contain history for older changes, just a single change containing everything. Most of the changes in the public repository match internal changes one-to-one, and vice versa. The branches from which releases are made are not public. This is due to a lack of time, not to a decision. So 6.0 at revison 130049 will be quite different from trunk, which is publicly mirrored, at say revision 130050. (A given revision is either a change to trunk or to a branch, but that is details about how Subversion works, you can check their documentation.) Releases are done from the internal tree, but closed source bits are stripped from the tarball.

The second issue with VBOX_SVN_REV_FALLBACK: this is the internal revision at which Config.kmk was last modified. It will always be lower than the release revision, because the release revision usually only modifies Version.kmk and a few other files.

[JamesMac]

I also have experienced the same BSOD issue on a Windows 7 client with an Arch Linux host. I experienced a different error when rolling back to 6.0.4 resulting in me not even being able to launch virtualbox prior to starting a VM, so I went back to 6.0.6 for now until a solution is reached for the ACPI compliance issue.

The following was the virtualbox pop-up message after rolling back to 6.0.4, but I don't want to derail this topic to a different issue, especially since I already went back to 6.0.6.

Code: Select all

Failed to create the VirtualBoxClient COM object. The application will now terminate.  Callee RC:  NS_ERROR_FACTORY_NOT_REGISTERED

[klaus]

VBOX_SVN_REV_FALLBACK is simply placed in the wrong file since Version.kmk was split off Config.kmk. Moving this variable to Version.kmk will fix this for good. It's a regression which wasn't noticed on the Oracle side...

[socratis]

Or in plain English, there's no

• "It's a conspiracy theory"
• "Meh, opensource friendly Oracle"
• "Oracle must have changed it silently"
• "Maybe the updated the binaries but forgot to update the source code tarball"

or anything close to that, that I've heard over this...

[michael]

We changed it so silently we didn't notice ourselves.

[socratis]

Confirmed, the official version works well.

Thanks @pepitogrillo for confirming that the generic, "All distributions" 6.0.6 release works fine.

On top of that, since we now know that there's no discrepancy/difference between the released revision 130049 and the tarball revision 129722 (except an artificial one), that can only mean one thing; a patch (or two) from Arch is doing this.

[pepitogrillo]

Confirmed, the official version works well.

Thanks @pepitogrillo for confirming that the generic, "All distributions" 6.0.6 release works fine.

On top of that, since we now know that there's no discrepancy/difference between the released revision 130049 and the tarball revision 129722 (except an artificial one), that can only mean one thing; a patch (or two) from Arch is doing this.

Sorry, I deleted my previous post because I had posted it without reading all the follow-up messages.
Yes, the official version works well on Arch with Windows 7.

[yan12125]

@michael Thank you very much for detailed explanations around the public repo and the internal repo!

Given the VirtualBox source tarball is OK, I tried to investigate what happens to the Arch build. I created a new Arch Linux VM and run acpidump [1] in official and Arch VirtualBox builds, respectively. SSDT and DSDT table contents are different. Is it expected? Which source files in VirtualBox control those tables?

There are two files in the attached acpi-tables.tar - acpi-arch.txt contains output of acpidump for the VM running on VirtualBox provided by Arch Linux, and acpi-official.txt is retrieved with the same approach on official VirtualBox build.

[1] https://www.archlinux.org/packages/comm ... 64/acpica/