Bug 161242 - (libvgahw) libvgahw.a is broken in FC4 due to gcc 4.0.0 bug, fixed in gcc 4.0.1
libvgahw.a is broken in FC4 due to gcc 4.0.0 bug, fixed in gcc 4.0.1
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
: 151548 151688 green-border 154502 155416 155775 157556 157593 158976 159106 160287 160307 160453 160470 160477 160490 160500 160509 160519 160580 160642 160777 160950 161047 161566 161655 161756 161926 162385 162567 163104 163707 164260 165429 165653 166303 167123 (view as bug list)
Depends On: 162274
Blocks: 151252 151336 151688 green-border 154502 157556 159106 160307 160453 160470 160500
  Show dependency treegraph
 
Reported: 2005-06-21 13:18 EDT by Mike A. Harris
Modified: 2007-11-30 17:11 EST (History)
85 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-31 22:30:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
It works for Intel 815 (37.27 KB, text/plain)
2005-07-14 22:17 EDT, Jim Cornette
no flags Details
lspci --vvv on the affected machine (4.24 KB, text/plain)
2005-08-03 21:08 EDT, Tom Wood
no flags Details
Xorg.0.log from a not working -45 xorg & MGA G550 (38.82 KB, text/plain)
2005-08-04 01:44 EDT, Sébastien La Paola
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 22278 None None None Never
FreeDesktop.org 2976 None None None Never
FreeDesktop.org 2991 None None None Never

  None (edit)
Description Mike A. Harris 2005-06-21 13:18:23 EDT
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.
Comment 1 Joe Ceklosky 2005-06-21 13:52:20 EDT
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.


