Custom Query (16363 matches)
Results (457 - 459 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #12804 | obsolete | Toolbar misaligned in fullscreen after host display resize | ||
| Description |
When my host display is resized, and a VirtualBox guest is running in fullscreen mode, the toolbar at the top is misaligned. For example, I start in 1024x600 controlling the host display remotely through x11vnc, and the toolbar for my Windows XP VM is centered to the current display width. When I leave the VM running, then get in to work and no longer need x11vnc, I switch the display to its natural size, 1440x900 using xrandr. The toolbar is now off-center to the left, whereas I expected it to be centered in the new display width. Pressing Host-F twice to toggle out of and back into fullscreen mode recenters the toolbar properly. This is an acceptable workaround, but it would be nice to restore the original behaviour as I recall it: I no longer have 4.3.6 handy to verify, but I believe this did not happen in the versions prior to 4.3.8. Thanks, Ben |
|||
| #11821 | invalid | X server fails on 32-bit Fedora 19 with Guest Additions installed -> Fedora issue | ||
| Description |
I am using VirtualBox guests running Fedora(RC 3.1). My 32-bit Fedorabefore installing Guest Additions. After Guest Additions are installed, the X server no longer starts correctly. Instead I am simply left with a completely black screen. No mouse pointer or text cursor visible at all. Strangely, my 64-bit Fedora(RC 3.1) guest works fine both before and after installing Guest Additions. So whatever is going wrong here seems to be specific to 32-bit environments. Once the guest is in this state, it is not completely frozen. I can ssh into it remotely, it responds properly to ACPI shutdown requests, etc. Just the display is broken. By ssh'ing in remotely after the failure I can observe that no "X" or "Xorg" process is still running. So whatever went wrong, it killed the X server entirely. The last line of "/var/log/Xorg.0.log" reads "(EE) AIGLX error: vboxvideo does not export required DRI extension". But this is probably *not* the fatal problem. I see that same message in the X server log for my working 64-bit guest, followed by several more lines that reveal that the X server is falling back on software rendering: (EE) AIGLX error: vboxvideo does not export required DRI extension (EE) AIGLX: reverting to software rendering (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen My 32-bit guest's X server apparently dies after printing just the first of the about . I've tried ssh'ing in remotely, then launching Xorg within gdb, all as root, to see where the X server is dying. gdb shows the following clues: ... (initial X server output removed for brevity) ... Initializing built-in extension XFree86-DRI Initializing built-in extension DRIMissing separate debuginfo for /usr/lib/xorg/modules/drivers/vboxvideo_drv.so [tcsetpgrp failed in terminal_inferior: Operation not permitted] Missing separate debuginfo for /usr/lib/dri/vboxvideo_dri.so Missing separate debuginfo for /lib/VBoxOGLcrutil.so Program received signal SIGSEGV, Segmentation fault. _dl_fixup (l=60, reloc_arg=576) at dl-runtime.c:74 74 = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset); The gdb-reported stack trace at this point of failure is: #0 _dl_fixup (l=60, reloc_arg=576) at dl-runtime.c:74 #_dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:36 #__glXDRIscreenProbe (pScreen=66948) at glxdri.c:1148 #() at glxext.c:355 #(argc=argc@entry=1, argv=argv@entry=4) at ../../../mi/miinitext.c:337 #(argc=1, argv=4, envp= at main.c:208 |
|||
| #16418 | duplicate | Critical Error (VERR_IEM_INSTR_NOT_IMPLEMENTED, stmxcsr) | ||
| Description |
Randomly closes with critical error. After update 5.1.12 |
|||

