Non-stop assertion failure kernel log messages after 5.2.10 update

[jakemoroni]

Hello,

I've just recently updated to the latest 5.2.10 release and I've since been getting non-stop kernel log messages whenever my guest OS is running. I've actually had to disable logging since my syslog/kern.log files grew to a few gigabytes in just one day.

The log messages are as follows:

rcStrict=2624 GCPhys=00000000f0804030

AssertLogRel /home/vbox/vbox-5.2.10/src/VBox/VMM/VMMAll/PGMAllPhys.cpp(2345) VBOXSTRICTRC pgmPhysReadHandler(PVM, PPGMPAGE, RTGCPHYS, void*, size_t, PGMACCESSORIGIN): PGM_HANDLER_PHYS_IS_VALID_STATUS(rcStrict, false)

The host is an Ubuntu 16.04 64 bit system running kernel 4.15, and the guest is an Ubuntu 16.04 64 bit system running kernel 4.13. The host CPU is an Intel Xeon E3 1275v6 (Kaby Lake).

I've attached the machine log for more details.

This is my first bug report here, so please let me know if there's anything else I should include.

Thanks, Jake

[jakemoroni]

Virtual machine log

[Socratis]

00:00:00.164336 Console: Machine state changed to 'Restoring'

For a "proper" VBox.log, you should always start the VM from a cold-boot, i.e. not from a "Paused" or a "Saved" state. We get a lot more information during the boot phase of the VM. So, could you please:

• Follow a "start the VM from cold-boot" / "observe error" / "shutdown the VM" cycle.

• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".

• Save only the first "VBox.log", ZIP it and attach it to your response.

Here's what I was able to gather, which is not a lot, because the VM was 1) resumed but most importantly 2) you grabbed the log while the VM was running. Please give it another shot as described above...

---

00:00:00.219916 NumCPUs <integer> = 0x0000000000000004 (4)
00:00:00.366446 CPUM: Physical host cores: 4

You have assigned all your CPUs to the VM. The host is going to run low on resources, since VirtualBox cares about physical processors, not logical ones. And your ​Xeon E3-1275 has 4 cores.

---

00:00:00.219916 [/Devices/hda/0/LUN#0/AttachedDriver/] (level 5)
00:00:00.219916   Driver <string>  = "NullAudio" (cb=10)

Any particular reason why you decided to deviate from the proposed default ICH AC97 and go with the Intel HDA? Especially when it seems that you don't really care about the sound?

---

[jakemoroni]

VM cold start

[jakemoroni]

Hello,

Thanks for the response. I've added the attachment "start_shutdown.zip" which includes the log. Please ignore the "cold_start.log" attachment. I uploaded that one by accident and don't know how to remove it.

The procedure performed was as follows:

• Start the VM from the GUI.
• Periodically observe the host kernel log via dmesg.
• No errors were produced while the guest was still sitting on the login screen.
• Log into the guest VM.
• At this time, the errors started to appear in the kernel log.
• Shutdown the guest OS.
• Capture the log.

To answer your questions:

• I understand your point about assigning all "actual" CPU cores (not logical) to the guest OS. I did this on purpose to improve performance on the guest, as it's actually used more heavily than the host. That said, the errors are still produced even when the host CPU is almost idle. I will reduce the number of cores to 1 to see if it makes a difference.

• As for the audio, that was probably a leftover from when I was trying to figure out how to get audio to work over RDP (which is normally how I use the guest). That's why the host audio driver was set to null, but sound still enabled. I'll change it back to AC97 to see if it makes a difference.

I'll report back if the two changes above fix the issue.

Thanks, Jake

[jakemoroni]

VM cold start and shutdown

[jakemoroni]

Okay, so I just tested the two changes above and was able to get the messages to stop.

Reducing the number of CPUs from 4 to 1 didn't make a difference.

However, changing the audio from "Intel HD Audio" to "ICH AC97" seems to have eliminated the messages.

I've done multiple start/login/shutdown cycles and the messages have not returned. As soon as I change it back to "Intel HD Audio", the messages return.

I'm not sure where to go from here, but at least in my case, this issue is resolved.

[Socratis]

Excellent news! That's why trying different settings is one thing, but reverting to the suggested defaults? That's a whole different ball game! You know what I usually do when I get carried away change-wise and I forgot what did I change, at what point, and with the exact result? I create a new temp VM of the same kind and I text-compare the ".vbox" files. That gets me back on track. And then I decide to start making notes... :D

Really glad you got it going, I guess the ticket can be closed as [Invalid].

BTW, keep in mind that it's usually better and faster, if issues get first addressed in the ​VirtualBox forums. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is not a bug and someone from the developers has to deal with it and close it as "Invalid".