I'm seeing similar behaviour (blank, fully black screen when switching F7 screen
to CtrlAlt F1-F6)

This is on Fedora Rawhide(ish) box, Intel Corp 828245G/GL integrated graphics
device; though, the I810 driver rather than mga.

xorg-x11-6.8.2-20

If you need more info, let me know.  (I'm in the cube next to krh if that's helpful)

Same with a Matrox G400.
Black screen with a green border when switching from Xorg to Cont/Alt/F1-6.

Video card : Matrox MGA G400 AGP (rev 04)
Distribution : FC4 Test 2
Kernel : kernel-2.6.11-1.1240_FC4
Xorg : xorg-x11-6.8.2-22
Arch : i386 (AMD athlon xp)
Mainbord : MSI KT266

Same with a Matrox Mystique (mga1064sg)

This very much sounds like a general bug in the mga driver, as people are
reporting it on a variety of mga hardware.

For those of you experiencing this during OS installation, can you please
try to do a text mode installation, and then configure X afterward.  For
Fedora users, this would be:  "system-config-display --reconfig".  Users
of other distributions experiencing this problem, try using your distro's
custom X config tool, or if there isn't one, try using "xorgcfg" if it
is supplied.

Once you've configured X, start the server, and try to reproduce the
problem.  Does it reproduce?

If using Fedora, and the problem is reproduceable at runtime, try
doing "rpm -e rhgb" and rebooting your system.  Then start up X again.
Does the problem still occur?

Assuming the issue still occurs, the next troubleshooting step, would
be to disable DRI by commenting out the line:

    Load "dri"

in your xorg.conf and restarting X again.  Please indicate if disabling
DRI changes the problem in any way.

Next step is to try disabling render acceleration by adding to your device
section:

    Option "norenderaccel"

Again start the server and try to reproduce, and indicate any changes.

Finally, try using:

    Option "noaccel"

And indicate if there are any changes, etc.


Also, everyone having this problem, please attach your complete X server
log file and config file as individual uncompressed bugzilla file attachments
using the "Create a New Attachment" link above, or by clicking on this
link:

    https://bugs.freedesktop.org/attachment.cgi?bugid=2991&action=enter

All of this information will help Xorg developers to investigate the
cause of the problem, and hopefully find a fix or workaround.

Thanks in advance.

