Hi, from time to time, if I am in my WinXP session inside vmware (host=fedora core 2) my screen goes black and Xorg.log.old says: ======================================================= (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: ps2EnableDataReporting: succeeded Error in I830WaitLpRing(), now is 4293, start is 2292 pgetbl_ctl: 0x1fee0001 pgetbl_err: 0x0 ipeir: 0 iphdr: 7fffffff LP ring tail: 198 head: 3458 len: 1f001 start 0 eir: 0 esr: 0 emr: ffff instdone: ffc1 instpm: 0 memmode: 108 instps: 428 hwstam: ffff ier: 0 imr: ffff iir: 0 space: 12984 wanted 131064 (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xe00b1000 at 0x40117000 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. FatalError re-entered, aborting Caught signal 4. Server aborting ======================================================= lspci gives me: 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) vmware version: 4.5.2 build-8848 kernel 2.6.7 ============== XOrg version info ======================================== Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: Linux 2.4.21-23.ELsmp i686 [ELF] Current Operating System: Linux 2.6.7 #4 Tue Aug 3 14:30:51 CEST 2004 i686 Build Date: 16 November 2004 Build Host: bugs.build.redhat.com =============== xorg.conf =============================================== # XFree86 4 configuration created by pyxf86config Section "ServerLayout" Identifier "Default Layout" #Screen 0 "Screen0" 0 0 Screen 0 "Screen0" LeftOf "Screen1" Screen 1 "Screen1" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" # RgbPath is the location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. RgbPath "/usr/X11R6/lib/X11/rgb" FontPath "unix/:7100" EndSection Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" #Load "glx" #vmware hangs Load "record" Load "freetype" Load "type1" Load "dri" EndSection Section "InputDevice" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Option "Xleds" "1 2 3" # To disable the XKEYBOARD extension, uncomment XkbDisable. # Option "XkbDisable" # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: # Option "XkbModel" "pc102" # If you have a US Microsoft Natural keyboard, you can use: # Option "XkbModel" "microsoft" # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: # Option "XkbLayout" "de" # or: # Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" # # If you'd like to switch the positions of your capslock and # control keys, use: # Option "XkbOptions" "ctrl:swapcaps" # Or if you just want both to be control, use: # Option "XkbOptions" "ctrl:nocaps" # Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "LCD Panel 1400x1050" HorizSync 31.5 - 90.0 VertRefresh 59.0 - 75.0 #Modeline "1400x1050" 129.44 1400 1432 1920 1952 1050 1071 1081 1103 #Modeline "1024x768" 79.55 1024 1040 1216 1400 768 768 778 802 #Option "dpms" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName "Fujitsu Siemens E18-1" HorizSync 31.5 - 90.0 VertRefresh 59.0 - 75.0 EndSection Section "Device" Identifier "Videocard0" Driver "i810" VendorName "Videocard vendor" BoardName "Intel 852" Option "SWCursor" "off" Option "Rotate" "on" EndSection # Section "Screen" # Identifier "Screen0" # Device "Videocard0" # Monitor "Monitor0" # DefaultDepth 16 # SubSection "Display" # Viewport 0 0 # Depth 24 # #Modes "1400x1050" "1280x1024" "1024x768" "800x600" "640x480" # EndSubSection # SubSection "Display" # Viewport 0 0 # Depth 16 # #Modes "1400x1050" "1280x1024" "1024x768" "800x600" "640x480" # EndSubSection # EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" #DefaultDepth 24 SubSection "Display" Modes "1400x1050" "1280x1024" "1024x768" "800x600" Virtual 0 0 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Videocard0" Monitor "Monitor1" #DefaultDepth 24 SubSection "Display" Modes "1280x1024" "1024x768" "800x600" Virtual 0 0 EndSubSection EndSection Section "Screen" Identifier "Extern" Device "Videocard0" Monitor "Monitor1" #DefaultDepth 24 SubSection "Display" Modes "1280x1024" Virtual 1280 1024 EndSubSection EndSection Section "Screen" Identifier "Beamer1" Device "Videocard0" Monitor "Monitor0" SubSection "Display" Modes "1024x768" Virtual 1024 768 EndSubSection EndSection Section "Screen" Identifier "Beamer2" Device "Videocard0" Monitor "Monitor0" SubSection "Display" Modes "800x600" Virtual 800 600 EndSubSection EndSection Section "DRI" Group 0 Mode 0666 EndSection
Created attachment 1426 [details] Xorg.0.log when running correctly ;-) Just in case someone needs more x-information.
I have a FSC E-4010 Lifebook with an on-board Intel 855GM chip.
VMware running from the X server's perspective: whatever drawing the GTK based UI does, a bunch of XShmPutImages, a few XCopyAreas and a few XFillRectangles. There are also some XSyncs and XFlushes in there. Nothing out of the ordinary.
Nolan Leake wrote: > VMware running from the X server's perspective: whatever drawing the GTK > based UI does, a bunch of XShmPutImages, a few XCopyAreas and a few > XFillRectangles. There are also some XSyncs and XFlushes in there. Nolan: Is there a way to force the usage of the non-MIT-SHM codepath (e.g. where VMware then uses |XPutImage()| instead of |XShmPutImage()|) ? This may help in the cases where the MIT-SHM extension may cause crashes and on platforms where the host OS X11 transport may be faster than the MIT-SHM (this is true for Solaris (this is a general observation, no measurements have been made with VMware itself yet as a port of the VMware software to Solaris/x86 is still unavailable) when the shared memory X transport is being used (e.g. all traffic is going through the shared memory and not only the image data)).
Roland: Adding "mks.noSHM = TRUE" to your .vmware/config (or your per VM .vmx file) will disable use of MIT-SHM. Incidentally, I'm very surprised to learn that unix domain sockets are faster than SHM XImages on Solaris. re: solaris/x86 VMware port, it should be a fairly straightforward exercise for anyone knowledegable about both the linux and solaris kernels to port the vmmon driver; in theory, lxrun should then be able to run the UI and VMX. This is roughly how the third-party FreeBSD port came into being.
(In reply to comment #5) > Incidentally, I'm very surprised to learn that unix domain sockets are faster > than SHM XImages on Solaris. Uhm, no. Solaris's Unix domain sockets are faster than the Linux versions (Solaris 10 vs. Linux 2.6.x) but I was thinking here about Sun's shared memory X transport. Solaris's Xsun server and libX11.so have an alternative transport method which pushes all X traffic through shared memory - making X11 data transfers (including images) much faster for large data moves (and it reduces client<-->server latency, too).
This is a duplicate of 1353. The first comment shows the typical ring buffer lockup. Most other comments are unrelated to the original problem. *** This bug has been marked as a duplicate of 1353 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.