Description of Problem:Note: although I am using XFree86 4.2.0 as supplied with
beta release, I have verified with other users that they experience
this problem with the binary XFree86 distribution downloaded from
Here is the "Module" section from my XF86Config-4 file:
# Load "GLcore"
# Load "glx"
With this configuration, everything works fine though I (of course) do
not get the GLX extension. If I include glx and GLcore, then although
X starts up and the GLX extension appears to be present, if I switch
virtual consoles away from X and back to X, the display becomes
unusable. Specifically, moving the mouse results in moving the
pointer, but the display is otherwise non-functional including
selection of text with the mouse. The X server will not die easily.
Killing it with kill -9 does not restore the display. Using kbd_mode
or chvt has no effect. The only I can figure out so far to get the
display back is to reboot the machine.
To be a bit more specific, without GLX loaded, if you switch VC's away
from X and back to X, you see the display with some damage (most
windows not fully refreshed, and some noise on the display) for one to
two seconds, after which the display is restored to its previous state
and becomes fully usable. With GLX loaded, the initial appearance is
identical but the display does not ever return to usability.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start X server and client such as xterm
2. CTRL-ALT-F1 to switch to another virtual console
3. CTRL-ALT-Fn to switch back (F7 using default configuration)
Display is damaged and locked up if GLX is loaded; functions fine if GLX is not
loaded (though, of course, GLX is not available).
Should function correctly with or without GLX!
I have reported this to XFree86 including additional information such as full
My hardware is an HP Omnibook 6100 laptop. I have verified that other users of
this laptop have this problem as well with other distributions and with X as
downloaded directly from XFree86.
Here's the report on the video card from /etc/sysconfig/hwconf:
driver: Card:ATI Radeon Mobility M6
desc: "ATI|Radeon Mobility M6 LY"
I will attach /var/log/XFree86.0.log
Created attachment 51065 [details]
full X server startup
Can you attach your config file as well please? Thanks.
I'm attaching my XF86Config-4 file as requested. This is identical to the one
anaconda created except the two commented out lines in the "Module" section, the
addition of the "speedo" module, and the addition of the DontZap server option.
Created attachment 51191 [details]
Seems I have the same problem here on a DELL GX240 with "ATI Radeon VE QY
(AGP)". I can switch from X to console, but when I switch back to X, it hangs.
Unfortunately I don't have this computer available to make more test. The only
thing I can say is that it does not happen with RH 7.2.
This bug is still present in XFree86-4.2.0-6.62. I mention this only because
the changelog for the rpm mentions various Radeon fixes were included including
VT switch (though I don't know what that refers to). Since this particular
radeon bug has not been fixed, I figured it would be worth confirming that it is
still there.... At least, the bug still happens with my Omnibook 6100, the
information about which already appears in this report.
I have the problem too with redhat 7.3 on a gx240 desktop.
This problem is still present in RedHat 7.3, so I'm changing the product and
This same problem occurs with ATI Rage 128 cards
Adding to the list of "Me Too"...
Compaq Evo N600, ATI Radeon driver for ATI Mobility M6, details:
driver: Card:ATI Radeon Mobility M6
desc: "ATI|Radeon Mobility M6 LY"
I get a complete display freeze if I switch to a VT from the xdm login screen.
No mouse, no keyboard.
Here's a backtrace in gdb-xfree86; note that it appears to be stuck at 0x40133c44.
[root@localhost root]# ps -ef | grep X
root 1227 1 0 20:09 ? 00:00:00 /usr/X11R6/bin/xdm -nodaemon
root 1238 1227 13 20:09 ? 00:01:06 /usr/X11R6/bin/X -auth /etc/X11/
root 1384 1341 0 20:17 pts/0 00:00:00 grep X
[root@localhost root]# gdb
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
(gdb) attach 1238
Attaching to process 1238
0x40133c44 in ?? ()
Program received signal SIGINT, Interrupt.
0x40133c44 in ?? ()
#0 0x40133c44 in ?? ()
#1 0x083aab90 in ?? ()
#2 0x084afe2f in ?? ()
#3 0x08576103 in ?? ()
#4 0x08176543 in ?? ()
#5 0x08169115 in ?? ()
#6 0x080a7b96 in ?? ()
#7 0x08482532 in ?? ()
#8 0x08162259 in ?? ()
#9 0x080821da in ?? ()
#10 0x085548c4 in ?? ()
#11 0x080807ca in ?? ()
#12 0x0808031e in ?? ()
#13 0x080b997c in ?? ()
#14 0x080d4cfa in ?? ()
#15 0x080b3124 in ?? ()
#16 0x080c432b in ?? ()
#17 0x400751c4 in ?? ()
Mee too. Dell Dimension 4300S ATI Rage 128 Ultra 32M.
Not to complain, but are we going to see any action on this?
Sorry - Me too.
ATI Technologies Inc Rage Mobility M4 AGP
Reverted back to Redhat 7.2 XFree-86 binaries and it doesn't present the
corruption and/or lock-ups. Although, I haven't checked the 3D stuff yet.
For all of the me too's above which are Rage 128 or Rage Mobility M3/M4
please file separate bug reports or add info to any existing Rage 128 reports
that mirror your symptoms.
While the problem may be identical to the Radeon problem above, the
radeon and r128 drivers are completely separate, and once the radeon
problem is resolved and the bug closed, it wont fix any similar problem
on r128 hardware. Separate drivers/issues.
Care to provide us with a bug number for filing Rage 128 reports?
Just an update on the VTswitch problem... This problem is something
new that occured in the XFree86 4.2.0 codebase which has been reported
by users on almost all Radeon hardware. The problem is not specific
to Red Hat Linux, it occurs on all shipping versions of 4.2.0 from
The problem also does not occur on *all* systems. It only occurs on
some people's systems. Trying to find out the common link between
everyone experiencing the problem has eluded many developers for 6+
months so far.
Most developers whom have looked into this issue are unable to reproduce
it on the hardware they have apparently which makes it even more complex
to find a solution. The problem is widespread however, and is reported
to me at least 5-10 times a week by a new user via bugzilla, email, or
in IRC on irc.openprojects.net #xfree86.
A couple of people working on DRI recently have dug deeper into this
issue and have produced a patch which allegedly solves the problem for
them. I am going to apply this patch to rawhide XFree86 4.2.0-56 for
testing by everyone experiencing this problem.
One thing that would be useful, is if everyone who can reproduce this
problem can provide the following information:
1) Start up X
2) Open up a terminal with a root shell
3) Save the output of "lspci -vvn" into a text file "lspci-before.txt"
4) Switch VT's to the console and log in as root
5) Save the output of "lspci -vvn" into a text file "lspci-after.txt"
6) Attach both lspci text files as file attachments to this bug report
by using the bugzilla file attachment feature below. Please do not
cut and paste them - use file attachment.
This will provide us with a much greater wealth of detail to corelate
the problem with.
Again, this is *ONLY* for people with ATI Radeon hardware, not Rage128
or any other hardware. Any Radeon or Radeon Mobility is fine.
I don't have a bug number for R128 reports or I would have provided it.
Use bugzilla's query feature to look for a similar report.
I just stumbled upon a Rage 128 report for this:
*** Bug 65330 has been marked as a duplicate of this bug. ***
Please test XFree86 4.2.0-56 in rawhide. You can use the current
Red Hat Linux (Limbo) beta or some other mechanism.
Please still provide the above requested information, lspci stuff, etc.
*** Bug 65867 has been marked as a duplicate of this bug. ***
Good news folks.... <drumroll>
The bugfix test has so far turned up to be successful. I have
put a new Radeon driver at the following URL which fixes this
I've had 5 users respond that they can VTswitch like a wild animal
with the above driver, and it is rock solid.
Just copy this driver over top of the existing
/usr/X11R6/lib/modules/drivers/radeon_drv.o on your system, and
restart X. Please report back here your success/failure.
Closing as fixed in rawhide 4.2.0-56
Another 5-10 people report this as fixed now.
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.
FWIW, even with Severn, I still have this problem. My experience with laptops
is that Linux supports older laptops very poorly. I've owned three laptops.
Suspend worked well on all of them with the current kernel shortly after they
were purchased. Then, over time, features stopped working even though they
continued to work right under Windows. I've more or less resigned myself to the
fact that APM/ACPI support in Linux is weak, most likely due largely to
non-compliant hardware, lack of documentation, etc., and that I just have to let
go of this type of issue.
So, in summary, I can switch VTs all I want, but I still can't come out of
suspend and have things work with DRI enabled. I'll leave this closed, but I've
added these comments for the benefit of anyone who may do a search and find this
bug so they'll know that the problem as specific to an HP Omnibook 6100 was
never actually fixed.