As one of the Matrox MGA G400 AGP victims ( more details in
http://bugzilla.redhat.com/151252 ) here's the result of trying the
troubleshooting steps from comment 4:

  no rhgb => no difference
  no dri => no difference
  "Option norenderaccel" => no difference
  "Option noaccel" => no difference

In all cases, I get a bright green border surrounding a blank black screen on
all virtual consoles. The same green border appears for tens of a second when
the X server is started. The blue border, blue screen and green screen described
in above bug report at RH are gone in Fedora Core 4 Test 2.

Attaching config/log files...

Created attachment 2471 [details]
Xorg.0.log for MGA G400

Created attachment 2472 [details]
xorg.conf for MGA G400

Created attachment 2473 [details]
Xorg.0.log for MGA G550

Created attachment 2474 [details]
xorg.conf for MGA G550

None of the suggested changes had any effect
I will try to attach a screen capture file with next submit
it is 1.9MB !

Created attachment 2476 [details]
Screen capture showing "second" worse ? problem for MGA G550 FC4T2

Its now a gif file and a lot smaller !!!
This effect is present during FV4T2 install
and when booted to run level 5
the Control/Alt/Fx problem is also there

No difference here with any of the changes in comment 4
I am only testing only the blank screen with green border issue
not the Graphics installation problem
Attaching log files...

Created attachment 2486 [details]
Xorg.0.log  for Mystique (mga1064sg)

Created attachment 2487 [details]
xorg.conf for Mystique (mga1064sg)

When I ctrl-alt-f1 on a Dell running FC4T2, I get a black screen also.  Hardware
is detected as:

(--) PCI:*(0:2:0) Intel Corp. 82865G Integrated Graphics Device rev 2, Mem @
0xe8000000/27, 0xfeb80000/19, I/O @ 0xed98/3

(II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100,
	i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G

Package version is: xorg-x11-6.8.2-19

I can provide a full log if desired.  It doesn't look like this problem is
MGA-only...

This bug report is about VTswitch problems on mga hardware.  If you are
having VTswitch problems on Intel or other hardware, please file your
own bug report, because they are different video drivers for each hardware
and thus different bugs.

When the mga driver bug is fixed and this bug closed, your Intel issue
will be lost otherwise.

Additional Comment #1  shows same/similar bug !!

"This is on Fedora Rawhide(ish) box, Intel Corp 828245G/GL integrated graphics
device; though, the I810 driver rather than mga."

Also I hope it is not just about the Control/Alt/Switch problem
See attachment 2476 [details] !!!!!!

Re comments 1, 14, 15, 16; I've filed this bug to cover the problem on I810:
https://bugs.freedesktop.org/show_bug.cgi?id=3094

As a comparison, I do not have this problem on a computer with a radeon driver
that was recently fixed. The problem on the Intel 815 allows text to display in
terminal. The problem is with the first character starting on the rightmost
portion of the screen, then displaying the rest of the text on the next line.
X seems to work fine. The problem is in the virtual terminal only for the Intel
815 card.

I have a S3 Savage, and this bug accurately describes the problem for me also.

(--) PCI:*(1:0:0) S3 Inc. Savage 4 rev 3, Mem @ 0xf7f80000/19, 0xe8000000/27

After starting X, consoles have strangely colored borders and backgrounds (not
always the same color either). As noted, the border is about 0.25 of an inch or
so. Letters at the edge of the screen scroll to the other side.

Unique so far for me is that if I disable DRI, and switch from X console to a
different console I get the borders/colors, but can clearly see text. With DRI
enabled, and I change to console, I get a blank screen.

I don't use rhgb.

When leaving X the screen is totally corrupted (i.e. strange colors and text is
garbage/ unreadable).

I am running Fedora Core 4 test 2 w/ xorg-x11-6.8.2-27

Problem is 100% reproducable.

At te resolution that I run 1280x1024@24 I do not use DRI. I see the border and
text. I have not tried at a lower resolution and depth to see if the terminals
are blank and without text. I'll check this out sometime later.

(In reply to comment #12)
> Created an attachment (id=2486) [edit]
> Xorg.0.log  for Mystique (mga1064sg)
> 

Quoting the log file:
----------------------------------
Symbol XAAGetCachePlanarMonoStipple from module
/usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved!
Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/mga_drv.o is
unresolved!
Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/mga_drv.o is
unresolved!
Symbol XAAGetCachePlanarMonoStipple from module
/usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved!
Symbol XAAGetCachePlanarMonoStipple from module
/usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved!
Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/mga_drv.o is
unresolved!
---------------------------------

I also get those messages on my g450.  Are they related to this bug?
Has anyone tried to get rid of these problems and seen if that affects
this bug?

Bug #3250 shows nearly the same behavior on PowerPC Mac mini (ATI Radeon 9200),
ViewSonic A50 CRT.

FCFC4T3 i386  !!!!
Both the CONTROL-ALT-Fx and the corrupt screen problem still there
on Matrox G550,  Athlon64 machine.
Corrupt screen both during and after installation

Sorry, that is bug #3280 (not 3250) that shows the same problem on PowerPC Mac
mini (ATI Radeon 9200), ViewSonic A50 CRT.

On the theory that xorg-x11 6.8.2 might have introduced this, well, with Fedora
Core 3 and xorg-x11-6.8.2-1.FC3.13 (latest from Updates) the problem is not
reproducible.

So, as comparison: to get FC4T3's xorg-x11 version built with GCC 3.4.3 (not
GCC4) for FC3 would be interesting.

I just had to do it !!!! FC4T3-i386 Athlon64
Remove all of xorg-x11-6.8.2-30 and fonts-xorg-6.8.2-1
s1=`rpm -qa|grep -i xorg-x11`
rpm -e --nodeps $s1
s2=`rpm -qa|grep -i fonts-xorg`
rpm -e --nodeps $s2

mount the FC3 DVD and change to correct dir
Install xorg-x11-6.8.1-12 and fonts-xorg-6.8.1-1
s3=`ls xorg-x11*`
rpm -i --nodeps $s3
s4=`ls fonts-xorg*`
rpm -i --nodeps $s4
Reboot
The corrupt screen at Control-Alt-F7 has gone and
Control-Alt-F1-6 now work correctly !!!!
The machine is superficially very usable but I assume
I will have problems at some stage !!

(In reply to comment #26)
> I just had to do it !!!! FC4T3-i386 Athlon64
> Remove all of xorg-x11-6.8.2-30 and fonts-xorg-6.8.2-1
> s1=`rpm -qa|grep -i xorg-x11`
> rpm -e --nodeps $s1
> s2=`rpm -qa|grep -i fonts-xorg`
> rpm -e --nodeps $s2
> 
> mount the FC3 DVD and change to correct dir
> Install xorg-x11-6.8.1-12 and fonts-xorg-6.8.1-1
> s3=`ls xorg-x11*`
> rpm -i --nodeps $s3
> s4=`ls fonts-xorg*`
> rpm -i --nodeps $s4
> Reboot
> The corrupt screen at Control-Alt-F7 has gone and
> Control-Alt-F1-6 now work correctly !!!!
> The machine is superficially very usable but I assume
> I will have problems at some stage !!

While this is useful information to a point, unfortunately, it isn't
scientific method as you've changed multiple things - the xorg you're using,
and also the compiler and toolchain it was built with, among other things.

fonts-xorg is irrelevant, and I strongly recommend using the FC4 fonts-xorg.
They're *just* fonts, no code.  The only differences between the two, are
some fonts that were previously missing due to an Xorg font installation
bug, are now restored (lucida), and speedo fonts are now removed as they're
not supported anymore by the X server. Additionally the FC4 fonts-xorg fixes
some rpm font installation/upgrade script problems.  Summary:  fonts-xorg
is 100% unrelated to the problem described here, and you're best off using
the latest fonts-xorg packages.

Back to the real problem now... Let me help a bit by recommending some
further tests:

Can you take the xorg-x11 src.rpm from FC4test3, install it on a *FC3*
system, edit the spec file, and append ".fc3test.0" to the "Release"
field, but do NOT change anything else in the spec file at all.  Then do:

rpmbuild -ba xorg-x11.spec

After it all rebuilds, which can take anywhere from 15 minutes to several
hours depending on the speed of your computer, test the resulting build
on the FC3 computer and indicate wether the problem is reproduceable on
FC3 with the rebuilt FC4 src.rpm on FC3.

If FC4 xorg rebuilt unmodified (at source level) on FC3 works ok on FC3,
then it could be a variety of things causing the FC4 problem, some of which
might be:

1) FC4 compiler/toolchain bug
2) bug in FC4 kernel
3) change in FC4 kernel which isn't a bug, but causes X to behave differently
   for some reason, which might require X to be modified to handle the new
   kernel.

