Folks, I am posting this to the XFree86 mailing list and the RedHat general list. The issue appears to be pertinent to both XFree86 and RedHat 9, and I have not seen any specific mention of it in the current archives when I searched on Google. I apologize for the length of the note but want to get as many possibly pertinent details into it as I can. We recently had a meltdown on a box that had RedHat 7.3 installed; we decided to install the latest version of RH since support for 7.3 seems likely to go away in the near future. The box contains the following hardware: ASUS P2B-D Dual PII motherboard Dual PII 450 Deschutes CPUs w/512K cache 448 MB non-ECC PC100 RAM 3Com 3C905B-TX Ethernet ESS-1968 Maestro 2 sound Matrox G400 Dual-Head w/16 MB RAM Generic 40X CD-ROM 6.4 GB Quantum IDE HD 13 GB IBM IDE HD ViewSonic P810 21" Monitor IBM P200 20" Monitor The 6.4 GB drive has an old installation of NT 4.0 on it which we have enabled for dual-boot. The 13 GB is the primary channel master, the 6.4 is the primary channel slave, and the CD is the secondary channel master drive. On to the problem: when we installed RH 9, we were unable to set up dual head Xinerama display as we had previously. Not surprising, as we had to download the Matrox binary-only drivers to make that work on RH 7.3. We downloaded the latest drivers from Matrox which are currently labeled 3.0 compared to the old ones at 2.0, and installed them. After some initial weirdness with the MGA PowerDesk utility showing the second head greyed out so that it appeared it was impossible to configure it, we were able to get the second monitor up. For some odd reason, if you double-click in the (empty) area to the right of the monitor icons in Power Desk where the "mode selection" radio buttons go, it suddenly decides to activate the second monitor. Go figure. So, we configure the monitors into dual-head mode, left and right merged display. Restarting X brings up the dual-head display as we expected, and we were able to log in. We configured up2date and got all currently available updates onto the box. Then we started actually trying to use the system, and the problems began to appear. Here are the primary problems: 1) Anything GL-related can (and probably will) kill X. This problem first manifested when the primary user would walk away from the machine long enough for the screensaver to come on. He would often come back and find that he'd been logged out. He initially thought this was some wacky new auto-logout feature built into the screensaver and wasted some time trying to find something in the configuration windows to disable it. We found that we could force the crash by selecting preview on any of the GL screensavers such as GLForestFire. 2) Any version of Mozilla other than the 1.2.1 that ships with Redhat is extremely unstable. Browsing to the Ximian site locked up both 1.3 and 1.4 stable versions of Mozilla. We downloaded Firebird 0.6.1 as well, with the same results. Most of the time they won't even start; you get an empty grey window frame when you try to start any of them. Redhat's 1.2.1 continues to run like a champ. We de-installed the Matrox drivers and went back to single-head mode, and all of the problems immediately vanished. OK, so we went looking for information on this problem. We were unable to find anyone else who was having the specific problems we were having, either in the mailing list archives for redhat, XFree86, or the Linux lists at Matrox. We found some stuff through groups.google.com which suggested we might be able to run the G400 in dual-head mode without using the (clearly buggy) Matrox drivers, but that turned out to be totally fruitless. We set up a xinerama-enabled XF86Config file and attempted to run with the 4.3.0 stuff that we had installed. No joy. XFree86.0.log clearly showed that it wanted the mga_hal_drv.o file to be available. We finally concluded that the folks who claimed to be running without the Matrox drivers must be running distros that shipped with mga_hal_drv.o installed and they just weren't aware of it. One of them was running Mandrake, but I don't recall which version it was. You can find those posts on Google by searching for "Mantrox G400 Dual" (and no, that's not a typo). Documentation for XFree86 states that the default behavior for the MGA driver is to load the MGA HAL driver if it is available, so we tried installing *just* the mga_hal_drv.o file from Matrox but leaving the stock 4.3.0 mga_drv.o file in place. No joy. The second head would not turn on. Primary head worked fine, and none of the crashing problems were there. The 4.3.0 Matrox mga_drv.o file is almost 20 times larger than the one for 4.2.1, which suggested that there might be a bunch of debugging code in there which was the source of the problems. Some archived posts to the Matrox Linux list stated that it was possible to run the 4.2.1 Matrox drivers under 4.3.0, so we decided to try this. We renamed the Matrox distribution 4.2.1 directory to 4.3.0 and ran the install.sh script, and voila, a working dual-head system. Except that the GL problems were still there. And none of the standard versions of Mozilla would even start. But the 1.2.1 Mozilla that shipped with RH 9 *does* still work. We have decided at this point to backtrack to RH 8.0 and hope that the problems won't follow us. RH 8.0 ships with XFree86 4.2.1 which is the same version we were running on 7.3 and we know that it works. So, the questions are: 1) Is the problem due to XFree86 4.3.0, or something else in RH 9? Is it package specific or a result of some combination of things such as XF86, glibc, and gcc 3.2.2? 2) Why does nobody else seem to be having this problem? 3) Why should the problem break Mozilla/Gecko specifically? Why does the RH Mozilla 1.2.1 work fine? As I've stated, we have given up on RH 9. However, we recognize that eventually we will probably have to upgrade to a newer version and so it is in our best interest to see these problems fixed. So, we are getting the bug reports in and hoping that they will be useful to the nice folks at to RedHat and XFree86. Please feel free to email me or post to the list with any follow-up questions, and I will provide you with as much additional information as I can regards, Jim Wiggs _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
