Bug 1966

Summary: [Intel/i830] XServer hangup: i830+vmware
Product: xorg Reporter: Willi Richert <w.richert>
Component: Driver/intelAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: high CC: nolan, roland.mainz
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log when running correctly ;-) none

Description Willi Richert 2004-11-30 01:34:05 UTC 
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
Comment 1 Willi Richert 2004-11-30 01:36:12 UTC 
Created attachment 1426 [details]
Xorg.0.log when running correctly ;-)

Just in case someone needs more x-information.
Comment 2 Willi Richert 2004-11-30 01:49:52 UTC 
I have a FSC E-4010 Lifebook with an on-board Intel 855GM chip.
Comment 3 Nolan Leake 2004-11-30 15:55:54 UTC 
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.
Comment 4 Roland Mainz 2005-01-04 13:36:53 UTC 
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)).
Comment 5 Nolan Leake 2005-01-09 20:21:58 UTC 
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.
Comment 6 Roland Mainz 2005-01-10 00:54:15 UTC 
(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).
Comment 7 Egbert Eich 2005-03-03 06:56:11 UTC 
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.