Of the 3, #2 would be my primary suspect, then #1.  We can explore these
and other options once we have the info.  

To help determine which of these might be the case, try installing the
FC4 kernel, and any direct dependancies it has into FC3 without changing
xorg-x11 now.  Reboot into FC4 kernel on FC3 system and try the FC3
rebuilt version of FC4 X out again under this new kernel.  If the problems
come back now, I think we can conclude this is actually a kernel bug or
at least some new X<-> kernel interaction issue due to an FC4 kernel
change.  Another possibility is an FC4 SElinux bug or SElinux policy
bug.  You might want to try disabling SElinux also to see if that changes
anything.

That concludes FC3 rebuild testing.

Now copy the FC3 built FC4 xorg rpms to the FC4 computer, and upgrade
it's xorg to them.  Make sure it upgraded properly.  Now test X out.  If
the problem disappears, I think it's safe to conclude it is NOT an FC4
kernel bug, and seems to instead be related to the compiler or toolchain.
If the FC3 built FC4 xorg fails on FC4 however, but works ok on FC3, I
would lean towards it being a kernel bug or SElinux related issue.


Anyone who experiences the problem described in this bug report who could
perform these (likely somewhat time consuming) tests, would help a lot
to narrow down the possibilities of where the problem might lay.

Thanks in advance.

