VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (736 - 738 of 16363)

Ticket Resolution Summary Owner Reporter
#19313 obsolete random network dropouts SkipMMT
Description

Since upgrading the linux host to VirtualBox-6.1.2, the linux guest has been experiencing random network dropouts, 1 to 10 times a day, lasting for a few seconds. At these times, the linux guest reports:

Feb 13 20:04:59 kernel: e1000 0000:00:03.0 eth0: Reset adapter
Feb 13 20:05:01 kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

After downgrading to VirtualBox-6.0.16, the dropouts and the messages disappear.

#19312 fixed Linux: kernel 5.6 - we need changes (fixed in 6.1.6, 6.0.20 and 5.2.40) Frank Batschulat (Oracle) Frank Batschulat (Oracle)
Description

So mainline 5.6-rc1 is out and we have already 1 change required:

In file included from /home/ws/vbtrunk/trunk/out/linux.amd64/debug/obj/tstvboxguest-src_mod/combined-os-specific.c:33:0:
/home/ws/vbtrunk/trunk/out/linux.amd64/debug/obj/tstvboxguest-src_mod/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapKernel’:
/home/ws/vbtrunk/trunk/out/linux.amd64/debug/obj/tstvboxguest-src_mod/r0drv/linux/memobj-r0drv-linux.c:1465:32: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Werror=implicit-function-declaration]
                              ? ioremap_nocache(pMemLnxToMap->Core.u.Phys.PhysBase + offSub, cbSub)
                                ^~~~~~~~~~~~~~~
                                ioremap_cache
/home/ws/vbtrunk/trunk/out/linux.amd64/debug/obj/tstvboxguest-src_mod/r0drv/linux/memobj-r0drv-linux.c:1466:30: error: pointer/integer type mismatch in conditional expression [-Werror]
                              : ioremap(pMemLnxToMap->Core.u.Phys.PhysBase + offSub, cbSub);

                              ^

This is due to:

https://github.com/torvalds/linux/commit/4bdc0d676a643140bdf17dbf7eafedee3d496a3c
https://github.com/torvalds/linux/tree/master/drivers/usb/early

ioremap has provided non-cached semantics by default
since the Linux 2.6 days, so remove the additional
ioremap_nocache interface.

Merging generic-ioremap/for-next (4bdc0d676a64 remove ioremap_nocache and devm_ioremap_nocache)

https://www.spinics.net/lists/netdev/msg623588.html
https://lkml.org/lkml/2020/2/4/275

obvious fix:
=> replace use of ioremap_nocache() with ioremap_cache()

Edit:

ioremap_cache() is uncached by default since a long time.

all 5.X kernels down to version 5.0 all 4.X kernels down to version 4.0 all 3.X kernels down to version 3.0

from version 2.6.25 onwards we know for sure that ioremap_cache() has uncached semantics by default.

https://elixir.bootlin.com/linux/v2.6.25/source/include/asm-x86/io_64.h#L161

 * This one maps high address device memory and turns off caching for that area.
 * it's useful if some control registers are in such an area and write combining
 * or read caching is not desirable:
 */
extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);

/*
 * The default ioremap() behavior is non-cached:
 */
static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
{
	return ioremap_nocache(offset, size);
}

That means we can and should replace ioremap_nocache() usage with ioremap_cache() and make kernel version 2.6.25 the tipping point for this.

#19311 invalid Changes on Archlinux 1/27/20 to support Linux 5.5 cause 10 min. boot of guest after downgrade to Linux 5.4 drankinatty
Description

This issue was first discussed on the virtualbox-users list on 2/4/20 under the thread "[VBox-users] 5.5 kernel and 5.2.36 - Does this not work with the new 5.2.36?"

Following direction to https://www.virtualbox.org/ticket/19145 I was directed to file a separate bug and submit the strace and dmesg output for the guest here.

I build the 5.2.x branch for the AUR repository. https://aur.archlinux.org/packages/virtualbox-bin-5/

During update on 2/4/20, Archlinux moved to Linux 5.5 kernel. The virtualbox drivers built and on reboot starting my Archlinux guest headless, virtualbox reports that the guest started. 5 minutes later the boot had yet to complete and a poweroff was issued. So I built with 5.2.36 - same result, so I built with testcase 5.2.37 (135942), same result.

After posting to the vbox-users list and being informed of https://www.virtualbox.org/ticket/19145 and 5.2 not yet supporting Linux 5.5 kernel, I downgraded my host. The same problem remained, but this time I just left the boot of a simple Archlinux guest that boot to a text console running. After 10 minutes -- the boot succeeded, but the guest was unusably slow.

For example, users cannot login because the 90 second login timeout expires between the time the user enters their user name and presses [Enter] and the display of the 'password:' prompt. root can login as there is no 90 second timeout (takes about 120 seconds for 'password:' to display after entering user name.

All was fine on 1/27/20 when I last updated the guest to the Linux 5.4.14 kernel. I have downgraded both the host and guest multiple times to the package/kernel state they were in on 1/14/20, 1/21/20, 1/24/20, and 1/27/20. The guests are still unusable. It is like a config or something similar was modified to support the 5.5 kernel that isn't reverted on downgrade (or something similar) that is causing the problem. That's the only reason I can think that downgrading the entire system before the point the problem appeared does not resole the issue. I have a number of guests I use, and all was well before the 5.5 update.

I have attached a strace of the communication between the Archlinux host and Archlinux guest. I am no expert interpreting the strace communications, but when each bit of I/O is taking more than 10 seconds -- that looks like an issue to me. I have also attached the dmesg output from the Archlinux guest after waiting though the 10 minute boot (it normally boots fully in less than 20 seconds).

I'm happy to provide anything else you can think of that may identify the issue.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy