|Summary:||memory option for SiS 6326 in XF86Config is broke|
|Product:||[Retired] Red Hat Linux||Reporter:||Marc Williams <marcjw53>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Red Hat Linux 9||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-05-20 22:15:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Marc Williams 2002-11-20 14:25:58 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i586; U;) Gecko/20020830 Description of problem: When I add the line: VideoRam 8192 to my XF86Config file, either manually or with the redhat-config-xfree86 utility, my display acts strangely and is unusable. The mouse cursor changes to a large square, sections of the screen will disappear and reappear depending on where I move my mouse and what I click, etc. I didn't have this problem with either 7.3 or 7.1. My display adapter does have 8MB RAM but RH only sees the default value of 4 which is why I'd like to change it in the XF86Config file. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Add the "VideoRam 8192" to the XF86Config file 2.Restart the X server or reboot 3. Actual Results: The screen goes wacky as described Expected Results: Nothing. XFree86 should simply see the adapter as having 8 MB RAM. Additional info:
Comment 1 Mike A. Harris 2002-11-20 14:30:35 UTC
Please attach your config file and X server log.
Comment 2 Marc Williams 2002-11-20 15:11:33 UTC
Created attachment 85684 [details] the good (normal) log
Comment 3 Marc Williams 2002-11-20 15:12:56 UTC
Created attachment 85685 [details] the bad (abnormal) log
Comment 4 Marc Williams 2002-11-20 15:15:32 UTC
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
Comment 5 Marc Williams 2002-12-05 22:03:43 UTC
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?
Comment 6 Mike A. Harris 2002-12-18 20:06:34 UTC
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).
Comment 7 Marc Williams 2002-12-18 20:27:53 UTC
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.
Comment 8 Mike A. Harris 2002-12-18 20:49:13 UTC
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 firstname.lastname@example.org 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
Comment 9 Mike A. Harris 2003-05-20 22:15:54 UTC
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