Oh, one more thing...  If it turns out that the compiler or other parts
of the toolchain do become the factor that causes the changes in behaviour,
then we need to investigate wether the problems are due to compiler/toolchain
bugs, or due to bad/broken assumptions in the X code which compile differently
under different compilers.  Either is equally possible, and also either
scenario will be equally fun to diagnose.  So I really hope this turns
out to be a kernel bug.  ;o)

I have had a go at stage one of the suggested investigations
Installed clean FC3-i386 on Athlon64/G550. No yum updates.
No Screen corruption, Control-Alt-Fx OK
Down loaded xorg-x11-6.8.2-30.src.rpm and installed
edited spec file as suggested
rpmbuild -ba xorg-x11.spec
init 3
rpm -e --nodeps `rpm -qa|grep -i xorg-x11`
cd ....
rpm -i --nodeps *.rpm
init 5

The screen corruption is now there at Control-Alt-F7 !!!!!

Control-Alt-F1-6 terminals do not have a green border and are visable but
the characters are corrupt/incorrect/unreadable !!!!

Does this really indicate that the problem is with xorg-x11-6.8.2-30.src.rpm
rather than anything else ??

> Control-Alt-F1-6 terminals do not have a green border and are visable

I think you are mixing multiple bugs, multiple problems. This ticket is about
virtual consoles being lost completely as soon as X server starts up.

The original bug, reported by myself, includes both the
virtual terminal problem, the corrupt screen Control-Alt-F7
and the FC4T2 install problem.
My history of the problem is as follows:
1. FC4T1 only gave (me) the green border problem.

From memory I also did a yum update of xorg-x11 on FC4T1 to see if the green
border had been fixed and found the corrupt screen problem had been introduced.
 I thought I had done something wrong and reverted to the
"standard" FC4T1 xorg-x11. FC4T2 was due out very soon after this time and so
I waited.

2. FC4T2 additional gave (me) the corrupt screen during install and at
Control-Alt-F7

3. FC4T3 is still as per FCT2

Please see original bug report, Additional Comment #10 and attachment,
Additional Comments #16 and #23

There does seem to be confusion!
I hope that all the problems have been recognised !!!!
Please let me know if any additional information is required

So, somebody who prefers to stay anonymous mailed me privately with suggestions
for a work-around. I did not recompile anything without -O2, but I tried the
following:

Take /usr/X11R6/lib/modules/libvgahw.a from an up-to-date Fedora Core 3
(xorg-x11-6.8.2-something) and overwrite the file on Fedora Core 4 Test 3. With
that, the virtual consoles problem does not occur anymore (Matrox MGA G400). No
green border or green screen anywhere either.

Is this helpful?

Regarding comment 10 and comment 23 - the problem you describe seems to be on an
MGA 64 bit system. In comment 10 the problem seems similar to the screenshot
that you have regarding the intel 865G video card. I assume that these are
different machines and that the computer in comment 10 is a 32 bit box w/ the
Intel 865G video card.

If you are using two different boxes w/ different video cards and seeing the
same type of problem, are they both 64 bit installations or as I gathered in
assumption from the other comments?

My main concern is with the Intel 865G video, because I have an FC3 installation
that would be problematic if this bug is still present when FC4 is released.

Regarding comment #32, I can confirm replacing /usr/X11R6/lib/modules/libvgahw.a
with a copy from the latest xorg 6.8.2 from FC3 corrected the problem for me.

My video card is a S3/Savage. No more corrupted video upon altf1 through f6.

(In reply to comment #32)
> So, somebody who prefers to stay anonymous mailed me privately with suggestions
> for a work-around. I did not recompile anything without -O2, but I tried the
> following:
> 
> Take /usr/X11R6/lib/modules/libvgahw.a from an up-to-date Fedora Core 3
> (xorg-x11-6.8.2-something) and overwrite the file on Fedora Core 4 Test 3. With
> that, the virtual consoles problem does not occur anymore (Matrox MGA G400). No
> green border or green screen anywhere either.
> 
> Is this helpful?


Definitely a solid datapoint that's likely to be useful in finding a
solution. Perhaps vgahw miscompiles with gcc4 or something.

Thanks for the useful info Michael.

Tried 6.8.2-1.FC3.34 on FC4T3-i386 mg550 Athlon64
Corrupt at F7, kdm/kde
Corrupt at F1-6 but no green border
Reverted to 6.8.2-1.FC3.13.i368 to be able to use the machine

The bug is present in FC4 official release loaded on vanilla hardware with a
Matrox G200 video card. Switching to virtual terminals 1-6 shows blank screen
with green border. One can login blindly, so it's not related to vt functionality...

Same problem here (no green borders, just plain black). Intel 865GBF Motherboard.
(In reply to comment #37)
> The bug is present in FC4 official release loaded on vanilla hardware with a
> Matrox G200 video card. Switching to virtual terminals 1-6 shows blank screen
> with green border. One can login blindly, so it's not related to vt
functionality...

Sorry for the previous incomplete message. As I was saying...
Same problem here (no green borders, just plain black, VT's respond to commands).
Intel 865GBF Motherboard. I also have an Intel 865PERL that works ok.
But this information can be useful: in the first, buggy machine, doing logout
takes around 5/10 seconds (it remains the console), while in the good machine 
the logout is almost instantaneous.

And this is for Alan: your new i810_drv.o driver
(http://www.fairlite.demon.co.uk/i810_drv.o) gives me a black X too!

Sorry for the previous incomplete message. As I was saying...
Same problem here (no green borders, just plain black, VT's respond to commands).
Intel 865GBF Motherboard. I also have an Intel 865PERL that works ok.
But this information can be useful: in the first, buggy machine, doing logout
takes around 5/10 seconds (it remains the console), while in the good machine 
the logout is almost instantaneous.

And this is for Alan: your new i810_drv.o driver
(http://www.fairlite.demon.co.uk/i810_drv.o) gives me a black X too!

Created attachment 2909 [details] [review]
xorg-server-hw-xfree86-common-includes.patch

The computer has FC3 installed (where file came from), FC4 and a development
installation. The replaced file cured the messed up VTs on both the Dev and FC4
installation. The FC3 worked without noticable errors.

Say What!

The previous attached file is /usr/X11R6/lib/modules/libvgahw.a from FC3. Tagged
on the end of the filename is .fromfc3. The file should be owned by root:root
and not have the libvgahw.a name and replace the original file from FC4 or
development.
In order to get your terminals back or get rid of the borders or scrambled test,
a fresh boot might be needed to reset the video card to a sane condition.
The file is included only to simplify the task of extracting it from the rpm.

Doing a cmp either direction gives the same output. Checking same file against
itself shows no difference.

cmp  libvgahw.a  libvgahw.a.fromfc3
libvgahw.a libvgahw.a.fromfc3 differ: byte 28, line 2

cmp libvgahw.a.fromfc3 libvgahw.a
libvgahw.a.fromfc3 libvgahw.a differ: byte 28, line 2

 xorg-mess]$ cmp libvgahw.a.fromfc3 libvgahw.a.fromfc3
 xorg-mess]$ cmp  libvgahw.a  libvgahw.a
 xorg-mess]$

I still believe this ticket is specific to Matrox MGA chipsets, hence
"Driver/mga" was chosen at the top. Reports or details about other chipsets
ought to go somewhere else.

The driver for mga most likely has problems unique to its extreme reaction to
newer FC4 (and FC4Tx) versions. libvgahw.a is also a factor to consider, since
many different video drivers are broken, but made better when installing an
older version of libvgahw.a on the system.

Bug 3557 linking the library as an influencing factor is sufficient for me.
Though, extracting ideas from this bug repaired the damage caused by later
versions of X. Thanks for the extaction regarding libvgahw.a.

I have no MGA video card, dropping myself from CC (running linux yet)

Created attachment 2926 [details] [review]
change cairo_rectangle to use cairo_line_to instead of cairo_rel_line_to

I have Matrox G200 on VIA C3, and I am experiencing same problems with FC4 xorg
6.8.2.
Using mga video driver in Xorg yealds fine working X window system, however the

console has green border and I see nothing else there. No other possibility to
fix it than to reboot.

I tested with vesa driver. This has even worse behaviour. I have black console,

and X window does not start at all. Screen is black all the time. Computer
probably stops responding completely.
Vga driver is working, but is useless.

Some more datapoints:

Three boxes with problems:
1) mga g400 on FC4.
2) Intel 2845G/GL[Brookdale-G]/GE using i180 driver + i915 kernel driver from FC4.
3) Intel 915GM on Dell Latitude X1 laptop using i810 + i915 from snapshots dated
   20. june 2005 from http://dri.freedesktop.org/snapshots/ (the OS is FC4).

