Custom Query (16363 matches)
Results (2359 - 2361 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3834 | obsolete | OpenSolaris guest has high system time overhead | ||
| 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: unix 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 | ||
| 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 | ||
| 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). |
|||