Comment 2 Mike A. Harris 2005-06-21 16:13:23 EDT
(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.
Comment 3 Mike A. Harris 2005-06-22 17:12:50 EDT
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.
Comment 4 Mike A. Harris 2005-06-22 17:47:04 EDT
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.
Comment 5 Michael A. Peters 2005-06-22 18:04:50 EDT
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)
Comment 6 wilksen 2005-06-22 19:56:57 EDT
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).
Comment 7 Mike A. Harris 2005-06-22 20:35:19 EDT
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.  ;)
Comment 8 frollic nilsson 2005-06-23 12:09:42 EDT
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.
Comment 9 Matthew Flint 2005-06-23 12:22:08 EDT
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.
Comment 10 Stephen Adler 2005-06-23 12:50:07 EDT
I can report that I have X11 problems on my amd64 platform with a Matrox G450 card.
Comment 11 Mike A. Harris 2005-06-23 13:13:59 EDT
*** Bug 159106 has been marked as a duplicate of this bug. ***
Comment 12 Mike A. Harris 2005-06-23 13:21:28 EDT
*** Bug 160500 has been marked as a duplicate of this bug. ***
Comment 13 Mike A. Harris 2005-06-23 13:29:03 EDT
*** Bug 161047 has been marked as a duplicate of this bug. ***
Comment 14 Mike A. Harris 2005-06-23 13:44:25 EDT
*** Bug 160470 has been marked as a duplicate of this bug. ***
Comment 15 Mike A. Harris 2005-06-23 13:54:46 EDT
*** Bug 160453 has been marked as a duplicate of this bug. ***
Comment 16 Dave Malcolm 2005-06-23 13:56:22 EDT
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.
Comment 17 Mike A. Harris 2005-06-23 14:01:12 EDT
https://bugs.freedesktop.org/show_bug.cgi?id=2976 is seemingly related,
and linked to our bug #151688 as well.
Comment 18 Mike A. Harris 2005-06-23 14:11:04 EDT
*** Bug 160307 has been marked as a duplicate of this bug. ***
Comment 19 Doug Townes 2005-06-23 14:18:01 EDT
Can this file be inserted into the installation somehow so a graphical 
installation can be run?  Without graphical installation I cannot use LVM.
Comment 20 Mike A. Harris 2005-06-23 14:27:50 EDT
(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.
Comment 21 Mike A. Harris 2005-06-23 14:42:29 EDT
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.
Comment 22 Florian Knell 2005-06-23 17:19:49 EDT
*** Bug 160777 has been marked as a duplicate of this bug. ***
Comment 23 Mike A. Harris 2005-06-23 17:28:45 EDT
*** Bug 151688 has been marked as a duplicate of this bug. ***
Comment 24 Dave Malcolm 2005-06-23 19:00:07 EDT
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.
Comment 25 Jim Cornette 2005-06-23 20:34:05 EDT
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.
Comment 26 Frank Wang 2005-06-23 22:04:34 EDT
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. 
Comment 27 Doug Townes 2005-06-24 10:51:26 EDT
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
Comment 28 Doug Townes 2005-06-24 10:58:34 EDT
Go figure.  Re-ftp'd the file and rebooted again - works fine now ...
Comment 29 Mike A. Harris 2005-06-24 12:24:45 EDT
*** Bug 154502 has been marked as a duplicate of this bug. ***
Comment 30 Mike A. Harris 2005-06-24 12:35:12 EDT
*** Bug 161566 has been marked as a duplicate of this bug. ***
Comment 31 Michael Forrest 2005-06-25 06:58:00 EDT
*** Bug 160950 has been marked as a duplicate of this bug. ***
Comment 32 Michael Forrest 2005-06-25 07:18:01 EDT
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!
Comment 33 Mark A. Schwenk 2005-06-25 08:44:52 EDT
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.
Comment 34 Matthew Flint 2005-06-25 13:17:57 EDT
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".
Comment 35 Robin Gape 2005-06-25 14:08:08 EDT
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.
Comment 36 Mike A. Harris 2005-06-25 16:22:01 EDT
*** Bug 160580 has been marked as a duplicate of this bug. ***
Comment 37 Mike A. Harris 2005-06-25 16:26:02 EDT
(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!
Comment 38 Robert Scheck 2005-06-25 18:49:44 EDT
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 :(
Comment 39 redhat-bugs2eran 2005-06-26 12:49:07 EDT
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.
Comment 40 Michael A. Peters 2005-06-26 14:35:33 EDT
(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.
Comment 41 Scootre 2005-06-26 20:14:00 EDT
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.
Comment 42 tmoey 2005-06-27 10:07:35 EDT
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.
 
Comment 43 Charles Curley 2005-06-27 10:25:45 EDT
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]
Comment 44 tmoey 2005-06-27 11:00:23 EDT
(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.

Comment 45 Colin Charles 2005-06-28 10:16:29 EDT
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)
Comment 46 Rob K 2005-06-29 02:35:38 EDT
Fixes my green-border-in-VC issue too.

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01)
Comment 47 Carl Sychowski 2005-06-29 02:38:33 EDT
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)
Comment 48 Tauroka 2005-06-29 03:56:39 EDT
"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.
Comment 49 Wayne Walker 2005-06-29 09:25:25 EDT
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.
Comment 50 Mike A. Harris 2005-06-29 16:08:57 EDT
*** Bug 157556 has been marked as a duplicate of this bug. ***
Comment 51 Mike A. Harris 2005-06-29 16:09:02 EDT
*** Bug 161756 has been marked as a duplicate of this bug. ***
Comment 52 Mike A. Harris 2005-06-29 16:12:59 EDT
*** Bug 153729 has been marked as a duplicate of this bug. ***
Comment 53 Mike A. Harris 2005-06-29 17:19:34 EDT
*** Bug 160477 has been marked as a duplicate of this bug. ***
Comment 54 Jens Petersen 2005-06-30 01:05:29 EDT
*** Bug 155416 has been marked as a duplicate of this bug. ***
Comment 55 Dominik Bozek 2005-06-30 15:03:29 EDT
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.
Comment 56 Olivier Baudron 2005-07-01 15:22:51 EDT
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.
Comment 57 D. Hugh Redelmeier 2005-07-01 16:05:16 EDT
#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);
}
Comment 58 D. Hugh Redelmeier 2005-07-01 16:15:49 EDT
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).
Comment 59 D. Hugh Redelmeier 2005-07-01 16:46:30 EDT
I've written this up as a gcc bug: bug 162274
Comment 60 Olivier Baudron 2005-07-02 04:24:03 EDT
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);
}
Comment 61 Dave Jenkins 2005-07-02 07:05:51 EDT
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)
Comment 62 Jim Cornette 2005-07-02 10:30:44 EDT
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.
Comment 63 Olivier Baudron 2005-07-02 11:12:36 EDT
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);
 }