The mga host was blank with green lines on vt, while the intel chipset hosts
were completely blank on vt.

All hosts were fixed by replacing libvgahw.a from xorg-x11-6.8.2-1.FC3.13, the
bizarre trick from comment #32.

With Fedora Core 4 and a S3 Savege/IX-MV (ThinkPad T21), I'm getting not only
the display register corruptions, but also occasional crashes upon 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 solves all issues.

The libvgahw.a issue is covered, but not yet resolved, in RedHat bug 161242
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242) and its many
duplicates.

I had this problem (Green border around Blank VTs) with a G450 under FC4t3 and
then under FC4 release version. 

Replacing the libvgahw.a fixed the problem for me too.

Sounds like Mike is off the hook (unless he is responsible for libvgahw.a too...)

Thank you for your help Mike.

The root cause of this issue, is tracked in gcc bugzilla at:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278


Compiler developers are still debating wether or not this is a legitimate
gcc bug, or an X bug relying on behaviour some people consider invalid
by ISO C standard.

Until the debate is resolved, it might be a good idea to work around
the issue in the X code anyway.

I have discovered that running the command "modprobe i2c_matroxfb" (I'm using
FC4 and a Matrox G400) seems to fix the problem.  Either loading the module
manually or in /etc/rc.d/rc.local allows me to be able to see the text in the
virtual terminals 1--6 and X-Windows on terminal 7.  The only thing still
missing is when I shut down the computer there are no messages indicating
processeses being shut down, etc.

BTW my kernel is 2.6.11-1.1369_FC4smp; don't know if the smp makes a difference
or not.  I'm happy to provide more information if necessary.

I could verify on a G400 board that the root cause is PR 22278 in gcc.
Now gcc cvs has been fixed and for fedora users gcc-4.0.1-4 is available.
Hopefully a recompilation will fix most of the problems with other hardware as well.

NOTOURBUG ?
this has been sitting in my "unresolved issues" bin for too long 

