I have a system upgraded from 7.2 to 7.3. Hardware is an AMD K6 with a 2MB S3 Trio 64V2DX/GX graphics adapter (according to /proc/pci). When I try to start Xconfigurator, it segfaults after I press "Next" at the first informational screen. I'm attaching a list of the installed XFree packages.
Created attachment 56546 [details] Installed XFree86 packages
I have an HP Vectra VL5 Series 5 with builtin graphics on which Xconfigurator segfaults when run without any switches. Other than that the system works great. It worked well in RedHat 7.2. I tried installing another PCI Video card, it didn't segfault but it didn't work out and upon rebooting Kudzu detected the onboard video as an S3 Trio64 DX or GX, however it is not displaying anything even remotely normal. /sbin/lscpi gives me this: 00:00.0 Host bridge: Intel Corp. 430HX - 82439HX TXC [Triton II] (rev 03) 00:06.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 00:0d.0 VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] (rev 14) 00:0f.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01) 00:0f.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] 00:0f.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) I just tried running 'Xconfigurator --card "S3 Trio64V2/DX (generic)"' and it still segaulted, however I tried Xconfigurator --card "S3 Trio64V2/GX (generic)" and it actually went through offered me resolutions to choose from in addition to the defaults etc.
I apologize for the ambiguity and second email but running 'Xconfigurator -- card "S3 Trio64V2/GX (generic)"' works around the problem in my case and gets X Windows up and running.
Apparently this is not a good/reliable fix. After a reboot all I get when trying to run startx is: XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. I have no idea what is causing this error, attempting to reconfigure does nothing. I managed to dig up an old S3 Virge to use instead, but I will remove it to get more information or test a fix if required.
Please attach XFree86 log and config file using the link below. Also include the output of: lspci -n Thanks.
In my case, the graphics adapter was replaced with another (S3 Trio64 DX I believe) that didn't cause Xconfigurator to crash.
Well, someone please attach the requested information, otherwise I can't troubleshoot or change anything to prevent the problem in the future.
Created attachment 57129 [details] XF86Config
Created attachment 57130 [details] XFree86.0.log from /var/log
Created attachment 57131 [details] The output of lspci -n
I edited XF86Config to comment out the lines complained about in XFree86.0.log, namely the LeftAlt, RightAlt, ScrollLock, and RightCtl lines. Again startx fails and the error is "Data incomplete in file /etc/X11/XF86Config\n\tDevice section \"Generic VGA\" must have a Driver line.
$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 430HX - 82439HX TXC [Triton II] (rev 03) 00:06.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 00:0a.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06) 00:0d.0 VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] (rev 14) 00:0f.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01) 00:0f.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] 00:0f.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) $ /sbin/lspci -n 00:00.0 Class 0600: 8086:1250 (rev 03) 00:06.0 Class 0200: 10b7:9050 00:0a.0 Class 0300: 5333:5631 (rev 06) 00:0d.0 Class 0300: 5333:8901 (rev 14) 00:0f.0 Class 0601: 8086:7000 (rev 01) 00:0f.1 Class 0101: 8086:7010 00:0f.2 Class 0c03: 8086:7020 (rev 01)
Created attachment 57205 [details] XFree86.0.log log file
Created attachment 57206 [details] XFree86.8.log log file
Created attachment 57207 [details] XFree86.9.log log file
Please note that the files I attached are with the additional S3 Virge Graphics card in the system. When I am near the system (it is not physically here) I will remove the card and provide a "clean" log and a configuration file created by Xconfigurator for the S3 Trio64V2 DX/GX specifically. It should be provided by Wednesday at the latest. My hope is that what I have attached will prove at least somewhat useful until then. -j
mharris: I am building up at box that will have 7.2 on one hard drive and 7.3 on another. X/GNOME worked just fine under 7.2, but is a no-go under 7.3. This will be a fresh formated install for both versions. (Normally the machine would have the HDs RAIDed, but it makes it easy here. :) If you want access to the box let me know. I will take it into work where remote X would work at a decent speed. I also have two different S3 Trio64V2/DX cards. One that calls itself 1.83 ver 1.0 with a 86C775 - P5C3DD - 9708 marked GPU. The other calls itseld a 183 v2.1 with a 86C775 - P5E3FE - 9721 marked GPU. (Both fail under RH 7.3.) I am keeping a rather detailed list of the install and related files (X.log, XF86Config.test.log, lspic and lspic -n). Is there anything that you want from me before I do anything more? I will be attaching my 7.2 install notes. If you want anyother files/logs let me know.
Created attachment 65284 [details] 7.2 install notes
Created attachment 65325 [details] 7.3 Install notes (to compare with the 7.2 install notes)
Show this bug be linked to 65651 (or the other way around)?
Hi, I have the exact same problem. can anybody tell me what the status is of this problem? Regards Mark Flentge
I worked around, after quite some and trial error the same problem: Xonfigurator does not segfault if you do as follows: # Xconfigurator --card "S3 Trio64V2 (generic)" --preferxf3 Then follow the dialogs. Now the XFconfig files are OK, but the wrong X server is started: you need the change the wau /usr/X11R6/bin/X is linked. It is still wrongly linked to /usr/X11R6/bin/XFree86 change this linking of X to /usr/X11R6/bin/XF86_S3 Now X starts up OK At least thats how I did it.
This bug is acknowledged, and occurs on various S3 hardware which previously defaulted to 3.3.6 X servers. The problem actually is due to Xwrapper no longer being present in the distribution. Xwrapper was in the distro for quite some time as XFree86 3.3.6 required it, however 4.x has it built right into the server and doesn't need it. There were problems with Xwrapper during development, and it was discovered that it wasn't really needed anymore, so it got dropped. The consequence is that Xconfigurator still looked for it, and problems result if it isn't present and someone tries to use a 3.3.6 server. These problems were not forseen, and in several months of development, no beta testers reported the problems, so they went basically unknown. I've received various bug reports about issues like this, and it took a while to determine exactly what was occuring. It's unfortunate that people didn't test and report this stuff in time that it could be fixed for the 7.3 release. ;o/ Since the 7.3 release, Xconfigurator has been deprecated, and is no longer present in our 8.0 release. It has been replaced with the new redhat-config-xfree86 tool in Red Hat Linux 8.0 now, and maintenance of Xconfigurator is very very minimal. There are workarounds for several of the most commonly reported issues that come up in 7.3, and since these problems only occur on a few pieces of hardware, there hasn't been a strong reason to fix Xconfigurator. My official recommendations for people using hardware that is affected by this problem, roughly in order, are to do one of the following: 1) Upgrade/install Red Hat Linux 8.0, as the new config tool will configure the card to use the best 4.x driver for the card, and gives the best support going forward also. or 2) Use the 4.x server in 7.3, by forcing --preferxf4 in Xconfigurator. Try the s3 driver, the s3virge driver, then the "vesa" driver, and even the fbdev driver. One of those 4 should work, and should work on par or better to the 3.3.6 driver. We've removed 3.3.6 from Red Hat Linux 8.0 since 4.x can now work acceptably on pretty much all hardware, either using a native driver, or using vesa or fbdev. This simplifies configuration of the system also, and allowed us to create the new config tool much more easily. If I were to release any updates for this problem, the best way to do it would be to patch the hardware database to use 4.x drivers everywhere by default like it is in 8.0. If enough people want me to do this, I will do so and release hwdata erratum for RHL 7.3, so that default usage of Xconfigurator results in working video comparable to 8.0. I'm closing this as WONTFIX for now however, as I do not plan any future Xconfigurator releases unless Xconfigurator has security bugs which warrant security erratum.
*** Bug 64789 has been marked as a duplicate of this bug. ***