Description of problem: Numerous bugs are being reported for FC4 and development of FC4 prior to that which seem to indicate that the libvgahw.a X server module binary differs between an FC3 build of the same version of Xorg as the FC4 build. In other words, when this module is compiled in FC3 it works properly in FC4, but when it is compiled in FC4 it results in a variety of failures being reported with a wide range of hardware. To date, the majority of hardware the problems are being reported on include all Matrox video hardware, but in particular the G550 has a lot of reports. Additionally, Intel i852/i855/i865 and perhaps other Intel hardware seems to be hit by this problem. There are a number of other issues reported for FC4 on other hardware such as Cirrus Logic, and various other cards which are seemingly strange and might be related to this problem also, although that has not yet been investigated. The issue seems to be x86 specific thus far as nobody has reported the issue on other architectures yet. At this point it seems that there are 2 plausible scenarios to explore the root cause: 1) a compiler bug of some sort that results in invalid code being generated 2) a bug in the X sources which makes invalid assumptions in the C code which result in undefined behaviour of which might have worked magically with various compilers previously, but may no longer work the same manner in gcc4 Experimentation has shown that using "-O0" (oh zero) instead of "-O2" for optimization on x86 seems to avoid the problem, so it seems as if it is related to compiler optimization although at this point either scenario is equally plausible and no conclusions can be drawn until a full diagnosis has been completed and the problem analyzed to the code generation level. In the mean time, this bug will act as the master bug report to track the libvgahw.a problem, and the related bugs traced to this issue can be marked as depending on this bug for tracking purposes.
I have the G550 and I took the libvgahw.a file from the latest FC3 (6.8.2-1.FC3.13), but that did NOT resolve my problems. I installed all of the xorg-*-6.8.2-1.FC3.13 packages from FC3 onto FC4 to resolve the X problems on the G550. Also I tried to compile 6.8.2-1.FC3.13-src on FC4 with gcc 4, but this failed during the build. I don't have the details for that, but I can remember seeing something about missing math function like sin cos, ie. missing math libs.
(In reply to comment #1) > I have the G550 and I took the libvgahw.a file from the latest FC3 > (6.8.2-1.FC3.13), but that did NOT resolve my problems. This indicates that the problem you are having is a different issue than those reported so far which vanish when libvgahw.a is replaced with the FC3 one. There are other problems reported for the G550 in bugzilla also which are unrelated to this issue, but which your issue might be a duplicate of. You might want to scan bugzilla and add yourself to the CC of G550 issues that might be related. Hope this helps.
For those experiencing issues of this nature, I have uploaded the libvgahw.a X server module from the current FC3 errata release to my ftp space: ftp://people.redhat.com/mharris/libvgahw.a This should make it easier for some people to test out the module hopefully, and also have a temporary workaround. Feel free to add additional comments here about your successes with the FC3 module for /any/ bugzilla bugs in our bugzilla. There are probably more duplicate issues I haven't found yet, so this would be very helpful if people posted "potential duplicate" ID's here. Thanks everyone.
Status update: This issue has been linked to various problems reported on the following brands of video hardware: - Matrox G550,G400,other - Intel i845,i852,i855,i865 - Trident Cyberblade It is highly likely that similar problems occur on other hardware as well.
bug 159106 is probably a duplicate of this bug, but with a video card not yet mentioned: 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
As mentioned by Michael Peters in the above duplicate, replacing libvgahw.a from Mike Harris fixes the issue for me, too: S3 Inc. 86C270-294 Savage/IX-MV (rev 13).
That adds S3 Savage to the ever growing list of affected hardware. Thanks guys, when we have a fix ready, it should be easy to get it tested. Looking forward to closing a large number of reports on this one. ;)
However it doesn't seem to fix it for me and my G550, starting xorg still hangs the computer. If I downgrade the whole xorg-x11 to 6.8.2-1.FC3.13 it works.
S3 ProSavage Twister 4 here. Virtual consoles are corrupted when I switch to them. Switching back and forth between VC and X makes the VC get worse, til it's unreadable.
I can report that I have X11 problems on my amd64 platform with a Matrox G450 card.
*** Bug 159106 has been marked as a duplicate of this bug. ***
*** Bug 160500 has been marked as a duplicate of this bug. ***
*** Bug 161047 has been marked as a duplicate of this bug. ***
*** Bug 160470 has been marked as a duplicate of this bug. ***
*** Bug 160453 has been marked as a duplicate of this bug. ***
I tried the module posted in comment #3 with some success. Before: I was running a rawhide box, I ran into bug #157556, lspci shows: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) xorg-x11-6.8.2-30 Virtual terminals had a green border with a yellow and pink colorscheme; the fonts are horribly corrupted (and are unusable). Logging in as a user clears up the bad fonts (bad colour scheme remains). Switching to X and back to the virtual terminal yields the corrupt fonts again. Typing "reset" at a virtual terminal doesn't help, but running "bash" fixes the fonts (until the next time you switch to X and back) I upgraded to FC4 and was still seeing the same problems; this is with xorg-x11-6.8.2-31 I just tried the module posted in comment #3. With that module, the font problem appears to be fixed; the virtual terminals have the correct fonts, and I can freely switch between X and the virtual terminals without problems. I still get the rather tasteless greem pink and yellow colourscheme, but I can live with that for now.
https://bugs.freedesktop.org/show_bug.cgi?id=2976 is seemingly related, and linked to our bug #151688 as well.
*** Bug 160307 has been marked as a duplicate of this bug. ***
Can this file be inserted into the installation somehow so a graphical installation can be run? Without graphical installation I cannot use LVM.
(In reply to comment #19) > Can this file be inserted into the installation somehow so a graphical > installation can be run? Without graphical installation I cannot use LVM. There might be options in our installer to use the framebuffer device instead of native video driver during install. I'm not really sure, but you could find out on one of our mailing lists likely. Alternatively, if you rebuild xorg-x11 with the FC3 libvgahw.a included in the package, and rebuild and remaster the DVD, you can do a GUI install test. Hope this helps.
Since this issue is very very frequently reported on a variety of hardware, I've created the following "stock response" which can be cut and pasted into other bug reports which appear to possibly be the same issue or related, in order to simplify the process of finding duplicates: The f ============================================================================= This problem is believed to possibly be a duplicate of bug #161242. Please read bug #161242 and test the libvgahw.a module that is available at the following URL: ftp://people.redhat.com/mharris/libvgahw.a Make a backup copy of the original libvgahw.a module prior to replacing it with the one from above. Once you've replaced it, restart the X server or reboot the system. After doing this, please indicate if there is any change in the problem. You may wish to CC yourself on bug #161242 as well, assuming this does turn out to be a duplicate. Also, please attach your X server log from /var/log and your X server config file /etc/X11/xorg.conf to all X related bug reports, as this makes it easier for developers to perform a diagnosis. Thanks in advance. ============================================================================= If anyone suspects a given bug to be a possible duplicate of this issue, please cut and paste the above blurb into the given bug report and set the status to NEEDINFO.
*** Bug 160777 has been marked as a duplicate of this bug. ***
*** Bug 151688 has been marked as a duplicate of this bug. ***
Extra info re comment #16: after a complete reboot the crazy colours went away as well; looks like it was just residual state from the initial run of the old module from the rpm. So the FC3 version of the module is a full fix for me.
Intel 815 - Blue border and wrapped text in the terminal, before replacing libvgahw. After replacing and rebooting the system, terminals became normal again. X itself seemed to wor normally. It was just the terminals that showed a problem. Intel 865G - X seems to wor normally. The terminals are completely blank. Replacing the file and rebooting returned the terminals to view.
Replacing libvgahw.a with ftp://people.redhat.com/mharris/libvgahw.a in fc4 solves the blank white screen problem for my Trident Cyber9525DVD PCI/AGP card.
My Xserver still won't start with the new (old) file. I get the following in Xorg.0.log: (II) Loading /usr/X11R6/lib/modules/libvgahw.a Skipping "/usr/X11R6/lib/modules/libvgahw.a:vgaHW.o": No symbols found Wmodule.o is an unrecognized module type
Go figure. Re-ftp'd the file and rebooted again - works fine now ...
*** Bug 154502 has been marked as a duplicate of this bug. ***
*** Bug 161566 has been marked as a duplicate of this bug. ***
*** Bug 160950 has been marked as a duplicate of this bug. ***
The FC3 libvgahw.a fixed the problem for my i810 motherboard. Only after a reboot, though (which was noted by comment #24 above as well). I had initially reported this under bug 160950. I'm sure the gcc maintainers will be quite interested in the outcome of a code generation level analysis of libvgahw.a!
I had X problems on one of my systems based on the VIA EPIA 5000 motherboard with the Trident Cyberblade (generic) onboard video as reported in bug 160580 after upgrading my FC3 system to FC4. I then applied the test version of /usr/X11R6/lib/modules/libvgahw.a linked in the solution above and found that my problems with X were resolved.
Confirm that replacing libvgahw.a with the FC3 version fixes the problem here too. Graphics card is reported as "S3 Inc. 86C380 [ProSavageDDR K4M266] rev 2".
Also to confirm that replacing libvgahw.a with that from ftp://people.redhat.com/mharris/libvgahw.a fixes white screen syndrome on a Toshiba Satellite with a Trident Microsystem CyberBlade XPAi1. 1) I am truly delighted that Martin H. made the fix available 2) It would be a ** very good ** idea to make the fix available on fedora update. About the 2nd or 3rd thing I tried was yum update. Finding the bug in the bugzillas took rather longer :( Without a working FC3 on a separate partition one would have been well and truly snookered, to use a UK expression. 3) Also posted to freedesktop.org 2976.
*** Bug 160580 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > Also to confirm that replacing libvgahw.a with that from > ftp://people.redhat.com/mharris/libvgahw.a fixes white screen syndrome on a > Toshiba Satellite with a Trident Microsystem CyberBlade XPAi1. Good to hear! > 1) I am truly delighted that Martin H. made the fix available Mike. ;o) > 2) It would be a ** very good ** idea to make the fix available on fedora > update. We are exploring the root problem right now, and once we've nailed it, we will provide a proper fix. In the unlikely event the issue is elusive, or turns out to be a gcc bug as expected and it appears we wont be able to provide a real fix soon enough, an alternative workaround will be provided by compiling the module with -O0 instead of -O2, which also appears to resolve the issue. All of our rpms are built from source code contained within the src.rpm, and must not contain any binary components, so plopping the binary FC3 module into the rpm is not an option for an official update, however the -O0 solution should provide the same results in the worst case scenario. Thanks for the feedback!
ftp://people.redhat.com/mharris/libvgahw.a didn't solve the problem here at some computers, two days ago - waiting for a really working fix :(
On my ThinkPad T21 (S3 Savage/IX-MV) and Fedora Core 4, the problem is manifested not just as corruption of the display registers but also as occasional system crash when switching to textmode. These are full systems hangs (not just X), and occur about once in a dozen switches but with no obvious pattern. Because the display and kernel are both dead, I can't see the relevant kernel messages (if any). This means the machine cannot be safely shut down when using the savage driver: poweroff eventually switches to text mode and thus ocasionally crashes. Maybe this affects the priority and/or severity of this bug. Copying libvgahw.a from xorg-x11-6.8.2-1.FC3.13 cures all issues.
(In reply to comment #39) > On my ThinkPad T21 (S3 Savage/IX-MV) and Fedora Core 4, the problem is > manifested not just as corruption of the display registers but also as > occasional system crash when switching to textmode. These are full systems hangs > (not just X), and occur about once in a dozen switches but with no obvious > pattern. I have not seen that on my T20 - but I have seen something similar, where the system crashes when booting and starting the X Server. Disabling rhgb decreases the occurrence, and I have not seen it since installing the libvgahw.a from FC3 - but I also haven't booted my laptop that many times since implementing the workaround.
Here's a slightly different bent on the same issue. Output video freqencies change - twice - after successive attempts to go to the VC: Mobo: Gigabyte GA-7VKMP mobo with integrated graphics: S3 Pro Savage. Monitor is CMV CT-722D. Monitor set at default LCD 1024x768. Desktop KDE 3.4 Upon ctrl-alt-Fn I get a pink (magenta) console with a red border. Screen text is otherwise readable. Screen res at this point is 720 x 400, Hfreq=31KHz, Vfreq= 70Hz. I then ctrl-alt-F7 back to X and all is well. Next time I ctrl-alt-Fn to the VC, the screen is now unreadable and has pink and white vertical bands - about 5mm each wide. Screen res is again 720 x 400 but scanning freqencies have changed: Hfreq=35KHz and Vfreq=78.9Hz. Note that my screen is an LCD and supports a max Vfreq of 75Hz, hence it becoming unreadable above this freq. BTW... I got the above res & freq readings off the monitor's OSD.
i have the same green borders when i shutdown FC4. I am using matrox mga 2064W. I am posting this for the first time here, pls pardon any irregularities. I have not tried resolving this thru' the libvgahw thingy. Starting up FC4 is okay, x server had no problems. I have changed monitor vertical /horizontal sync rates too, no positive results. Once i shutdown FC4, the borders show up, but it's a clean shutdown, i just don't get to see anything on the monitor. If i use run level 3, x starts ok, but once i logout of x, it gives the same green borders. I hv not tried replacing the libvgahw.a yet, but i believe this started happening after FC2.
I can confirm that copying in the FC3 version of libvgahw.a (xorg-x11-6.8.2-1.FC3.13) solves this problem, as evidenced by symptoms similar to those reported in Comment #25, as seen on this video card: [root@taltos modules]# lspci | grep -i vga 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
(In reply to comment #42) > i have the same green borders when i shutdown FC4. I am using matrox mga 2064W. > I am posting this for the first time here, pls pardon any irregularities. I have > not tried resolving this thru' the libvgahw thingy. > > this is a follow-up, i hv downloaded the libvgahw.a module and replaced it. Instead of green borders around my screen, now i get a totally blank screen. That means it's definitely this module and it probably affects mostly matrox cards.
Works well on the i855, which during most of the FC4 testing cycle didn't. 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
Fixes my green-border-in-VC issue too. 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01)
I can confirm that copying in the FC3 version of libvgahw.a (xorg-x11-6.8.2-1.FC3.13) solves this problem, as evidenced by symptoms similar to those reported in Comment #25, as seen on this video card: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
"Me Too" i855GM in a Fujitsu (Siemens) P7010. Worked fine with FC3. Same problem as described with FC4. Normal behaviour since copying Mike Harris's FC3 libvgahw.a over the top of the FC4 one. Recommend that bug #155416 be marked as a duplicate of this bug.
The libvgahw.a swap fixed my problem on a g450 (green border around blank vt). You may email me directly if you would like me to test any fixes.
*** Bug 157556 has been marked as a duplicate of this bug. ***
*** Bug 161756 has been marked as a duplicate of this bug. ***
*** Bug 153729 has been marked as a duplicate of this bug. ***
*** Bug 160477 has been marked as a duplicate of this bug. ***
*** Bug 155416 has been marked as a duplicate of this bug. ***
PC: Matrox G550, Athlon 1900+. Like other, I have scrap in X, but if I'm back to text mode (from X) I see scrap as well (sometimes black screen). No changes after swap libvgahw.a (from FC3). I playd with xorg packet from FC3 and I found out, that after swap /usr/X11R6/bin/Xorg X work again correct. But if I swap only Xorg, then still if I'm back to text mode, I have scrap. The libvgahw.a swap solve the last problem.
We have a volatile/optimization issue. The problem in xorg-x11-6.8.2-37 is in file xorg-x11-6.8.2/xc/programs/Xserver/hw/xfree86/vgahw/vgaHW.c at line 436: (void) minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET); After preprocessing, it reads: (void) *(volatile CARD8 *)(((CARD8*)(hwp->MMIOBase)) + ((hwp->MMIOOffset + (hwp->IOBase + 0x0A)))); Or equivallently: (void) *somewhere; Therefore, for some reason, the hardware memory needs to be read. But even though the result is "volatile", this line is discarded by gcc -O2. As I understand it, this is not a bug in gcc but a misuse of volatile. I did several successfull tests. First, I split vgaHW.c into 2 files so that I could recompile the 10 line function mmioReasAttr() without optimization. It worked. Another workaround is to ensure the gcc optimization won't discard the memory access. The following patch works: ------------- begin patch ------------------------- --- vgaHW.c 2004-08-03 11:33:54.000000000 +0200 +++ vgaHW.c 2005-07-01 20:51:51.000000000 +0200 @@ -441,12 +441,16 @@ static CARD8 mmioReadAttr(vgaHWPtr hwp, CARD8 index) { + CARD8 tmp1, tmp2; + if (hwp->paletteEnabled) index &= ~0x20; else index |= 0x20; - (void) minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET); + tmp1 = minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET); + __asm__ __volatile__ ("movb %1, %0" : "=r" (tmp2) : "r" (tmp1)); + moutb(VGA_ATTR_INDEX, index); return minb(VGA_ATTR_DATA_R); } --------------- end patch -------------------------- My video cards is a matrox G400.
#56 looks like a good analysis. It looks like you are on the right track. But I have some quibbles. The fix looks ugly (of course the problem is ugly too). asm ought to be avoided as much as possible. Even with this kind of fix, I bet it could be reduced -- do you really need two temp variables? I don't see why "(void) *(volatile CARD8 *) somewhere" may be legally optimized away. According to the "info gcc" node "Volatiles", it should not be. Here's an extract (done on FC4): <<Less obvious expressions are where something which looks like an access is used in a void context. An example would be, volatile int *src = SOMEVALUE; *src; With C, such expressions are rvalues, and as rvalues cause a read of the object, GCC interprets this as a read of the volatile being pointed to.>> I even tried to duplicate this optimization with a tiny program (on FC4 running on x86_64). It didn't seem to happen. Did I do something wrong? I ran it with cc -S -O2 gccvolopt.c && cat gccvolopt.s The file gccvolopt.c contained: typedef unsigned char CARD8; /* from /usr/include/X11/Xmd.h:150 */ void test(CARD8 *addr) { (void)*(volatile CARD8 *)(CARD8 *)(addr + 1); }
Oops. My experiments in #57 were in fact done on an FC3 i386 system. I can duplicate the optimization on my FC4 x86_64 system. I still think that gcc does not match its own documentation so that there is a gcc bug (perhaps in the documentation, but I don't think so).
I've written this up as a gcc bug: bug 162274
Thanks for your help Hugh. After all, it seems to be a gcc bug. Note that in the 2 testcases below, the first one is correctly optimized whereas the second one is not. So the problem in gcc is when casting to a volatile. void test_1 (volatile char *addr) { *addr; } void test_2 (char *addr) { *((volatile char *) addr); }
Bug affects S3 Unichrome too - fine green vertical lines superimposed over X display, scrambled multicoloured VC. Mike's libvgahw.a and a reboot fixed it for me, thanks Mike. VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01)
Someone mentioned that vgaHW.c was what was most likely the culpret for the blue border and wrapped test that I saw using an Intel 815 video in comment 56 above. This problem could be the trigger for problems that domino through to other symptoms.
A not so ugly pach (till gcc is fixed): --- vgaHW.c 2004-08-03 11:33:54.000000000 +0200 +++ vgaHW.c 2005-07-02 17:07:32.000000000 +0200 @@ -441,12 +441,16 @@ static CARD8 mmioReadAttr(vgaHWPtr hwp, CARD8 index) { + volatile CARD8 tmp; + if (hwp->paletteEnabled) index &= ~0x20; else index |= 0x20; - (void) minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET); + /* gcc-4.0 -O2 is broken : needs a volatile assignment */ + tmp = minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET); + moutb(VGA_ATTR_INDEX, index); return minb(VGA_ATTR_DATA_R); }
[untested speculation] Perhaps a good temporary fix would be to change /usr/X11R6/lib/Server/include/vgaHW.h to add the qualifier "volatile" to field "Base" in struct _vgaHWRec. The current type is "pointer", so adding "volatile" isn't simple ("void pointer" would make the pointer volatile, not the object pointed at). I'm not sure, but it looks as if "pointer" is defined in /usr/X11R6/lib/Server/include/Xdefs.h. It is defined there as "void *". So "Base" should be defined as "volatile void *" Such a change *might* force a cascade of changes because C's type rules with respect to qualifiers are a little clunky. This might even be a good permanent fix. I don't know whether everything in the VGA memory really is best described as volatile.
I disagree with solution at comment #64. There are many instances where the field Base is used (search "hwp->Base") and in each of these there is no reason to consider it as volatile. Btw, I am recompiling gcc cvs sources to fill a proper bug report there.
(In reply to comment #55) > PC: Matrox G550, Athlon 1900+. > Like other, I have scrap in X, but if I'm back to text mode (from X) I see scrap > as well (sometimes black screen). > No changes after swap libvgahw.a (from FC3). I playd with xorg packet from FC3 > and I found out, that after swap /usr/X11R6/bin/Xorg X work again correct. But > if I swap only Xorg, then still if I'm back to text mode, I have scrap. The > libvgahw.a swap solve the last problem. Hi, Dominik, i would appreciate it if u could post the /usr/X11R6/bin/Xorg file somewhere i can download and test. I encountered the same problems u described above but as i do not have FC3, have not been able to swap the file mentioned by u.
Re comment #66: please read comment #3 -- Mike provides an i386 binary. Mike: could you also provide an x86_64 binary?
gcc devs seem unable to agree on interpretation of the C standard and wether or not this is a gcc bug or not. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 While this specific bug is the only currently-known place in the X codebase that is giving a runtime problem, there may be other areas lurking in the code as well. At this point, I believe the only rapid solution, is to work around the gcc bug (or non-bug depending on one's viewpoint) by recompiling Xorg with -O0 on any platform which can reproduce the issues. I'll be proposing this interim solution with the rest of our X11 development team tomorrow. Once we've made a decision, I'll roll it into rawhide.
(In reply to comment #68) > I'll be proposing this interim solution with the rest of our X11 > development team tomorrow. Once we've made a decision, I'll roll > it into rawhide. And please, as an FC-4 update after its rolled into rawhide/updates-testing
(In reply to comment #69) > (In reply to comment #68) > > > I'll be proposing this interim solution with the rest of our X11 > > development team tomorrow. Once we've made a decision, I'll roll > > it into rawhide. > > And please, as an FC-4 update after its rolled into rawhide/updates-testing There are 2 other issues that need fixing first prior to another FC4 update. Once we've got all of these major issues resolved, we'll likely push a new FC4 update, and possibly even an FC3 update. There are known workarounds or fixes for each issue however, so it probably wont be very long in the coming either way, although I wont promise any specific date/time. Take care, TTYL
This has worked on my i386 PC's with ATI 3D Rage IIC 215II [Mach 64 GT IIC] video cards. It hasn't however fixed my iMac PPC. When I replace the file, the TTY's work, but X will not start.
(In reply to comment #71) > This has worked on my i386 PC's with ATI 3D Rage IIC 215II [Mach 64 GT IIC] > video cards. It hasn't however fixed my iMac PPC. When I replace the file, the > TTY's work, but X will not start. Eh, where did you get the PPC version of libvgahw.a? We /never/ released a FC-3 for PPC, so getting to the older Xorg file isn't going to be as easy as you'd hope. This might be useful: http://fedoraproject.org/fedorappc/FC-3/os/Fedora/RPMS/xorg-x11-6.8.1-12.ppc.rpm Remember, while libvgahw.a is an ar file, there are really compiled C objects in there, and those are arch-dependant
*** Bug 160287 has been marked as a duplicate of this bug. ***
I have a PXE+NFS server setup with fc4 structure up to date via /usr/lib/anaconda-runtime/* procedure. On a HP with a ATI Technologies Inc Rage XL (rev 27) controller all work fine and the grafical setup is ok. On a system VIA with a Trident Microsistem CyberBlade/i1 controller, when X start the screen come white, if I switch on a text console the usual green edge appears. I have take the rawhide new versione of xorg-x11-*6.8.2-41.i386.rpm and I have rebuild fc4 install structure. Now the green edge not appears, the text console work, but the graphical console still to appear white ad is unusable. Some suggest? Can help to substitue manually the libvgahw.a on /u/fc4dist/i386/Fedora/base/stage2.img root image? (sorry for my bad english)
Rawhide xorg-x11-6.8.2-41 does not contain any changes to fix or workaround this particular issue currently, so updating the installer image to that version would not change anything. Once we have an official fix available, you can remaster the CD/DVD ISO images using the same procedures used to create them at Red Hat. I'm not sure where it is documented, but anaconda-list archives probably have pointers to the exact procedures that you might find useful.
*** Bug 162567 has been marked as a duplicate of this bug. ***
Anyone have an X86_64 version of this file? Jay
Copying the FC3 version of the file solved the problem for me too - after SELinux worked out the permission required.
I have an Intel G440LX with a Cirrus Logic GD5480. I experienced the same problem as others using this display card as noted in bug 157593. Using the libvgahw.a compiled for fc3 made my display work. I believe this bug is a duplicate of bug 157593 (or the other way around).
ftp://people.redhat.com/mharris/libvgahw.a fixes my problems with a G400 AGP (rev 82). Thanks, Florian La Roche
(In reply to comment #79) > Anyone have an X86_64 version of this file? > > Jay Stolen from the FC3-x86_64 distro xorg-x11-sdk-6.8.1-12.x86_64.rpm: http://www.northwest-aero.com/download/libvgahw.a BTW, this fixed this bug on an Intel D915GEVL motherboard with the "Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04)" -j-
ftp://people.redhat.com/mharris/libvgahw.a fixes my console problems (after reboot) with a 00:01.0 VGA compatible controller: Intel Corporation 82810 CGC [Chipset Graphics Controller] (rev 03) i810 with 1Mb of memory Thanks,
*** Bug 157593 has been marked as a duplicate of this bug. ***
*** Bug 163104 has been marked as a duplicate of this bug. ***
3 Systems 2 work fine until exiting from x, then one gives no display as system shuts down, second has odd colored borders around text and sometimes no display, reverting to FC3 libvgahw.a does not fix either problem, They are protac All in one Mobo's, one with S3 ProSavage KM133 Video, the other Via/S3G UniChrome, both worked with FC3 3rd System, Test Server, old Intel Dual PII BX440 with Cirrus Logic GD5480 Video Gave horozontal line on boot to X & so had to install in text mode, Any replacement S3 video cards failed until one with extra memory gave basic graphics Reverted to FC3 libvgahw.a & initially did not seem to solve problem, simply changed it to a blank screen on boot, set server to run level 3 on boot & tried x -configure but this failed, reverted to backup xord.conf & nmanually startx OK, monitor was not set, set it up & now ok on boot & starting x manually. No display on shutdown/reboot. Inexplicable reason on the fix
A workaround has been added for this issue in xorg-x11-6.8.2-43 in rawhide. Everyone who experienced any problems related to libvgahw.a miscompilation, please upgrade to the latest rawhide build and confirm wether or not the new build equally works around the issue for you. Once I've received a reasonably sized handful of confirmations, I will consider releasing an updated build for Fedora Core 4 as well. Thanks in advance to everyone for testing everything and helping us to narrow this issue down. RPMs are also available for download here: ftp://people.redhat.com/mharris/testing/unstable Setting status to "NEEDINFO", awaiting testing confirmation.
xorg-x11-6.8.2-43 running in an up-to-date Fedora Core Development installation fixes my issues with MGA G400 (bug 151252).
My issue is not fixed. xorg-x11-6.8.2-43 shows whole white screen. What I has done on my FC4 box is: # yum --enablerepo=development upgrade 'xorg-x11*' This upgraded xorg-x11-* and glibc for dependency. # reboot after reboot, # startx
I just tried ftp://people.redhat.com/mharris/libvgahw.a, and it fixed my problem too. I own a ASRock K7VM2 with a VIA KM266 chipset onboard: 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] I hope to see a fix go into FC4 soon! Thanks!
Unfortunately, none of the aforementioned workarounds seem to work here. Matrox G550 AGP, Athlon XP 2800+, Asus MB Tried: - libvgahw.a from FC3 -> distorted X Display & text console distorted after logging out of X - additionally FC3 Xorg binary -> same as above - Upgrading to Rawhide Xorg Packages -> no change Just to be shure tried FC3 libvgahw.a / Xorg with the updated Rawhide Xorg packages but still X display is broken and even the text console is corrupted after shutting down X. Seems, at least with the G550, there is more to it than just a broken libvgahw.a .
*** TROUBLESHOOTING GUIDE FOR libvgahw.a ISSUE. PLEASE READ *** (In reply to comment #91) > My issue is not fixed. xorg-x11-6.8.2-43 shows whole white screen. > What I has done on my FC4 box is: > # yum --enablerepo=development upgrade 'xorg-x11*' > This upgraded xorg-x11-* and glibc for dependency. > # reboot > after reboot, > # startx In order to cut down on any confusion over this issue, and any other problems people might be experiencing and think that their problem is this issue (which it may or may not be), I am providing a troubleshooting guide below which will allow anyone to go step by step to determine wether they are experiencing the bug we are tracking in this bug report, or if they are experiencing an entirely different and unrelated issue. Whichever the case, I've provided detailed instructions for how everyone should proceed which I hope clarifies any confusions. This bug report is tracking one single bug - a known issue in libvgahw.a which causes numerous problems on a variety of hardware, as reported above in the first comment. Once we have had 3 or 4 people confirm that the updated rpm packages fix the issue for them, we can conclude it resolves the issue for everyone. Anyone still experiencing an issue at that point, is most likely experiencing an unrelated bug which might "appear" to be the issue reported here, but which is likely a separate issue entirely. Anyone reading this, who thinks they might be suffering from this bug due to similar sounding symptoms, can determine if the issue they are experiencing is indeed the same bug, or a completely separate and unrelated bug which just has similar looking symptoms by doing: 1) Download ftp://people.redhat.com/mharris/libvgahw.a which is the libvgahw.a module extracted out of the latest Fedora Core 3/i386 rpm update release of xorg-x11. If you are using x86_64, ppc, or any other architecture, you'll have to download the appropriate FC3 rpm yourself from our ftp servers and extract the module manually. 2) Replace the currently installed libvgahw.a module with the one from step 1, then completely reboot your system to force the hardware to completely reset to factory power on defaults. 3) Start X and see if the problem has gone away or changed in any way. If the problem is gone, then you know that you are experiencing the problem we are tracking in this bug report. At this point one of 3 scenarios are likely: Scenario a) The problem is completely gone now. You've now confirmed that you were experiencing this bug, and the workaround of using the FC3 libvgahw.a module does prevent the problem from occuring. In this case, I want you to upgrade to the rpm packages referenced in comment #89 above, check "rpm -qi xorg-x11" and ensure that you do in fact have the new rpms installed. Then do a complete system reboot to reset the hardware, and test out the new Xorg you just upgraded to. If the new rpms also work around the problem you were having, then please indicate in a comment in the bug report: "I tested libvgahw.a from above, following the instructions provided, and it (works|does not work) for me. I tested the rpms pointed to in comment #89 above, and it (works|does not work for me)." That is the only useful information to us for this bug now at this point - confirmation that the proposed fix does work for people who we have confirmed were actually experiencing the problem reported here. Scenario b) After updating libvgahw.a from above, rebooting, and restarting X, you still notices some problems, but you also notice that things have changed. This most likely indicates that you were experiencing this problem, as well as one or more completely separate problems. If you do notice some improvements, please add a comment stating: "After upgrading to the new libvgahw.a, I notice that part of the problem I was having is now gone, but there are still other problems." This means that the problem reported in this bug report is now fixed for you, but you are experiencing secondary unrelated problems as well. For the secondary problems, please see the section labelled "Still having problems" below. Scenario c) When you upgrade libvgahw.a, reboot and test it, you do not see any improvements or changes at all. If this is the case, then you are not experiencing the bug that is being reported and tracked in this bug report. Your issue may or may not have symptoms that appear to be similar to some of the symptoms that other people are reporting, however if this workaround does not change anything for you, that tells us that your problem is a totally unrelated issue. You can test the new rpms mentioned in comment #89 if you would like to, however if the libvgahw.a update does not change anything, it is very unlikely that the new rpms will either (unless your problem was fixed in a different patch included in the new rpms too). In either case, you should read the "Still having problems" section below. Still having problems: ~~~~~~~~~~~~~~~~~~~~~ For those who have tried all of the steps I've provided in this comment, and are still having problems of some kind, then you are experiencing one or more issues that are completely unrelated to this bug, but which might "sound" similar compared to other people's reports. If this is the case, then you need to report your secondary issues to X.Org developers in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component, including full details of the problem, and attaching your X server log file and config file using the "Create a file attachment" link in the X.Org bugzilla. If anyone is unsure where to find these files, you can search google, or ask for assistance on a public mailing list and someone can help. Once you have filed a new bug report to X.Org bugzilla, if you would also like Red Hat to track the separate bug(s), you can also file a short bug in Red Hat bugzilla, just to point it at the upstream bug report you've filed. Be sure to file one bug report per problem you're experiencing, so that they can be closed independantly when they're resolved. In closing: ~~~~~~~~~~ Since there have been a multitude of people reporting this problem, as well as problems that "appear" might be the same issue, I thought it would help to cut down on additional bug duplicates, as well as comments from people experiencing unrelated issues with similar looking symptoms by providing a brief troubleshooting guide. Hopefully this takes some of the guesswork out of things. Once we have gotten 3 more success reports, I believe we can safely close this bug as "fixed". Assuming that happens, we will release a Fedora Core 4 update containing the fix sometime before mid-August rougly. Thanks everyone for your patience and assistance in troubleshooting this matter.
Can they be built on FC4? Here is what I did to get the unstable testing rpm's: for rpm in `rpm -qa |grep "^xorg" |sed -e s?"37$"?"43\.i386\.rpm"?g`; do wget ftp://people.redhat.com/mharris/testing/unstable/xorg-x11/6.8.2-43/i386/$rpm done Here is what happens when I try to install them: [mpeters@laptop x11_test]$ rpm --test -Uh *.rpm error: Failed dependencies: libc.so.6(GLIBC_2.4) is needed by xorg-x11-6.8.2-43.i386 [mpeters@laptop x11_test]$ yum localinstall *.rpm *snip* Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package xorg-x11-deprecated-libs.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-libs.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-Mesa-libGLU.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-twm.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-font-utils.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-tools.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-xfs.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-xauth.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11-Mesa-libGL.i386 0:6.8.2-43 set to be updated ---> Package xorg-x11.i386 0:6.8.2-43 set to be updated --> Running transaction check *snip* --> Processing Dependency: libc.so.6(GLIBC_2.4) for package: xorg-x11 --> Finished Dependency Resolution Error: Missing Dependency: libc.so.6(GLIBC_2.4) is needed by package xorg-x11
On Intel SE440BX-2 motherboard w/celeron 400Mhz & S3Trio64 video libvgahw.a reversion did not fix blank screen bug but xorg-x11-6.8.2-43 upgrade via yum (as in #91 above) did the trick.
Both the libvgahw.a and the xorg-x11-43 FAIL to resolve the terminal or X11 problems on my Matrox G550 video card. Any other ideas?
If anyone has problems manually installing the rpms from my people.redhat.com directory, try pointing yum to rawhide and use that instead. It will ensure the dependencies are met properly. Looks like a new glibc dep has been picked up.
(In reply to comment #97) > Both the libvgahw.a and the xorg-x11-43 FAIL to resolve the terminal or X11 > problems on my Matrox G550 video card. > > Any other ideas? My troubleshooting guide in comment #94 should help. Sounds like you have "Scenario c". Hope this helps.
For me replacing all the xorg packages with FC3 versions did the trick. Just swapping libvgahw.a was not enough.
(In reply to comment #98) > If anyone has problems manually installing the rpms from my > people.redhat.com directory, try pointing yum to rawhide and > use that instead. It will ensure the dependencies are met > properly. > > Looks like a new glibc dep has been picked up. Yes - I rebuilt the src.rpm in mock - that removed the glibc issue. I really don't want to update something like glibc with a rawhide package ... Later tonight when I reboot I'll report.
upgrading xorg-x11 as in comment #91 fixed the problem for my Savage/IX-MV (thinkpad T20). Didn't try libvgahw.a. Thanks.
IBM Thinkpad T20 *partially* fixed. With the fc3 libvgahw.a workaround, I would get the full use of the screen - black background, white text, the same way it comes up if I don't run an x server - exactly what was expected. With the update src.rpm rebuild in mock for fedora core 4, I don't get the full screen. I get a colored background with a rectangle that is the console. The color of the background and the background color for the area that is the console changes as I switch from a virtual console to the X console and back. If I switch to a virtual console from another virtual console, the same color scheme exists - it doesn't change until I switch to X11 and then switch back again. The src.rpm I rebuilt was xorg-x11-6.8.2-43.src.rpm I will apply the libvgahw.a fix again and see if it returns to acting as expected. Thinkpad T20 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
Re-applying the libvgahw.a workaround brought it back to expected behaviour. It does _not_ appear that I actually have full screen in console though, it just looks that way (illusion) because the screen background is black and the console background is black. While the updates src.rpm does give me a usable console, it still is different than the fc3 libvgahw.a workaround, and different than expected behaviour. mharris - I *do* appreciate the work you are doing this.
On Athlon64 machine with Matrox G550 running FC4-i386 rpm -e linuxthreads-devel to avoid dependency in glibc-devel yum --enable=development update xorg\* Clean update xorg to 6.8.2-43 and glibc things to 2.3.90-2 Reboot The graphics at run level 5, Cont/Alt/F7 is still corrupt, unusable !!!! Cont/Alt/F1-6 does not show coloured border but the text is corrupt - repeated/distorted characters - unreadable
(In reply to comment #99) > (In reply to comment #97) > > Both the libvgahw.a and the xorg-x11-43 FAIL to resolve the terminal or X11 > > problems on my Matrox G550 video card. > > > > Any other ideas? > > My troubleshooting guide in comment #94 should help. Sounds like you > have "Scenario c". > > Hope this helps. Mike, Thanks, the only thing that has worked for me, was to force install the latest xorg-x11 from FC3. Has anyone tried to take the x11-org 6.8.2 src and tried to compile and use it on FC4 using gcc 4? Also I was thinking of taking the x11-org-43 src from FC4 and compiling it on FC4, but use older gcc. Any thoughts?
I tested libvgahw.a from above, following the instructions provided, and it works for me on an Intel 845. I tested the rpms pointed to in comment #89 above (using yum to install the binary RPMs from rawhide), and it does NOT work for me. With the new RPMS I get the same symptoms as the original problem -- virtual consoles 1-6 appear blank. X itself has always worked fine. Reinstalling the FC3 libvgahw.a and rebooting again makes everything work properly. So it appears that the workaround added to these new RPMs does not in fact solve the problem for me.
(In reply to comment #100) > For me replacing all the xorg packages with FC3 versions did the trick. Just > swapping libvgahw.a was not enough. You're experiencing scenario C from above also. Read comment #94 for suggestion. HTH
(In reply to comment #104) > Re-applying the libvgahw.a workaround brought it back to expected behaviour. > It does _not_ appear that I actually have full screen in console though, it just > looks that way (illusion) because the screen background is black and the console > background is black. > > While the updates src.rpm does give me a usable console, it still is different > than the fc3 libvgahw.a workaround, and different than expected behaviour. > > mharris - I *do* appreciate the work you are doing this. Hmm. If libvgahw.a from FC3 completely resolves all problems for you, but the new rpms only resolve part of the problem, this introduces a "Scenario D" that implies there is more than one problem with gcc4 compiled libvgahw.a ;o/ Since these issues have very hardware specific symptoms which vary greatly from person to person, if someone who can reproduce this new Scenario D (Using FC3 libvgahw.a works completely, but using the new updated rpms and doing a full reboot, works only partially or not at all) could debug this further on their own machine, that would help. I think the next step we'll have to try, is to recompile the libvgahw.a module with "-O0" which was the original workaround. If that doesn't work for everyone, then there might be other X server modules that are broken as well, in particular if a complete replacement of FC3's xorg-x11 rpms gets rid of the problem, or if an FC3 recompile of rawhide xorg-x11, which is then installed on FC4 solves all problems - we're definitely looking at multiple compiler related issues. Thanks for testing, and for your results.... The plot thickens... ;o)
Mike - what about a BuildRequires: compat-gcc-32 and then build that particular module with gcc32? Or, have xorg-x11 honor the CC environment variable? This, of course, would be temporary until a sufficient level of patch makes libvgahw fully GCC4 compatible.
I just added a massive comment in response to comment #106, and got a mid-air collision with comment #110. Upon clicking "submit my comment anyway", bugzilla kindly threw away my comment and displayed a white page - just like it does every time nowadays it seems, so my comment was lost. I don't feel like typing it in again right now, as I've got a busy day ahead of me. Hopefully bugzilla will get fixed soon. Sorry...
Just replacing libvgahw.a didn't solve the problem for me. Enabling the "fedora-devel" repository and updating xorg (along with glibc) didn't fix it as well :( The only thing that fixed it, was to use the FC3 xorg-* RPMs after trying the above two steps, and now it works very well :) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82)
HW is Thinkpad T21: 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13) I see two problems: Strange colors (border, background, foreground) and garbage in the character buffer. Strange colors occur with libvgahw.a from 6.8.2-37 (FC4) and 6.8.2-43 (FCdevel), but not with the FC3 version. After stopping X (Ctrl-Alt-Backspace), there's garbage content in the console, regardless of which libvgahw.a I use. I don't notice any difference between 6.8.2-37 and 6.8.2-43, so I'll assume that none of the problems I'm seeing are the same as what was worked around in -43, although it might still be gcc4-related.
(In reply to comment #109) Mike, the machine here seems to exhibit scenario D. Downloaded -43 X.org using yumex and the rawhide/development repository, which brought in the glibc dependencies. Upon reboot from cold, when x started there was a momentary cursor on a white field, followed by a white field only. Restoring the FC3 libvgahw.a brought the X server back to life. The video device is a Trident Microsystems Cyberblade XPAi1. Thanks again for your help. Questions/observations: 1. I've debugged a number of things, but never been foolish enough to try and debug an X server on a standalone machine. Is there a sane way of tackling this? 2. Presumably the -43 rpms from the development repository and from your private site are identically the same. 3. Is there any specific info that you need that would assist in debugging? Robin (Who's just stashed this text, just in case!) > (In reply to comment #104) > > Re-applying the libvgahw.a workaround brought it back to expected behaviour. > > It does _not_ appear that I actually have full screen in console though, it just > > looks that way (illusion) because the screen background is black and the console > > background is black. > > > > While the updates src.rpm does give me a usable console, it still is different > > than the fc3 libvgahw.a workaround, and different than expected behaviour. > > > > mharris - I *do* appreciate the work you are doing this. > > > Hmm. If libvgahw.a from FC3 completely resolves all problems for you, > but the new rpms only resolve part of the problem, this introduces a > "Scenario D" that implies there is more than one problem with gcc4 > compiled libvgahw.a ;o/ > > Since these issues have very hardware specific symptoms which vary > greatly from person to person, if someone who can reproduce this new > Scenario D (Using FC3 libvgahw.a works completely, but using the new > updated rpms and doing a full reboot, works only partially or not > at all) could debug this further on their own machine, that would > help. > > I think the next step we'll have to try, is to recompile the libvgahw.a > module with "-O0" which was the original workaround. If that doesn't > work for everyone, then there might be other X server modules that > are broken as well, in particular if a complete replacement of FC3's > xorg-x11 rpms gets rid of the problem, or if an FC3 recompile of rawhide > xorg-x11, which is then installed on FC4 solves all problems - we're > definitely looking at multiple compiler related issues. > > Thanks for testing, and for your results.... The plot thickens... ;o) >
I believe that the solution wil be in applying the changes in the code referenced in bug 162274 that is stated as a bug which the volitile references need added to the c source code on modules as referenced in the bug report that I filed on freedesk.org - https://bugs.freedesktop.org/show_bug.cgi?id=3557 If gcc4 is "OK" then the code needs modified to act correctly with the tighter controls that are imposed by gcc4. The code is thrown away without changing the references to include volitile. If the references are thrown out, so are the binary bits from the compiled source. vgahw.c seems like it is the triggering source file since the blue border with visible but wrapped text seems to be dependent upon this file with the symptoms seen. This then effects libvgahw.a and replacing it with a version that the bits were not tossed out worked. The missing bits in the thrown out code are effecting a lot of people with different symptoms. I have a rawhide installation as well as FC4 and FC3 on the same computer. I'll report on what happened with rawhide since gcc needs upgraded.
Sorry for spelling in the above comment. Anyway, adding volatile to xf86Mode.c for appropriate values might get xorg-x11 to compile without reverting to lower optimization. Jim
Created attachment 116785 [details] It works for Intel 815 It appears that this will work for the Intel users. I still feel that adding volatile to the code would be a good idea by programmers who know what the parameter does.
Hi Jim, The patch in comment #63, is in the rawhide xorg-x11 which I posted a reference to in comment #89. The person who posted bug #162274 which you refer to above, is the same person who wrote the patch in comment #63, which does what you're suggesting (if I read you correctly). ;o) If you're suggesting something else, please clarify, preferably with a patch. ;) The only other suggestion anyone has made, was in bug #162274 comment 8 by Jakub. Unfortunately, that change would affect a *lot* more in the X server than just the one line of code people are having problems with, and may have a rippling effect through the code as indicated. The risk factor is IMHO too great to consider testing such a solution in our rpms. X.Org CVS head is a better place for any risky experimental fixes. Personally I consider this problem big enough right now, that: - Short term, we just need a simple "good enough" workaround that does not risk regressing anything else, and is self contained to the problem area. Compiling it with "-O0" seems to be that low risk workaround for the short term, until the long term "official" fix is made upstream ... - Long term we need the problem fixed the "right" way upstream, wether upstream is gcc.org, X.Org or both. Currently it appears gcc developers have not agreed wether it is a real gcc bug or not, and there does not appear to be many X.Org developers investigating the issue yet, which is pretty reasonable considering most people are working on modularization right now, and DDC/OLS conferences are in a few days, and a large number of X.Org folk will be there. Unfortunately, our entire X Development team leaves for Ottawa for Desktop Developers Conference and OLS next week, so it'll probably be at least a week before any of us can follow up on the problem again. Also, when I return after OLS, I'm taking a long needed 2 week vacation and will be avoiding technology as much as possible. I hope that nobody gets the feeling I'm abandoning this bug during the next 3 weeks. ;o) If the problem hasn't been resolved by the time I return, it'll be on the top of my personal list to get something out there soon as possible for everyone. In the mean time, I also strongly encourage everyone to discuss the problem on xorg.org, and in the upstream bug report(s), to get as many eyes on the problem as possible. Who knows, maybe when I return, a new bugfixed gcc will be available, and we can just send xorg through the buildsystem once to *really* fix it. ;o) Take care, TTYL
For those facing "scenario C" - corrupt display on matrox hardware, I've raised Bug 163331. It appears to be caused by the use-linux-native-pciscan-by-default patch introduced in 6.2.8-16.
There are 100+ casts into volatile in xorg-x11 and some of them are in libvgahw. All of these are "miscompiled" by gcc4 -O2. The patch in -43 (one volatile fixed in libvgahw) was enough for my G400. Unfortunatly, other hardware are depending upon volatile side effects found elsewhere in libvgahw or even elsewhere in xorg. Thus reported scenarii a,b,c,d are easily understood. For now, we have fixed: 1 bug out of 100+ in 1 package out of 1000+. I *really* suggest gcc4 be compatible with gcc3 in a near future.
All, I have successfully built xorg-x11-6.8.2-38 (from a little older FC4 testing) on FC4 using gcc32. The trick I used was to alias gcc to use gcc32. I will test and post my results for all over the weekend. Joe
Following comment #94: I tested libvgahw.a from above, following the instructions provided, and it works completely for me. I tested the rpms pointed to in comment #89 above, and it does not work for me at all; the symptoms are just the same as with the stock FC4 xorg-x11: all text consoles are totally blank after X starts. The machine is a HP D530, with an onboad i865 graphics card: 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) More details available if necessary.
Thanks Mike and Olivier for the information. Basically, the approach to stop the bug effect with the least pain possible for the most users is a good aproach. I know making xorg-x11 more modular is something needing a lot of effort and reduces resources. I'll look at the file that is supposed to be responsible for the blue border from a curiousity standpoint. It might make coding less boring having an object of interest. (messes up hardware I own in a minor way) As Chris stated a problem with the 865G video card, I have this video card type that showed the blank terminals once X started. Both the Intel 815 and the Intel 865G cards showing different symptoms and using the same driver is puzzling to my why one has blank terminals, while the other card shows a blue border and visible text in the virtual terminals. I'll pose this question on xorg.org if not already discussed.
To me, original problem is a bug in the way GCC4 handles volatile. There is a thread on the gcc at gcc.gnu.org mailing list. A possible fix to GCC4.x has been posted in that thread: http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html Mike: do you think you'd like to test this? See you at OLS!
Just a cross reference to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163331 Iain's fix appears valid for Athlon64 G550 FC4 i386 machine !!!! xorg-x11-6.8.2-43 from Mike and removal of use-linux-native-pciscan-by-default patch John
All The G550 matrox problems are not the same as the other cards. The problem appears to stem from the xorg-x11-6.8.2-use-linux-native-pciscan-by-default.patch. I am not sure if it's the patch itself or interaction with GCC 4 or something else on FC4. I rebuild xorg-x11-43 without the patch on FC4 with GCC 4 and my matrox G550 is now working again finally. see this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163331 mharris, do you have any thought on the issue? Joe
I upgraded a x86_64 system with Matrox g550 from FC3 to FC4. I had the usual problems with image corruption in X. I tried substituting libvgahw from FC3, and upgrading to xorg-x11-6.8.2-43 from unstable; neither worked. I then rpm -force'd xorg-x11-6.8.2-1.FC3.13, and it did work after warm reboot. I then upgraded to xorg-x11-6.8.2-43, which screwed up; I downgraded again to FC3, rebooted and it works fine now.
After I posted #124, Richard Henderson submitted a better patch for GCC4.x to the gcc mailing list: http://gcc.gnu.org/ml/gcc/2005-07/msg00733.html He said that he would be testing it. It is likely that the patch is for HEAD, not exactly the same version of GCC that is in FC4.
It worked for me on a Dell C400, thank you much.
A new gcc-4.0.1-4 is available, which should fix the root problem of this bug. Presumably, the new xorg rpm won't be available until Mike has returned, in 20 days or so. In the meantime, for those who want to experiment: 1. Update gcc to 4.0.1-4 2. Download xorg-x11-6.8.2-37.src.rpm (or -43 if you want) 3. Install the source rpm: # rpm -i xorg-x11-6.8.2-37.src.rpm 4. Rebuild the rpm from sources: [can take several hours...] # rpmbuild -bb /usr/src/redhat/SPECS/xorg-x11.spec 5. Install the new binary rpms: # rpm -Uvh /usr/src/redhat/RPMS/i386/xorg-x11-*
Recompiled binaries rpms can be found at: http://olivier.baudron.free.fr/RPMS/i386/ Testing is welcome!
I rebuilt the xorg-x11-43 with gcc-4.0.1-4 (which include the volitle changes). This does NOT fix the problem with a Matrox G550 card. The native-pci scan continues to be the root cause of the problems with the Matrox card. I rebuilt xorg-x11-43 with gcc-4.0.1-4 with the native-pci scan REMOVED and the card works fine.
Hi evryone, I am new to linux, i tried FC3 and i liked it, then i wiped my machine and tried FC4 but i ran into problems. I get the white screen, so i read your posts here and i tried i booted up with rescue cd and i renamed the libvgahw.a into libvgahw.a.old, but i cannot mount the floppy disk where i have the new libvgahw.a file (the one i downloaded from mharris). Any ideas as how i could access the floppy under the rescue mode or how else i can copy the file from the floppy onto my box. Thanks Ken Adams
Olivier, Mike, Les Gars, using Olivier's binaries (-43.ob1) on a Toshiba Satellite with a Trident Microsystem CyberBlade XPAi1 has so far been a complete success, with no white screen. They are running as I write this, of course! Mike, if the change to GCC has cured an obvious bug in X11, then one wonders what other bugs, both obvious and otherwise, GCC might have been responsible for... Oliver, merci bien. Robin (In reply to comment #131) > Recompiled binaries rpms can be found at: > http://olivier.baudron.free.fr/RPMS/i386/ > Testing is welcome!
You can press any key when your computer is booting to show the menu. Then you can press the "a" key to get where you can append options to the kernel. What you want to do is to backspace out the "rhgb quiet" from the line and then put a space followed by a 1 as an option to the kernel. Then you can run: mount /media/floppy to get your floppy accessable. Then you can run cp /media/floppy/libvgawh.a /usr/X11R6/lib/modules/libvgahw.a chmod 444 /usr/X11R6/lib/modules/libvgahw.a chown root:/usr/X11R6/lib/modules/libvgahw.aroot /usr/X11R6/lib/modules/libvgahw.a Once these steps are completed, you can type reboot and your system should come up with a working X. These instructions are taking into account that you saved the file without putting it in a special directory on the floppy. If the compilation works for xorg-x11 with the fixes to gcc4, this should no longer be needed past this initial installation.
dylexic on the cp should be: cp /media/floppy/libvgahw.a /usr/X11R6/lib/modules/libvgahw.a chmod 444 /usr/X11R6/lib/modules/libvgahw.a chown root:/usr/X11R6/lib/modules/libvgahw.aroot /usr/X11R6/lib/modules/libvgahw.a sorry!
Hi all. I have a Toshiba TE2000 laptop with Trident CyberBlade/Ai1. -- Using the xorg-x11-* from FC3 does not solve the white screen problem. -- Using mharris's libvgahw.a solves the problem halfway - I can boot into run-level 3, and do 'startx' to get X. However, if I try to boot into run-level 5, I get the guage that shows during the boot process (suggesting that my xorg.conf is OK?), but when it comes to the login screen, X keeps trying to start, with no success. Also, if I try 'init 5' from run-level 3, X keeps trying to start, again without success. -- Doing a 'system-config-display --reconfig doesn't change the above behaviour. Do I have a problem with kdm/kde - unrelated to this bug? Any information on where I should be posting this? I have not changed kdmrc from what it came as in the FC4 distribution. Thanks for any pointers. Muyiwa
This fixed my blank consoles on my 865GLX. One question though... I found two instances of the file. The first in /usr/X11R6/lib/Server/modules and the other in /usr/X11R6/lib/modules. When I found this situation, I suspected one was a symlink to the other, but I was wrong, it was two copies of the same file. Was I correct in replacing both of them? Kevin
I have encountered this problem with a matrox G450. I initially tried the ftp://people.redhat.com/mharris/libvgahw.a by itself, but that didnt fix it. I had to boot to init 3. Then I had to install the latest matrox driver 4.1 from http://www.matrox.com/mga/support/drivers/files/lnx_41.cfm tar zxvf mgadriver-4.1.tar.gz cd mgadriver-4.1 sh ./install.sh There was no 6.8.2 so,I selected 6.8.1 version. Then I copied ftp://people.redhat.com/mharris/libvgahw.a over the original (made a backup of the original first). Then startx, and all looks good, even works with dual head :) Matt
(In reply to comment #142) > Then startx, and all looks good, even works with dual head :) > Matt It didnt survive a reboot, I get black and white verticle bars on my screen. It does work if I boot, edit the kernel line for grub to init 3, then login, and startx& A bit more work is needed I guess, but at least there is hope.
Your problem is known and fixed at bug #163331
(Re comment #131) Olivier: I used the test RPMs and they work all right on my system. There is only a small corruption glitch, but I had that with the FC3 RPMs I was using as well: In Evolution (and working with some graphics), when I move a message to an IMAP folder, the cursor becomes corrupted; after releasing the message the cursor is OK again. Well, just to add a "me too" comment. 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82)
(In reply to comment #61) > Bug affects S3 Unichrome too - fine green vertical lines superimposed over X > display, scrambled multicoloured VC. Mike's libvgahw.a and a reboot fixed it for > me, thanks Mike. > > VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] > Integrated Video (rev 01) I omitted to mention that I have been using Xavier Bachelot's Unichrome-enabled xorg-x11 rpms, and that the symptoms appear when using the via driver, but not vesa. I have now built & installed rpms from Xavier's srpm using gcc-4.0.1-4 and the problems disappear. Previously I tried Olivier's patch from Comment #56. This modified but did not fix the problems: green lines on X remained, VC no longer scrambled but sometimes multicoloured. So it seems that there was more than one place in vgahw where gcc-4.0.0 was causing problems.
(In reply to comment #140) The problem was due to a missing link to xfs in /etc/rc.d/rc5.d, present in /etc/rc.d/rc3.d, which explains why "init 5" and run-level 5 don't work but "startx" from run-level 3 does. I don't remember removing it, but I must have... Anyway, with the link back in place, problem now solved. I should therefore add that "libvgahw.a also works for me" to the list. Muyiwa > Hi all. > > I have a Toshiba TE2000 laptop with Trident CyberBlade/Ai1. > > -- Using the xorg-x11-* from FC3 does not solve the white screen problem. > -- Using mharris's libvgahw.a solves the problem halfway - I can boot into > run-level 3, and do 'startx' to get X. However, if I try to boot into run-level > 5, I get the guage that shows during the boot process (suggesting that my > xorg.conf is OK?), but when it comes to the login screen, X keeps trying to > start, with no success. Also, if I try 'init 5' from run-level 3, X keeps > trying to start, again without success. > -- Doing a 'system-config-display --reconfig doesn't change the above behaviour. > > Do I have a problem with kdm/kde - unrelated to this bug? Any information on > where I should be posting this? I have not changed kdmrc from what it came as > in the FC4 distribution. > > Thanks for any pointers. > > Muyiwa
Updating to xorg-x11-6.8.2-43.i386.rpm resolves the problem for me. onboard i815 graphics, rawhide FC thanks
(In reply to comment #3) > For those experiencing issues of this nature, I have uploaded the libvgahw.a > X server module from the current FC3 errata release to my ftp space: > > ftp://people.redhat.com/mharris/libvgahw.a > > This should make it easier for some people to test out the module hopefully, > and also have a temporary workaround. > > Feel free to add additional comments here about your successes with the > FC3 module for /any/ bugzilla bugs in our bugzilla. There are probably > more duplicate issues I haven't found yet, so this would be very helpful > if people posted "potential duplicate" ID's here. > > Thanks everyone. After upgrading from FC3 to FC4 I got a white screen when X loaded. It worked fine in FC3 so I knew the hardware was OK. I am not using a matrox card but rather a trident pci card with tgui9680 chipset in an HP x2000 workstation. Booting to runlevel 3 and replacing /usr/X11R6/lib/modules/libvgahw.a with the one you have posted fixed the problem and made the system usable with X. Thanks alot. DWB
*** Bug 163707 has been marked as a duplicate of this bug. ***
*** Bug 164260 has been marked as a duplicate of this bug. ***
Additional information given by Kristian Høgsberg in bug #163331 : A new rawhide update is available: 6.8.2-44 It has 2 major improvements: 1. It is compiled with a fixed gcc so it should fix many more regressions than -43 for this bug 2. The linux-native-pci-scan patch has been fixed and this should fix the remaining cards
I've updated the RPMs to disable the gcc miscompilation workaround, since gcc-4.0.1-4 now has a fix for the problem. xorg-x11-6.8.2-45 should be in rawhide soon, in the meantime I've put up -45 RPMs built with the new gcc here: http://people.redhat.com/krh/xorg-x11-6.8.2-45/ Please give them a try so we can see if the gcc fix works as intended. Thanks!
Matrox MGA G400 AGP (rev 03) : Fixed.
Intel 845 is also fixed with the -45 RPMs.
(In reply to comment #153) The -45 rpms from the FC4 development/rawhide repository give correct results with a Toshiba Satellite with Trident CyberBlade XPAi1 video, which previously operated incorrectly. (The -43 rpms from Olivier Baudron were also fully satisfactory on this machine.) Robin > I've updated the RPMs to disable the gcc miscompilation workaround, since > gcc-4.0.1-4 now has a fix for the problem. xorg-x11-6.8.2-45 should be in > rawhide soon, in the meantime I've put up -45 RPMs built with the new gcc here: > > http://people.redhat.com/krh/xorg-x11-6.8.2-45/ > > Please give them a try so we can see if the gcc fix works as intended. Thanks!
Replacing the libvgahw.a provided by mharris worked for me. Card: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(In reply to comment #74) > I have a PXE+NFS server setup with fc4 structure up to date via > /usr/lib/anaconda-runtime/* procedure. > > On a HP with a ATI Technologies Inc Rage XL (rev 27) controller all work fine > and the grafical setup is ok. > > On a system VIA with a Trident Microsistem CyberBlade/i1 controller, when X > start the screen come white, if I switch on a text console the usual green edge > appears. > > I have take the rawhide new versione of xorg-x11-*6.8.2-41.i386.rpm and I have > rebuild fc4 install structure. > Now the green edge not appears, the text console work, but the graphical console > still to appear white ad is unusable. On a system FC4 UpToDate I have rebuild xorg-x11-6.8.2-45.src.rpm and I have regenerate the NFS structure (whit the /usr/lib/anaconda-runtime/* procedure) and generate the DVD, then I have try setup my system whit MB VIA with a Trident Microsistem CyberBlade/i1 Video controller. Now all (setup and X) work fine!!. Many thank to all!. Dario Lesca.
I think a FC4.1 release is justified. FC4 did not install on alot of hardware. To continue a release for 9 months that is so flawed is detrimental to the community.
*** Bug 162385 has been marked as a duplicate of this bug. ***
(Specially In reply to comment #46) > Fixes my green-border-in-VC issue too. > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) For me also it worked. I chanced upon reading about this bug. I have Matrox MGA G200 with 16 MB. All the time I was struggling with my monitor TVM As5Dp (poor chap took lot of beating). I only hope that I didnot over stress (reduce age of) the hardware by some experementing with H/V frequencies OR continuing to run in abnormal mode. Any wise word on this issue is applauded here in advance. Thanks.
Good news, thanks for testing. We'll do an FC4 update next week.
-45, like all versions before it in FC4, doesn't work on the SiS 550 chipset with embedded graphics controller. Attached please find the results of "lspci -vvv" on this machine. All attempts at firing up X on this box with FC4 have resulted in reboots. FC3, at least as of a month ago, works fine.
Created attachment 117426 [details] lspci --vvv on the affected machine
I have a Matrox MGA G550 and the xorg-x11-6.8.2-45 did NOT resolve my problems. The things are even worse: i get a black screen when starting x and system stops responding. After a hard reboot, i notice that my root file system is currupt! After formatting hard disk and installing a fresh copy of FC4 i get the same result. To be more precise: 1) The fist time many critical system files (such as /sbin/init) where made unuseable 2) The second time the root hard disk partition wasn't recognized as a valid ext3 partition any more! The issue doesn't seem to be reproduceable with the original FC4 xorg (i get a black screen only). Hard disk does NOT seem to have any physical failure. I might say that the issue happens if and only if xorg-x11-6.8.2-45 is installed and x is starting.
Created attachment 117431 [details] Xorg.0.log from a not working -45 xorg & MGA G550
Tom and Sébastien: Can you please open a new bug report because obviously your problem is not related to this VT switch issue. Also, please update your kernel to the latest rawhide and restart your tests. I will have a look at it. -- Thanks.
I have a Matrox MGA G550 and -45 seems to have got me working OK.
*** Bug 165653 has been marked as a duplicate of this bug. ***
I tried by replacing the libvgahw.a as per message 94 above and it did work on my Athlon 32 with a Matrox Mistique (that is buggy in other ways with X - scrolling ad refresh problems). friscom
*** Bug 165429 has been marked as a duplicate of this bug. ***
*** Bug 151548 has been marked as a duplicate of this bug. ***
*** Bug 164707 has been marked as a duplicate of this bug. ***
I have a Toshiba TE2000 with a Trident CyberBlade XPAi1 Had the same issue with the white screen and blurry console (even after installing in text mode). Solved by: 1. Adding [rhgb vga=791 3] parameters to /etc/grub.conf. kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00 rhgb vga=791 3 2. CHanging [Driver "fbdev"] device parameters in /etc/X11/xorg.conf (under Device section). I'm assuming i'm not really getting the best out of my video card here. Is the fix available on updates via Yum or do i still need to manually replace libvgahw.a?
Asaf Shamir wanted to know if xorg -45 was available via yum. The answer is yes, via the fedora-updates-testing repository. For myself, I accessed it via yumex for the sake of my sanity! Comment 153 above notes that -45 is in development/rawhide. Robin (In reply to comment #174) > I have a Toshiba TE2000 with a Trident CyberBlade XPAi1 > Had the same issue with the white screen and blurry console (even after > installing in text mode). > > Solved by: > 1. Adding [rhgb vga=791 3] parameters to /etc/grub.conf. > kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00 rhgb vga=791 3 > 2. CHanging [Driver "fbdev"] device parameters in /etc/X11/xorg.conf (under > Device section). > > I'm assuming i'm not really getting the best out of my video card here. > Is the fix available on updates via Yum or do i still need to manually replace > libvgahw.a? >
xorg-x11-6.8.2-45 from rawhide fixes the blank screen with green border problem with Mystique (mga1064sg). Was not able to test 43 at the time ot its release.
*** Bug 166303 has been marked as a duplicate of this bug. ***
I also had the same problem on my machine when I switch to console I get a blue border that chops off part of the text (actually it makes part of a the first letter wrap to the line before). After I applied comment #3 and replaced libvgahw.a it fixed my problem. I have a built-in Intel 810 graphics chip. Thanks for the workaround. Also I wish there was more info on where to put the file. I'm a Linux newbie, so i hope i did it correctly. I found libvgahw.a in two locations: /usr/X11R6/lib/Server/modules/libvgahw.a /usr/X11R6/lib/modules/libvgahw.a I replaced both of them.
(In reply to comment #68) > gcc devs seem unable to agree on interpretation of the C standard and > wether or not this is a gcc bug or not. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 > While this specific bug is the only currently-known place in the X > codebase that is giving a runtime problem, there may be other areas > lurking in the code as well. At this point, I believe the only rapid > solution, is to work around the gcc bug (or non-bug depending on > one's viewpoint) by recompiling Xorg with -O0 on any platform which > can reproduce the issues. > I'll be proposing this interim solution with the rest of our X11 > development team tomorrow. Once we've made a decision, I'll roll > it into rawhide. Loks like they have decided it was a bug, and the fix is now in GCC CVS. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
*** Bug 158976 has been marked as a duplicate of this bug. ***
*** Bug 160642 has been marked as a duplicate of this bug. ***
*** Bug 155775 has been marked as a duplicate of this bug. ***
*** Bug 160519 has been marked as a duplicate of this bug. ***
*** Bug 160490 has been marked as a duplicate of this bug. ***
*** Bug 160509 has been marked as a duplicate of this bug. ***
*** Bug 161926 has been marked as a duplicate of this bug. ***
*** Bug 161655 has been marked as a duplicate of this bug. ***
*** Bug 167123 has been marked as a duplicate of this bug. ***
Testing report: G400 based system, went into green-bordered black screen instead of returning to console when exiting X (operating in run level 3). Put in Mike's FC3 based libvgahw.a file, now things work just fine. Was unable to try the rawhide xorg*-45 rpms, they didn't like the glibc installed on my system (2.3.5-10.3, fresh FC4 install with updates) and I wasn't about to enter the dependancy hell of trying the rawhide glibc files from yesterday :)
With respect to #178: on my system, the two copies are in different RPMs. [hugh@redclaw ~]$ rpm -qf /usr/X11R6/lib64/modules/libvgahw.a xorg-x11-6.8.2-45 [hugh@redclaw ~]$ rpm -qf /usr/X11R6/lib64/Server/modules/libvgahw.a xorg-x11-sdk-6.8.2-45 Even so, the files are identical. I got these RPMs from http://people.redhat.com/krh/. See #153. I find it REALLY UNFORTUNATE that there is no official Fedora update to fix this serious bug that has been well-understood for some time.
What makes this bug 'serious'? Its impact is marginally cosmetic, and there is a very simple workaround. This bug is trivial & minor.
(In reply to comment #191) > What makes this bug 'serious'? Its impact is marginally cosmetic, and there is > a very simple workaround. This bug is trivial & minor. The bug is indeed a serious bug, because it causes a large number of end users to be unable to use X at all. It's not just a trivial cosmetic issue. The bug is far from trivial, in fact it is the most critical Fedora Core 4 X.Org bug period. >I find it REALLY UNFORTUNATE that there is no official Fedora update to fix >this serious bug that has been well-understood for some time. Yes, unfortunately the real bug isn't an Xorg bug at all, it is a gcc compiler bug. There are multiple reasons why it is not fixed in an official update yet, and I'll try to explain those, and update everyone with the current plan also. Here's a brief history: - Various bugs were reported individually in bugzilla with various corruption issues during OS install, or with inability to even start the X server, or with X server crash and system hang, or with coloured border around the screen or other visual artifacts. There was not yet any known co-relation between any of the bugs. - Over time, it became more clear that some of the problems were related on mga hardware, so they were closed as dupes of the original mga bug. - Someone who reproduced the problem had the time to diagnose it further and debugged it to discover the "volatile" issue. (details in this bug and others, read full bug and links to others for details) - A patch was created which attempted to work around the volatile issue. That patch was added to an xorg-x11 build and provided for users to test. The results of the testing, were that it solved the problem for some people, but not at all for other people. It wasn't clear if there were multiple completely different issues people were experiencing, or if the patch just didn't work, or if there were more cases that needed workarounds for the issue or other issues. - Our entire X Development team went to conferences for 1 week. Dr. Hugh Redelmeier can attest to this, as he was there. ;o) - I had 2 weeks vacation immediately after that. Our team felt the best solution to the problem was a proper gcc fix, however the gcc people still hadn't acknowledged that it was a real compiler bug. There was no existing patch for X to workaround the issue(s), which actually solved all of the problems, and so no real solution available yet. - Returning from vacation I learned that gcc folk finally admitted it to be a compiler bug, and fixed it. Fedora Core 4's gcc however did not have the fix yet. An update to fix the issue at this point was entirely dependent on having a properly working compiler released as a FC4 update, although that was not the only factor. - At the same time, people have reported that the pciconfig patch causes problems for them, and removing it makes the problem go away. The pciconfig patch is a very important patch that we can not throw away, or we just recreate the bugs that that patch fixes. The only acceptable solution, is to fix the pciconfig patch. - A new patch became available that fixed additional pciconfig related issues, which we've confirmed do actually fix other reported bugs. Unfortunately, there are still users who claim to have done before/after testing, who claim that the "new" pciconfig patch (present in rawhide build -44 and later) still causes them to have problems. Which brings us to current: The compiler issue is fixed, but the pciconfig one is still not fixed. The new pciconfig patch seems to fix some problems for some people, but create new problems for others. We'd like to find a solution to both problems instead of regressing one thing and fixing another, so we've been letting bugzilla collect additional data for us to help determine the best way to resolve both issues. I guess it's also important to note that this bug is not the only high-priority critical thing we're working on right now. ;o) There are several possible directions we can move in now. None are "perfect", but I think it is time to make a decision and stick by that decision knowing that it is not going to solve everyone's problem all at once. We can: - Release FC5 xorg-x11 rebuilt for FC4 with appropriate spec file toggles set. This brings FC4 in sync with rawhide. It also updates the pciconfig patch, which may fix or break some setups. We can continue to track the other problems then, and hopefully find solutions for them for future updates. If we do this, once we release the update to FC4, this "libvgahw" bug will be closed. Some people who are CC'd on this bug may still have problems, and may report back "why was this closed, when I still have a problem???". That is something I'd like to avoid, which is one of the reasons we wanted to solve the other problems as well. However, if we do release the update to fix the gcc issue, anyone still having problems should query bugzilla for other bugs that are still open, which describe their problem, and add themselves to the other bug report - or alternatively file a brand new bug report, indicating that they did experience libvgahw (or thought they did), and now that it is closed, they still have an issue - then describe the issue in total detail, indicate what all xorg-x11 rpms they've tried, which ones worked, which didn't, wether rebuilding with any patches disabled solves the problem, etc. The other option, is to hold off on the update and find solutions to the remaining bugs. At this point, my own inclination is to just go ahead with the FC4 update, so that the problem is fixed for people that only have the gcc/volatile issue. Second reason for the update, is that it means we can close this bug report, which has 191 comments on it which makes it notoriously difficult to try to find comments that are actually still valuable for any remaining problems. I'd rather get new bug reports that just focus on the remaining problems, and only have a handful of really useful comments. ;o) Also, many people are hesitant to try rawhide built xorg-x11, and I cant fault them for that, especially if it drags in new glibc, and other dependencies - I wouldn't do that either. ;o) So... the conclusion is: I think it is time for an FC4 update of a rebuild of rawhide xorg ASAP, and we can deal with any fallout it causes once its out there via new bug reports. Another benefit, is that bugzilla wont choke anymore due to additional comments added to this bug being sent out to 300 people on CC. ;oP I'll update this bug once the update is released, and it can finally R.I.P. Thanks very much to everyone who has participated in narrowing the problem down, to everyone who has provided patches, debugging and troubleshooting, to Hostess for making twinkies, and to Jolt Cola for those long night hack sessions. Stay tuned...
Fixed in xorg-x11-6.8.2-37.FC4.45, which is a merge of FC devel xorg back into FC4, recompiled with the latest FC4 gcc update which no longer has the bug which caused this problem. *********************************************************************** *********************************************************************** *********************************************************************** *** IMPORTANT NOTICE *** *** ================ *** *** After you have upgraded to the xorg-x11-6.8.2-37.FC4.45 *** *** release, this bug will be fixed. If you still have any kind *** *** of stability problems with the X server, or any video *** *** corruption, then you are experiencing a separate problem which *** *** is unrelated to this bug report even if it seems to have *** *** similar or identical symptoms. *** *** *** *** Therefore, anyone still having problems after this update, *** *** should query bugzilla to see if there is another bug opened *** *** already which describes the problem that is occuring for you *** *** and CC yourself on that bug, adding your own details. *** *** *** *** If there isn't already a bug that is still open in bugzilla *** *** which describes your problem, please file a new bug report for *** *** the issue, and describe fully the current problem you are *** *** having in complete detail. Please do not refer to this bug, *** *** or another bug for details, as this one is a massive mess. ;o) *** *** *** *** Be sure to indicate that your new bug is NOT this bug *** *** (libvgahw) to reduce the risk of someone overzealously and *** *** accidentally closing your new bug as a dupe of this one. ;o) *** *** *** *** If you do file a new bug report, mandatorily attach your X *** *** server log file (generated from the newly released xorg-x11), *** *** and config file to the new report as individual uncompressed *** *** file attachments. Also, make sure to tell us in the new report *** *** exactly what xorg-x11 builds you have previously tested and *** *** what the results were/are for each one. If you've experienced *** *** a regression somewhere along the way, knowing which versions *** *** have regressed will help us narrow down the problem. *** *** *** *** Hopefully by putting a massive asterisk border around this, *** *** it will help it stand out in the morass of comments and make *** *** life easier on anyone who stumbles upon the bug. ;o) *** *** *** *********************************************************************** *********************************************************************** ***********************************************************************
In reply to comment #192, > Returning from vacation I learned that gcc folk finally admitted > it to be a compiler bug, and fixed it. Fedora Core 4's gcc > however did not have the fix yet. The volatile issue was fixed in gcc-cvs on July, 19th. Jakub was quick to import the fix in rawhide on July, 21th. An FC4 update (gcc-4.0.1-4.fc4) was available on July, 24th. So presumably the fedora build machine was ready to compile an update of xorg (with a fixed gcc) from this day on. And if I'm right you return from vacation on August, 8th ;) Also about the pci config space issue (bug #163331): The problem was well understood and fixed on July, 25th. Kristian imported the patch in rawhide on July, 28th. So, personally it's one month that I'm waiting for an FC4 update with both of these fixes. Not that I'm tired to answer step by step to people how to update to rawhide, but errr... almost ;) > A new patch became available that fixed additional pciconfig > related issues, which we've confirmed do actually fix other > reported bugs. Unfortunately, there are still users who claim > to have done before/after testing, who claim that the "new" > pciconfig patch (present in rawhide build -44 and later) still > causes them to have problems. Now the important part of my post: +--------------------------------------------------------------------+ | I have never ever heard of someone telling that the updated patch | | of pci config space access was a *regression*. I went here and | | there in a dozen of reports to track one such report and never had | | one. I even made binaries of -45 available on my home page without | | the whole pci patch so that even beginners could test it. | +--------------------------------------------------------------------+ Also, the patch has been fully approved by the xorg team. See recent coments at: https://bugs.freedesktop.org/show_bug.cgi?id=2880 and no regression (from the direct bitbanging situation) was found. If there are some regression, they might be in some drivers (radeon?). Anyway, because of human nature of reporters it will be really easier to track down remaining issues once an FC4 update is available. Thanks for having released it! -- Cheers, Olivier.
(In reply to comment #194) > In reply to comment #192, > > > Returning from vacation I learned that gcc folk finally admitted > > it to be a compiler bug, and fixed it. Fedora Core 4's gcc > > however did not have the fix yet. > > The volatile issue was fixed in gcc-cvs on July, 19th. > Jakub was quick to import the fix in rawhide on July, 21th. > An FC4 update (gcc-4.0.1-4.fc4) was available on July, 24th. > So presumably the fedora build machine was ready to compile an update of xorg > (with a fixed gcc) from this day on. > And if I'm right you return from vacation on August, 8th ;) > > Also about the pci config space issue (bug #163331): > The problem was well understood and fixed on July, 25th. > Kristian imported the patch in rawhide on July, 28th. > > So, personally it's one month that I'm waiting for an FC4 update with both of > these fixes. Not that I'm tired to answer step by step to people how to update > to rawhide, but errr... almost ;) > > > A new patch became available that fixed additional pciconfig > > related issues, which we've confirmed do actually fix other > > reported bugs. Unfortunately, there are still users who claim > > to have done before/after testing, who claim that the "new" > > pciconfig patch (present in rawhide build -44 and later) still > > causes them to have problems. > > Now the important part of my post: > > +--------------------------------------------------------------------+ > | I have never ever heard of someone telling that the updated patch | > | of pci config space access was a *regression*. I went here and | > | there in a dozen of reports to track one such report and never had | > | one. I even made binaries of -45 available on my home page without | > | the whole pci patch so that even beginners could test it. > | > +--------------------------------------------------------------------+ > > Also, the patch has been fully approved by the xorg team. See recent coments at: > https://bugs.freedesktop.org/show_bug.cgi?id=2880 and no regression (from the > direct bitbanging situation) was found. > > If there are some regression, they might be in some drivers (radeon?). > > Anyway, because of human nature of reporters it will be really easier to track > down remaining issues once an FC4 update is available. Thanks for having > released it! > > -- Cheers, Olivier. Well, there is a lot more to the story than I felt was necessary to describe in the bug report. All 4 of us are very busy people with numerous responsibilities, of which have been higher priority. Coming back from 3 weeks abscense from work, with a pileup of high priority urgent work to do, catching up on email and other matters, means issues of this nature which are more "important" class, will sometimes wait until "urgent" class things are out of the way, in particular if there are still unknowns in the picture. However, the update is out there now, so people who have waited can just go and get it. Discussing the details of how and why it took this long is an interesting exercise in testing how many emails the bugzilla server can send out, but just takes our precious time away from fixing other issues that are open still. ;o) So, I ask everyone to please install the update, and follow comment #193, and lets move on to bigger and better things now rather than wasting time justifying how long a bug took to close. Fedora Core is a dynamic quantity, and has no bugfix deadlines or guarantees. ;o) Thanks again everyone for helping narrow this problem down.
i tried the new version for FC4 on an Intel 865G and things worked with the distributed version. The Intel 815 works, but only tested with Rawhide version. Dropping from the CC. Thanks for the help and learning encountered with this bug. No more for FC5 please. - :-)
I had same bug at my essay website: https://www.wowessays.com/