(In reply to comment #48)
> NOTOURBUG ?
> this has been sitting in my "unresolved issues" bin for too long 

The gcc issue refered to above is indeed "not X.Org Foundation's bug", which
is I believe why this was closed as NOTOURBUG.

The problem with this bug report is that 200 people have added "me too" to
it, with their own information, even though everyone is definitely _not_
experiencing the _same_ bug/problem.

This is why there should be one single bug - per bug report, and one single
person on each bug report, unless it can be 300% concluded that multiple
people are experiencing the 100% _exact_ same bug.

Otherwise, a single bug report has 30-50 vague bugs in it from as many people,
all fairly vague, and the one bug report no longer takes on any particular
meaning. Also, when 300 people all pile into one bug report with "me too"
and are not having the _exact_ same bug, the bug grows lengthy and contains
tonnes of confusing information.  It becomes next to impossible to diagnose
the issue that the bug was originally filed about, due to the amount of
unrelated information added to the report by 30 other people, many of whom
are not actually having the same problem.

The other problem, is that if someone does actually manage to figure out
the problem that the original report was all about, and fix it, and then
close the bug as FIXED, the 300 other people who added "me too" to the
report who were NOT having the SAME bug, get pissed off and reopen the
report to say "NO THIS IS NOT FIXED YET!".

While _their_ problem might not be fixed, if it is determined the one
single issue that was _originally_ reported was fixed, then the bug will
be closed as such.

Recommendation:  When filing bug reports about X server or video driver
problems, problems VT switching, if you find a bug report that is similar
to what you are seeing, but not 10000% exact, then file a _new_ bug report
and your individual issue will be tracked _separately_.  Later, if developers
determine they are the same issue, a developer can close them as duplicates.

It is easier to track individual people's issues in individual separate
bug reports and close them as duplicates, or cross reference them with
URLs in comments, than it is to take one massive bug report with comments
from 30 people, all experiencing similar but not 100% identical issues, or
even totally unrelated issues.

After re-reading this whole report, the original issue that was reported here,
as far as I am concerned, was the problem which occured last year due to a
bug in gcc, which caused libvgahw.a to be miscompiled.  That definitely was
a bug in gcc, and not in X.Org, so the NOTOURBUG resolution is very accurate.
Having said that, that gcc bug was fixed eons ago, and updates released for
the distributions that were affected.

If anyone CC'd on this bug, or whom has added comments to this bug thinking
they were experiencing the same issue reported by Dr. John Austin, is
currently still experiencing the same problem they had when they added
a comment or added themselves to CC, pay close attention to this next
statement very carefully:

YOU ARE NOT EXPERIENCING THIS BUG.  YOU ARE HAVING A COMPLETELY UNRELATED
PROBLEM.  FILE YOUR OWN BUG REPORT INSTEAD OF PILING AN UNRELATED ISSUE
ONTO AN ALREADY RESOLVED ISSUE.

If I sound a bit short tempered, it is because it is frustrating as a
developer when people all tag onto one bug report when they're actually
not having the same problem - and then bitch and complain once the bug
they were not actually having gets closed.

Summary:  File your own bug report always, and include as much detail as
possible always.  Refer to other similar bugs with URLs in your report
if you think you are having the same or similar issue to someone else but
are not 100% sure.  A good way of determining wether or not you are 100%
sure, is to say out loud:  "If they had a gun to my (wife/girlfriend/child/
someone important)'s head and the trigger was going to be pulled 10 times
if my bug is not actually a duplicate, then I better file a separate
report."

That makes everyone happy in the end.
other's head, and were going to pull the trigger if 

Just to make things clear. I acidentaly resolved this bug as NOTOURBUG. I think
this is the right resolution but I certaimly didn't expect to have the
permission to do so when adding my previous comment.
For some unknown to me reason I appear to have permissions to edit all aspects
of any bug.  
My previous comment was meant as in inquiry to whether its not already time to
resolve this bug as NOTOURBUG, not as a questioning of the resolution.