Custom Query (16363 matches)
Results (151 - 153 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #9866 | fixed | when IO-ACPI is enabled, VM's will cause system-wide (host) freeze | ||
| Description |
My host is HP ProLiant ML370 G5 E5410 Intel Xeon 2.33GHz/12M 1333, 4 GB HP SA P400/256 RAID SAS, BBWC, DVD-RW 10/100/1000 lan 6x HP HDD 72GB, SAS-I 15K, 2.5' hot plug I use binaries for SLES 10, 64bit - http://download.virtualbox.org/virtualbox/4.1.6/VirtualBox-4.1-4.1.6_74727_sles10.1-1.x86_64.rpm Host OS is SLES 10, SP1 and I want to install single guest OS, preferrably windows 7 64bit, for that, I need VT-x enabled, so: 1, I've upgraded BIOS to latest version (2011.05.02, 20 Jul 2011) and enabled "No-Execute Memory Protection" and "Intel® Virtualization Technology" options in BIOS. 2, I did cold restart (plugged out power cord before) 3, I've installed Virtualbox (specific build for SLES10, 64bit) 4, When I enable IO-ACPI option in VM's settings, whole machine will freeze shortly after start, sometimes 5seconds, sometimes 2minutes. It doesn't matter if VT-x is enabled or not, nor if I've assigned 1 or 3 CPU's to the VM, nor the amount of memory, nor if the VM is 32bit or 64bit. It seems like I've tried all the combination, but it all goes down to "IO-ACPI" feature. I enable it, machine freezes (not only gdm, the whole machine, I can't even switch to command line) I want to use 64bit guest and be able to assign more than 1 cpu core to the VM and without IO-ACPI it's not possible, so I'm stuck here. I've attached log from my last attempt to start installation of win7, 64b, but from what I see, freeze is random and there is nothing obvious in virtualbox log. I also browsed the linux system logs, but found nothing helpful. System just hangs and needs cold restart. |
|||
| #4807 | obsolete | wglMakeCurrent fails when 3D acceleration is enabled | ||
| Description |
I'm trying to get a commercial visualization product running on a Windows XP32 (sp2) guest hosted by either Windows Vista64 or Windows 7. The render/paint method for a canvas is basically: enableTheContext() renderWhatNeedsRendering() swapBuffers() disableTheContext() The method that enables the context first saves away the current rendering and device contexts by calling wglGetCurrentContext() and wglGetCurrentDC(); then it calls wglMakeCurrent to make the canvas's context current. This call to wglMakeCurrent succeeds. However, when the disable context method is called after rendering, which tries to restore the context previously saved by the enable method, wglMakeCurrent fails. All of this happens very soon after app startup, so it appears to crash almost immediately. However, since I can't debug the low-level code, I can't say for certain if the problem occurs on the first rendering pass, or very soon thereafter. If the app is run outside of vbox - or if the app is run in vbox w/o 3D acceleration enabled - everything works dandy. (Obviously if run in vbox w/o 3D acceleration it is very slow). A couple of possibilities come to mind for reasons why this issue occurs: 1) There's a good chance that on the first rendering pass the previous context is NULL; maybe your implementation of wglMakeCurrent is not handling a NULL context properly. 2) A threading issue. There's some small chance that the previous context is from a different thread. Are these vbox drivers threadsafe? One other interesting tidbit from our internally generated log file (which may or may not be useful): right before the app crashes, the following is logged: OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU |
|||
| #8662 | obsolete | weird PID in exception raised by mach.LockMachine | ||
| Description |
From a script displaying the currently running VMs, I get a weird traceback under unclear circumstances (say once every 1000 run or something): vboxslave.py running Traceback (most recent call last):
xpcom.Exception: 0x80070005 (An unexpected process (PID=0x00003768) has tried to lock the machine 'freebsd-8.0-64bits', while only the process started by launchVMProcess (PID=0xFFFFFFFF) is allowed) I have no idea where to look for that in the code, but PID=0xFFFFFFFF probably indicates a bug somewhere. At the very least, it shouldn't generate such a backtrace but point the user to something more meaningful about the cause. |
|||

