Bug 78233

Please attach your config file and X server log.

Created attachment 85684 [details]
the good (normal) log

Created attachment 85685 [details]
the bad (abnormal) log

I made one error in my initial report.  This problem does NOT occur with a
simple restart of the X server.  In order for the problem to occur as described,
I must reboot.

Here is my XF86Config file:

# File generated by anaconda.

Section "ServerLayout"
	Identifier     "Anaconda Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Mouse1" "SendCoreEvents"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
# 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  "dri"
	Load  "glx"
	Load  "record"
	Load  "freetype"
	Load  "type1"
EndSection

Section "InputDevice"
#	Option	"AutoRepeat"	"500 5"
# when using XQUEUE, comment out the above line, and uncomment the
# following line
#	Option	"Protocol"	"Xqueue"
# 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"
	#Option	"XkbOptions"	""
	Identifier  "Keyboard0"
	Driver      "keyboard"
	Option	    "XkbRules" "xfree86"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us"	#Option	"XkbVariant"	""
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "PS/2"
	Option	    "Device" "/dev/psaux"
	Option	    "ZAxisMapping" "4 5"
	Option	    "Emulate3Buttons" "yes"
EndSection

Section "InputDevice"
	Identifier  "Mouse1"
	Driver      "mouse"
	Option	    "Device" "/dev/input/mice"
	Option	    "Protocol" "IMPS/2"
	Option	    "Emulate3Buttons" "no"
	Option	    "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
	HorizSync    31.5 - 48.5
	VertRefresh  50.0 - 70.0
	Option	    "dpms"
EndSection

Section "Device"
	# no known options
        #BusID
	Identifier  "SiS 6326"
	Driver      "sis"
	VendorName  "SiS 6326"
	BoardName   "SiS 6326"
#	VideoRam    8192
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "SiS 6326"
	Monitor    "Monitor0"
	DefaultDepth     16
	SubSection "Display"
		Depth     16
		Modes    "1024x768" "800x600" "640x480"
	EndSubSection
EndSection

Section "DRI"
	Mode         0666
EndSection

I'm not sure what your normal timeframes are but I was curious about the status
of this since I hadn't heard anything since the date of my initial report.  Do
you need additional info perhaps?

The timeframe, is basically whenever I have a chance to get to look at a
given bug in the queue of 400 bugs that are assigned to me.  That might
be a week, or it might be 9 months, it's hard to say.

Anyway... back to the problem at hand.  First off, please don't ever
cut and paste large bodies of text into the bug reports like the config
file above - always use a file attachment.

Looking through both log files, and the attached config file, I am not
sure I understand exactly what the problem is that you are describing.

You have indicated that you want to force-set the video RAM to a specific
size, and your log files show it doing just that by my eyes.

Also note that it is not "Red Hat" using a default of 4Mb.  Red Hat is
a company, Red Hat Linux is the product, and XFree86 is the specific software
that you are using.  If there is a problem, it is an XFree86 problem, not
a Red Hat problem.  A subtle and perhaps pedantic difference, but an important
one nonetheless.  It is entirely possible that XFree86.org changed this
driver in some way that perhaps changes the behaviour that you expect. If
that is the case, it is possible that there is an explanation for such a
change, and possibly even a newer driver available that fixes the problem.
I don't really understand what the problem is however so I can't really comment
further without more information.  I also do not have any SiS video hardware
available to test this or do any troubleshooting with actual hardware if there
is indeed a problem.

Please be more specific and detailed in your report.  Also, please try the
XFree86 CVS RPM packages that are in rawhide, as they contain an entirely
new SiS driver which may or may not resolve the issue you are experiencing
if there is indeed a bug (which isn't evident to me yet from your above
report).

Sorry about the embed.  I don't recall why I attached two files but not the third.

As far as not understanding what the problem is, I'm not sure how to better
restate it than I did in my initial report:  When I edit XF86Config to reflect
the actual amount of memory on my display adapter and then reboot, things get
wacky as described.  I never said that there was an answer to be found in the
logs.  You asked to see my logs and I complied.

You said "If there is a problem, it is an XFree86 problem, not a Red Hat
problem."  and "I also do not have any SiS video hardware available to test this
or do any troubleshooting with actual hardware if there is indeed a problem."  I
wish you had stated that at the outset so that I wouldn't have waited a month
only to discover I wasted your time and mine.

I will certainly look into the rawhide packages.

Not having the hardware does not mean that I can't do anything.  It does
mean that I can't plug in the identical adaptor, and reproduce the problem
at will.  Not having the hardware limits what one can do about hardware
specific problems.  It doesn't mean that nothing at all can be done however,
but it does mean that the bug reporter needs to provide as accurate and
detailed information as possible, and clearly and concicely.

The Video memory option is a generic XFree86 option, and I have now tested
and confirmed that the option does work on other hardware (A Rage 128 board).

The reason I am unable to do anything currently, is that you are telling
me that you can't use 8Mb of video memory, and then attaching 2 log files,
one of which shows that you are using 8Mb of video memory.  Sorry, but I
don't see the problem.  It could just be the way that you are wording things,
but if I can't understand what you're saying, there is not a lot I can
do really.

Please do try the rawhide packages, as XFree86 4.2.x is unlikely to get any
SiS fixes from upstream developers nowadays unless they are mission critical.
XFree86 CVS however does get fixes, and will get updated several times per
week until 4.3.0 comes out.  Now is the time to test it and report bugs both
to upstream developers via xpert mailing list, and to us via
bugzilla.  Hopefully then the 4.3.0 release will be rock solid.

Let me know if rawhide packages work better for you.

Thanks

I'm assuming this works in Red Hat Linux 9 properly.  Another option, is
that this option is no longer supported in the SiS driver.  In any case,
forcing the videoram is a deprecated thing which should be discouraged.

If this problem continues, and you believe it is really a bug, please file
a bug report at http://bugs.xfree86.org and the upstream SiS driver author
will investigate the problem and advise.

Closing as CURRENTRELEASE, however if after upgrading you determine it does
not work still, please file upstream as mentioned above, and include the
upstream bug report URL here, so I can track it there instead of here.  In
that case, if there is a real bug, and it gets fixed upstream, I can investigate
backporting the fix.

Thanks