Comment 64 D. Hugh Redelmeier 2005-07-02 11:29:24 EDT
[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.
Comment 65 Olivier Baudron 2005-07-02 11:46:11 EDT
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.
Comment 66 tmoey 2005-07-04 10:38:36 EDT
(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.

Comment 67 D. Hugh Redelmeier 2005-07-04 11:01:22 EDT
Re comment #66: please read comment #3 -- Mike provides an i386 binary.

Mike: could you also provide an x86_64 binary?
Comment 68 Mike A. Harris 2005-07-05 04:20:50 EDT
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.

Comment 69 Colin Charles 2005-07-05 05:24:53 EDT
(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

Comment 70 Mike A. Harris 2005-07-05 06:37:58 EDT
(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
Comment 71 James Curtis 2005-07-05 09:28:39 EDT
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.  
Comment 72 Colin Charles 2005-07-05 09:45:32 EDT
(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
Comment 73 Mike A. Harris 2005-07-05 19:37:25 EDT
*** Bug 160287 has been marked as a duplicate of this bug. ***
Comment 74 Dario Lesca 2005-07-07 13:11:13 EDT
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)
Comment 76 Mike A. Harris 2005-07-07 18:30:24 EDT
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.
Comment 77 Shrinivas Varanasy 2005-07-08 04:53:23 EDT
*** Bug 162567 has been marked as a duplicate of this bug. ***
Comment 78 Jay McDonald 2005-07-08 17:36:54 EDT
Anyone have an X86_64 version of this file?

Jay
Comment 79 Jay McDonald 2005-07-08 17:38:28 EDT
Anyone have an X86_64 version of this file?

Jay
Comment 80 Chia-Ling Lee 2005-07-08 21:46:54 EDT
Copying the FC3 version of the file solved the problem 
for me too - after SELinux worked out the permission
required. 
Comment 81 James Couball 2005-07-09 23:00:51 EDT
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).
Comment 82 Florian La Roche 2005-07-10 16:06:52 EDT
ftp://people.redhat.com/mharris/libvgahw.a fixes my problems with
a G400 AGP (rev 82).

Thanks,

Florian La Roche
Comment 83 John Lindgren 2005-07-10 22:18:43 EDT
(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-
Comment 84 Sergio Monteiro Basto 2005-07-11 12:57:14 EDT
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,
Comment 85 Mike A. Harris 2005-07-11 19:52:20 EDT
*** Bug 157593 has been marked as a duplicate of this bug. ***
Comment 86 Dave Jones 2005-07-12 18:04:35 EDT
*** Bug 163104 has been marked as a duplicate of this bug. ***
Comment 87 Wayne Carruthers 2005-07-13 03:40:06 EDT
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
Comment 89 Mike A. Harris 2005-07-13 06:16:51 EDT
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.
Comment 90 Michael Schwendt 2005-07-13 12:08:42 EDT
xorg-x11-6.8.2-43 running in an up-to-date Fedora Core Development installation
fixes my issues with MGA G400 (bug 151252).
Comment 91 Kazutoshi Morioka 2005-07-13 12:21:15 EDT
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
Comment 92 Pascal de Bruijn 2005-07-13 13:38:51 EDT
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!
Comment 93 Andreas Karajannis 2005-07-13 14:33:51 EDT
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 .
Comment 94 Mike A. Harris 2005-07-13 14:56:05 EDT
*** 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.
Comment 95 Michael A. Peters 2005-07-13 16:27:47 EDT
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
Comment 96 David Holland-Moritz 2005-07-13 18:13:09 EDT
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.
Comment 97 Joe Ceklosky 2005-07-13 21:47:00 EDT
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?
Comment 98 Mike A. Harris 2005-07-14 00:09:02 EDT
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.
Comment 99 Mike A. Harris 2005-07-14 00:13:36 EDT
(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.
Comment 100 Christof Damian 2005-07-14 02:11:24 EDT
For me replacing all the xorg packages with FC3 versions did the trick. Just
swapping libvgahw.a was not enough.
Comment 101 Michael A. Peters 2005-07-14 02:16:43 EDT
(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.
Comment 102 zach w 2005-07-14 02:18:51 EDT
upgrading xorg-x11 as in comment #91 fixed the problem for my Savage/IX-MV
(thinkpad T20). Didn't try libvgahw.a. Thanks.
Comment 103 Michael A. Peters 2005-07-14 03:28:31 EDT
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)
Comment 104 Michael A. Peters 2005-07-14 03:50:14 EDT
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.
Comment 105 Dr J Austin 2005-07-14 06:47:56 EDT
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


Comment 106 Joe Ceklosky 2005-07-14 07:40:03 EDT
(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?


Comment 107 James Juran 2005-07-14 08:20:12 EDT
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.
Comment 108 Mike A. Harris 2005-07-14 11:03:23 EDT
(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
Comment 109 Mike A. Harris 2005-07-14 11:15:47 EDT
(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)
Comment 110 Michael Lee Yohe 2005-07-14 11:21:57 EDT
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.
Comment 111 Mike A. Harris 2005-07-14 11:42:51 EDT
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...
Comment 112 Alejandro Gonzalez Hernandez - Imoq 2005-07-14 12:02:25 EDT
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)
Comment 113 Alexander Boström 2005-07-14 15:05:56 EDT
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.
Comment 114 Robin Gape 2005-07-14 18:28:36 EDT
(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)
> 

Comment 115 Jim Cornette 2005-07-14 21:30:58 EDT
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.
Comment 116 Jim Cornette 2005-07-14 21:38:56 EDT
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
Comment 117 Jim Cornette 2005-07-14 22:17:18 EDT
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.
Comment 118 Mike A. Harris 2005-07-15 01:45:05 EDT
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@lists.freedesktop.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
Comment 119 Iain Arnell 2005-07-15 03:58:25 EDT
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.
Comment 120 Olivier Baudron 2005-07-15 04:03:46 EDT
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.
Comment 121 Joe Ceklosky 2005-07-15 07:33:07 EDT
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
Comment 122 Chris Siebenmann 2005-07-15 16:52:00 EDT
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.
Comment 123 Jim Cornette 2005-07-16 14:56:08 EDT
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@lists.freedesktop.org if not already discussed.
Comment 124 D. Hugh Redelmeier 2005-07-17 04:01:08 EDT
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!
Comment 125 Dr J Austin 2005-07-17 09:24:52 EDT
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
Comment 126 Joe Ceklosky 2005-07-17 16:55:48 EDT
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
Comment 127 Przemek Klosowski 2005-07-18 16:06:18 EDT
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.

Comment 128 D. Hugh Redelmeier 2005-07-18 18:07:26 EDT
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.
Comment 129 Brian Harris 2005-07-19 19:54:31 EDT
It worked for me on a Dell C400, thank you much.
Comment 130 Olivier Baudron 2005-07-21 09:41:33 EDT
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-*
Comment 131 Olivier Baudron 2005-07-21 15:24:03 EDT
Recompiled binaries rpms can be found at:
http://olivier.baudron.free.fr/RPMS/i386/
Testing is welcome!
Comment 132 Joe Ceklosky 2005-07-22 08:13:27 EDT
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.
Comment 133 Ken Adams 2005-07-22 12:55:58 EDT
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
Comment 134 Ken Adams 2005-07-22 12:56:58 EDT
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
Comment 135 Ken Adams 2005-07-22 12:57:47 EDT
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
Comment 136 Robin Gape 2005-07-22 19:36:15 EDT
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!

Comment 137 Jim Cornette 2005-07-22 19:58:05 EDT
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.
Comment 138 Jim Cornette 2005-07-22 20:04:45 EDT
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!
Comment 139 Muyi Taiwo 2005-07-25 07:23:16 EDT
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
Comment 140 Muyi Taiwo 2005-07-25 07:24:14 EDT
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
Comment 141 Kevin Fries 2005-07-25 14:20:24 EDT
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
Comment 142 Matt C 2005-07-26 11:36:49 EDT
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
Comment 143 Matt C 2005-07-26 12:46:31 EDT
(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.
Comment 144 Olivier Baudron 2005-07-26 14:22:46 EDT
Your problem is known and fixed at bug #163331
Comment 145 Alejandro Gonzalez Hernandez - Imoq 2005-07-26 18:27:15 EDT
(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)
Comment 146 Dave Jenkins 2005-07-26 19:52:29 EDT
(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.
Comment 147 Muyi Taiwo 2005-07-26 20:52:40 EDT
(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

Comment 148 Pavol Šimo 2005-07-27 07:52:16 EDT
Updating to xorg-x11-6.8.2-43.i386.rpm resolves the problem for me.

onboard i815 graphics, rawhide FC

thanks
Comment 149 DWB 2005-07-27 11:33:02 EDT
(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
Comment 150 Colin Charles 2005-07-29 05:28:16 EDT
*** Bug 163707 has been marked as a duplicate of this bug. ***
Comment 151 Olivier Baudron 2005-07-29 11:45:43 EDT
*** Bug 164260 has been marked as a duplicate of this bug. ***
Comment 152 Olivier Baudron 2005-07-29 11:59:15 EDT
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
Comment 153 Kristian Høgsberg 2005-07-29 18:03:02 EDT
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!
Comment 154 Olivier Baudron 2005-07-30 03:41:34 EDT
Matrox MGA G400 AGP (rev 03) : Fixed.
Comment 155 James Juran 2005-07-30 11:45:50 EDT
Intel 845 is also fixed with the -45 RPMs.
Comment 156 Robin Gape 2005-07-30 13:46:55 EDT
(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!

Comment 157 Jasper O. Hartline 2005-07-31 11:51:16 EDT
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)
Comment 158 Dario Lesca 2005-08-01 11:21:12 EDT
(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.
Comment 159 Paul Coleman 2005-08-01 22:33:43 EDT
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.
Comment 160 Olivier Baudron 2005-08-02 06:41:17 EDT
*** Bug 162385 has been marked as a duplicate of this bug. ***
Comment 161 Anil Kumar Sharma 2005-08-03 08:23:31 EDT
(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.
Comment 162 Kristian Høgsberg 2005-08-03 11:47:55 EDT
Good news, thanks for testing.  We'll do an FC4 update next week.
Comment 163 Tom Wood 2005-08-03 21:02:27 EDT
-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.
Comment 164 Tom Wood 2005-08-03 21:08:53 EDT
Created attachment 117426 [details]
lspci --vvv on the affected machine
Comment 165 Sébastien La Paola 2005-08-03 21:34:27 EDT
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.
Comment 166 Sébastien La Paola 2005-08-04 01:44:49 EDT
Created attachment 117431 [details]
Xorg.0.log from a not working -45 xorg & MGA G550
Comment 167 Olivier Baudron 2005-08-04 08:02:52 EDT
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.
Comment 168 John C. Bonnett 2005-08-04 08:13:13 EDT
I have a Matrox MGA G550 and -45 seems to have got me working OK.
Comment 169 Olivier Baudron 2005-08-11 03:17:32 EDT
*** Bug 165653 has been marked as a duplicate of this bug. ***
Comment 170 Francesco Millotti 2005-08-11 12:48:25 EDT
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
Comment 171 Olivier Baudron 2005-08-11 17:17:36 EDT
*** Bug 165429 has been marked as a duplicate of this bug. ***
Comment 172 Dave Jones 2005-08-11 18:38:16 EDT
*** Bug 151548 has been marked as a duplicate of this bug. ***
Comment 173 Olivier Baudron 2005-08-12 06:52:22 EDT
*** Bug 164707 has been marked as a duplicate of this bug. ***
Comment 174 Asaf Shamir 2005-08-16 23:15:36 EDT
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?
Comment 175 Robin Gape 2005-08-17 06:29:34 EDT
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?
> 

Comment 176 Yanko Kaneti 2005-08-17 08:06:52 EDT
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.
Comment 177 Olivier Baudron 2005-08-24 12:51:06 EDT
*** Bug 166303 has been marked as a duplicate of this bug. ***
Comment 178 matwan2 2005-08-28 12:25:01 EDT
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.
Comment 179 J. D. Jordan 2005-08-29 16:54:20 EDT
(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
Comment 180 Mike A. Harris 2005-08-30 03:44:40 EDT
*** Bug 158976 has been marked as a duplicate of this bug. ***
Comment 181 Mike A. Harris 2005-08-30 03:58:27 EDT
*** Bug 160642 has been marked as a duplicate of this bug. ***
Comment 182 Mike A. Harris 2005-08-30 04:06:47 EDT
*** Bug 155775 has been marked as a duplicate of this bug. ***
Comment 183 Mike A. Harris 2005-08-30 04:10:38 EDT
*** Bug 160519 has been marked as a duplicate of this bug. ***
Comment 184 Mike A. Harris 2005-08-30 04:15:51 EDT
*** Bug 160490 has been marked as a duplicate of this bug. ***
Comment 185 Mike A. Harris 2005-08-30 04:25:17 EDT
*** Bug 160509 has been marked as a duplicate of this bug. ***
Comment 186 Mike A. Harris 2005-08-30 04:25:35 EDT
*** Bug 161926 has been marked as a duplicate of this bug. ***
Comment 187 Mike A. Harris 2005-08-30 04:28:41 EDT
*** Bug 161655 has been marked as a duplicate of this bug. ***
Comment 188 Mike A. Harris 2005-08-30 13:19:59 EDT
*** Bug 167123 has been marked as a duplicate of this bug. ***
Comment 189 Habig, Alec 2005-08-31 11:36:35 EDT
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 :)
Comment 190 D. Hugh Redelmeier 2005-08-31 17:25:27 EDT
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.
Comment 191 Lonni J Friedman 2005-08-31 17:35:55 EDT
What makes this bug 'serious'?  Its impact is marginally cosmetic, and there is
a very simple workaround.  This bug is trivial & minor.
Comment 192 Mike A. Harris 2005-08-31 18:32:05 EDT
(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...

Comment 193 Mike A. Harris 2005-08-31 21:39:01 EDT
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)           ***
***                                                                 ***
***********************************************************************
***********************************************************************
***********************************************************************
Comment 194 Olivier Baudron 2005-09-01 05:06:49 EDT
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.
Comment 195 Mike A. Harris 2005-09-02 00:22:32 EDT
(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.
Comment 196 Jim Cornette 2005-09-03 08:43:21 EDT
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. - :-)

Note You need to log in before you can comment on or make changes to this bug.