Custom Query (16363 matches)
Results (814 - 816 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #5948 | obsolete | Eject CD/DVD does not work from windows guest | ||
| Description |
opensuse v11.1 host linux 2.6.27.39-0.2-default x86_64 guest winXP sp3 The CD/DVD "Passthrough" option is enabled for the guest. A CD burning program, Nero Burning ROM, can burn a CD and when completed, actually eject the disk. However, after reinserting the CD to verify the result (which verified), it is not possible to again eject the disk. Opening "My Computer", RMB on on the CD/DVD to obtain the context menu, and select "Eject", does not produce the expected result, namely an opened drive; nothing happens. Sometimes not even the root in the host can eject the disk: "inappropriate ioctl". Only logging out of the windows account (shutdown not required) seems to release the drive to the extent that root can then operate it. |
|||
| #5960 | obsolete | vm crashes as soon as I try to connect to a network source (pgmRCGst32BitGetPage, raw mode) | ||
| Description |
The vm crashed and asked me to send the log and the screenshot. Below is the log. I will be grateful if you fix it. |
|||
| #5961 | obsolete | VBoxManage hangs on futex wait | ||
| Description |
I have an automated system which keeps about four VirtualBox guests (various guest operating systems) running. Each guest runs for a few hours - when it shuts down, the driver script uses VBoxManage to destroy the VM, import and configure a new one and finally start the newly imported VM. The driver script also uses VBoxManage to query the status of running VMs (list runningvms, showvminfo etc.). Every now and then (a few times a week) I end up having VBoxManage processes hanging doing nothing. They appear to be frozen - output from 'top' claims they sleep on the futex_wait channel. If I run a "VBoxManage list vms" manually (or any other VBoxManage command that interacts with the virtual machines), it too will just hang indefinitely. My guess is that the VBoxManage commands all talk to the same common daemon (VBoxSVC?), and that this daemon somehow doesn't respond. But I have no way of debugging this any further. Is there anything I can do to help resolve this issue? Does VBoxSVC log information somewhere I didn't see? Would it be helpful with an strace/backtrace/...? Is anyone else seeing this issue? The host system is Debian Lenny (linux 2.6.26-2-amd64); I also a parallel VB setup on Solaris where this problem never occurs (Solaris doesn't have futexes of course). |
|||

