VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (2359 - 2361 of 16363)

Ticket Resolution Summary Owner Reporter
#3834 obsolete OpenSolaris guest has high system time overhead Scott Fehrman
Description

We created an image using OpenSolaris 2008.11 (32-bit), MySQL, OpenDS, Glassfish to support applications. After the image boots, the apps have started and "steady state" is reached, the image has 30-35% system time constantly being consumed. We've seen this on vbox 2.0.x, 2.1.x, and 2.2.x.

We've seen this happen on the following Host OS platforms: OpenSolaris on Sun Ultra40 (AMD) Mac OS X on MacBookPro (Intel) Linux (Ubuntu 8.10) on Toshiba Laptop (Intel) Windows XP on Acer Laptop (AMD)

I "profiled the kernel" using a dtrace script and the kernel is calling: unixtsc_read / genunixgethrtime_unscaled A LOT.

I'll attach the output of the script and the dtrace script

This might be related to bug # 894

#3992 obsolete host-only networking slows down, high latency Scott Fehrman
Description

MacOS 10.5 using VBox 2.2.2 with OpenSolaris guest. Started having networking issues after upgrading to 2.2.2. Image works fine for 1-2 hours, using ssh / scp from host to guest. Then for no obvious reason the networking has large delays (2-10 seconds), type in command in ssh terminal and wait. Here is some "ping" data ...

macbook:[sfehrman] ping sedemo8
PING sedemo (192.168.100.101): 56 data bytes
64 bytes from 192.168.100.101: icmp_seq=0 ttl=255 time=13851.959 ms
64 bytes from 192.168.100.101: icmp_seq=1 ttl=255 time=12851.360 ms
64 bytes from 192.168.100.101: icmp_seq=2 ttl=255 time=11850.678 ms
64 bytes from 192.168.100.101: icmp_seq=3 ttl=255 time=10850.062 ms
64 bytes from 192.168.100.101: icmp_seq=4 ttl=255 time=9849.439 ms
64 bytes from 192.168.100.101: icmp_seq=5 ttl=255 time=8848.794 ms
64 bytes from 192.168.100.101: icmp_seq=6 ttl=255 time=7848.265 ms
64 bytes from 192.168.100.101: icmp_seq=7 ttl=255 time=6847.562 ms
64 bytes from 192.168.100.101: icmp_seq=8 ttl=255 time=5846.956 ms
64 bytes from 192.168.100.101: icmp_seq=9 ttl=255 time=4846.243 ms
64 bytes from 192.168.100.101: icmp_seq=10 ttl=255 time=3845.652 ms
64 bytes from 192.168.100.101: icmp_seq=11 ttl=255 time=2845.027 ms
64 bytes from 192.168.100.101: icmp_seq=12 ttl=255 time=1844.426 ms
64 bytes from 192.168.100.101: icmp_seq=13 ttl=255 time=843.721 ms
64 bytes from 192.168.100.101: icmp_seq=14 ttl=255 time=29428.120 ms
64 bytes from 192.168.100.101: icmp_seq=15 ttl=255 time=28427.485 ms
64 bytes from 192.168.100.101: icmp_seq=16 ttl=255 time=27426.888 ms
64 bytes from 192.168.100.101: icmp_seq=17 ttl=255 time=26426.605 ms
64 bytes from 192.168.100.101: icmp_seq=18 ttl=255 time=25426.004 ms
64 bytes from 192.168.100.101: icmp_seq=19 ttl=255 time=24425.402 ms
64 bytes from 192.168.100.101: icmp_seq=20 ttl=255 time=23424.780 ms
64 bytes from 192.168.100.101: icmp_seq=21 ttl=255 time=22424.066 ms
64 bytes from 192.168.100.101: icmp_seq=22 ttl=255 time=21423.472 ms
64 bytes from 192.168.100.101: icmp_seq=23 ttl=255 time=20421.088 ms
64 bytes from 192.168.100.101: icmp_seq=24 ttl=255 time=19420.491 ms
64 bytes from 192.168.100.101: icmp_seq=25 ttl=255 time=18419.905 ms
64 bytes from 192.168.100.101: icmp_seq=26 ttl=255 time=17419.179 ms
64 bytes from 192.168.100.101: icmp_seq=27 ttl=255 time=16418.473 ms
64 bytes from 192.168.100.101: icmp_seq=28 ttl=255 time=15417.836 ms
64 bytes from 192.168.100.101: icmp_seq=29 ttl=255 time=14417.111 ms
64 bytes from 192.168.100.101: icmp_seq=30 ttl=255 time=13416.476 ms
64 bytes from 192.168.100.101: icmp_seq=31 ttl=255 time=12415.752 ms
64 bytes from 192.168.100.101: icmp_seq=32 ttl=255 time=11415.001 ms
64 bytes from 192.168.100.101: icmp_seq=33 ttl=255 time=10414.306 ms
64 bytes from 192.168.100.101: icmp_seq=34 ttl=255 time=9413.643 ms
64 bytes from 192.168.100.101: icmp_seq=35 ttl=255 time=8842.514 ms
64 bytes from 192.168.100.101: icmp_seq=36 ttl=255 time=7841.669 ms
64 bytes from 192.168.100.101: icmp_seq=37 ttl=255 time=6839.962 ms
64 bytes from 192.168.100.101: icmp_seq=38 ttl=255 time=5839.377 ms
64 bytes from 192.168.100.101: icmp_seq=39 ttl=255 time=4837.303 ms
64 bytes from 192.168.100.101: icmp_seq=40 ttl=255 time=3836.596 ms
64 bytes from 192.168.100.101: icmp_seq=41 ttl=255 time=2835.894 ms
64 bytes from 192.168.100.101: icmp_seq=42 ttl=255 time=1835.271 ms
64 bytes from 192.168.100.101: icmp_seq=43 ttl=255 time=834.580 ms
--- sedemo ping statistics ---
71 packets transmitted, 44 packets received, 38% packet loss
round-trip min/avg/max/stddev = 834.580/12596.713/29428.120/8208.305 ms

A reboot of the image will restore normal host-to-guest performance, for another few hours.

#14980 fixed vbox freezes computer on restoring debian 7.0 ocasionally seymour
Description

On resuming a debian guest system on Windows 10 host, vbox occasionally freezes the computer while restoring. Sometimes it is for a half a minute and there is some slow mouse or keyboard response, other times Windows 10 reports DPC_WATCHDOG_VIOLATION and reboots the computer. If the restore manages to succeed eventually, the audio output does not work. For example, Timidity on Linux reports that everything is working but no audio comes out. To fix the issue I have to shut down (power off) -- not a restart -- and reboot Linux guest from vbox. The problem seems to occur after playing some video or audio files on Windows 10 using Windows Media Player. It may also occur when Windows 10 is also busy doing something else (like virus checks).

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