Custom Query (16363 matches)
Results (1237 - 1239 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #7549 | obsolete | VirtualBox 3.2.8, Windows 7 Guests Startup Hangs, and "VBoxVideo: using HGSMI" | ||
| Description |
When running immutable guest sessions of Windows 7, with VRDP enabled, there seems to be a sporatic issue with start up hangs. Ee will VRDP into the child session do a couple reboots and about half the time it will hang at the "Starting Windows" screen. When looking at the log it always hangs at: 01:39:03.400 Guest Log: VBoxVideo: using HGSMI These sessions are configured:
Please see attached logs for additional details |
|||
| #7554 | obsolete | CD DVD Roms and USB Devices disappeared | ||
| Description |
I tried to format my flash drive in ubuntu and I unmounted the flash drive by mistake. I removed and pushed it in my computer again and it did not show in the device menu under USB, but my webcam was shown as a usb device, so I clicked it and windows 7 started to install the VirtualBox Usb driver and the driver installation failed. I then went to the device menu and saw that there was no devices in the cd/dvd menu and no devices in the usb menu. I closed the guest ubuntu system and when I tried to restart it said invalid state and some number in hex. I have two screen shots of the bug. |
|||
| #7558 | obsolete | Intermittent packet loss in Mac OS X host | ||
| Description |
This has been ongoing over all recent revisions of Virtualbox 3.1.x and 3.2.x, OS X Server 10.6.x (up to 10.6.4) Running Virtualbox on a Mac OS X Server host causes intermittent UDP packet loss for the host. The major symptom is that other clients on the network are periodically unable to successfully resolve names via DNS when trying to contact Apple supplied BIND named running on the host. The intermittent nature is why it has taken so long to isolate Virtualbox (more likely the network kext installed by StartupItem on the host) as the cause. Clients intermittently report no DNS server can be found when trying to resolve well-known domains (eg www.google.com). Server logs for named (when extended debug logs enabled) report repeatedly "Success resolving /foo/ after reducing the advertised EDNS UDP packet size to 512 octets" The client is actually timing out while the server fails to respond to that particular name lookup (other lookups for other domains continue as normal). It looks like some UDP packets are being dropped. I've only noticed it for DNS, Using "dig" to investigate will often "unclog" things and clients can again resolve the problem domain for a while. (Using nslookup does not, it just reports the same timeout) If it makes a difference, the Guest(s) were using bridged networking over the host's ethernet interface. The guest does not seem to exhibit any problems apart from the same issues resolving DNS using named running on the host. |
|||

