Bug#765490: xserver-xorg-video-vmware problem details
I have also been experiencing the window resize problems. My problems are
there
whether or not VMware tools as provided with VMware workstation 10 are
installed.
I have been running Debian Jessie recently installed from
debian-testing-amd64-netinst.iso in VMware workstation 10 running under
Windows
8.1.
Window resize was occurring when the 800x600 login screen was replaced by
the
1440x900 desktop (i.e. not full screen) that I have been using. I could
prevent
this resize by creating /etc/X11/xorg.conf and setting:
'Option "PreferredMode" "1440x900"' in 'Section "Monitor"'
Once the display resolution was made fixed then the problems disappeared
unless
I deliberately used the desktop System->Display configuration tool to change
the resolution to 800x600 for example and then back again.
The most obvious and consistent problems following resize were:
* On shutdown the Xorg process went CPU bound for about 90 seconds until
systemd gave up waiting and killed it and then shutdown proceeding
normally. Control
via the VMware desktop was lost as I could not try switching to a
different
virtual terminal etc.
* Attempting to switch to a different virtual terminal (CTRL ALT F1) instead
of
shutting down had the same effect. Although this time Xorg remained CPU
bound
indefinitely and control via the VMware desktop was again lost.
* The behaviour on logout from the desktop was similar to switching to a
different virtual terminal.
I then discovered that it was possible to still connect to the system via
ssh. This is how I
discovered that Xorg was becoming CPU bound.
If I killed the Xorg process then after a while a new one would be created
but
the displayed login screen was somewhat garbled. However killing Xorg, then
running 'systemctl stop gdm', then 'systemctl start gdm' usually (but not
always) provided a clean login screen and everything behaved normally.
I tried to download xserver-xorg-video-vmware-dbg but it does not exist so I
downloaded xserver-xorg-video-vmware-13.0.2 source and modified debian/rules
and debian/control to enable the production of debug symbols and then built
it.
I was then able to use gdb to connect to Xorg whilst it was stuck CPU bound
and
got traces like the following:
^C
Program received signal SIGINT, Interrupt.
vmwgfx_pixmap_present_readback (vsaa=0x7f6e388e5f40,
pixmap=0x7f6e3892d4b0, region=0x7f6e3892d528) at
../../vmwgfx/vmwgfx_saa.c:236
236 struct saa_pixmap *spix = saa_get_saa_pixmap(pixmap);
(gdb) where
#0 vmwgfx_pixmap_present_readback (vsaa=0x7f6e388e5f40,
pixmap=0x7f6e3892d4b0, region=0x7f6e3892d528) at
../../vmwgfx/vmwgfx_saa.c:236
#1 0x00007f6e3132118e in vmwgfx_download_from_hw
(driver=0x7f6e388e5f40, pixmap=0x7f6e3892d4b0, readback=0x7f6e3892d528)
at ../../vmwgfx/vmwgfx_saa.c:353
#2 0x00007f6e3132260d in vmwgfx_saa_drop_master (pScreen=<optimized
out>) at ../../vmwgfx/vmwgfx_saa.c:1608
#3 0x00007f6e3131b623 in drv_leave_vt (arg=0x7f6e388714e0) at
../../vmwgfx/vmwgfx_driver.c:1185
#4 0x00007f6e36f377d4 in xf86XVLeaveVT (pScrn=0x7f6e388714e0) at
../../../../hw/xfree86/common/xf86xv.c:1349
#5 0x00007f6e333a6f8d in glxDRILeaveVT (scrn=0x7f6e388714e0) at
../../glx/glxdri2.c:837
#6 0x00007f6e36f1ea97 in xf86VTLeave () at
../../../../hw/xfree86/common/xf86Events.c:492
#7 0x00007f6e36ee4bab in WakeupHandler (result=result@entry=2,
pReadmask=pReadmask@entry=0x7f6e372e1f40 <LastSelectMask>)
at ../../dix/dixutils.c:423
#8 0x00007f6e3703bee7 in WaitForSomething
(pClientsReady=pClientsReady@entry=0x7f6e38cf4520) at ../../os/WaitFor.c:229
#9 0x00007f6e36edfce1 in Dispatch () at ../../dix/dispatch.c:361
#10 0x00007f6e36ee4066 in dix_main (argc=17, argv=0x7ffff76893e8,
envp=<optimized out>) at ../../dix/main.c:296
#11 0x00007f6e34b9fb45 in __libc_start_main (main=0x7f6e36ece4e0
<main>, argc=17, argv=0x7ffff76893e8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7ffff76893d8) at libc-start.c:287
#12 0x00007f6e36ece50e in _start ()
I interrupted several times and vmwgfx_saa_drop_master() was always in the
stack trace
Looking at the source for vmwgfx_saa_drop_master() there is a loop that
steps
through vsaa->pixmaps.
WSBMLISTFOREACH(list, &vsaa->pixmaps) {
<SNIP>
}
I added the following diagnostics to the loop
if (limit < 50){
LogMessage(X_ERROR, "XXX (%d) list = 0x%lx\n", limit, list);
limit++;
}
to print out up to 50 list values before going silent.
Normally there were 7 different values (i.e. if no screen resize done).
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX hrg
vmwgfx_saa_drop_master entry. pixmaps = 0x7fc97184a0a8
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (1) list =
0x7fc971891620
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (2) list =
0x7fc971893f00
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (3) list =
0x7fc971aa27c0
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (4) list =
0x7fc971cdcab0
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (5) list =
0x7fc971cdcd90
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (6) list =
0x7fc971cd9bb0
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX (7) list =
0x7fc971cd9770
Oct 22 19:49:46 debian gdm-Xorg-:0[588]: (EE) XXX hrg
vmwgfx_saa_drop_master exit
Following a resize and an attempt at changing the virtual terminal the
diagnostics show that Xorg is stuck in the loop:
Oct 22 19:51:47 debian gdm-Xorg-:0[588]: (EE) XXX hrg
vmwgfx_saa_drop_master entry. pixmaps = 0x7fc97184a0a8
Oct 22 19:51:47 debian gdm-Xorg-:0[588]: (EE) XXX (1) list =
0x7fc971891620
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (2) list =
0x7fc971891620
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (3) list =
0x7fc971891620
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (4) list =
0x7fc971891620
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (5) list =
0x7fc971891620
<SNIP>
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (48) list =
0x7fc971891620
Oct 22 19:51:48 debian gdm-Xorg-:0[588]: (EE) XXX (49) list =
0x7fc971891620
It is interesting that list is always the same value
That is a as far as I have got so far. I may carry on a bit more but
debugging
Linux software is somewhat out of my comfort zone and also I am totally
unfamiliar
with Linux memory access checking tools.
Reply to: