Bug 62171 - ATI Radeon (all) lockup/corruption when VT switching
Summary: ATI Radeon (all) lockup/corruption when VT switching
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 65867 (view as bug list)
Depends On:
Blocks: 61901 67218
TreeView+ depends on / blocked
Reported: 2002-03-28 04:29 UTC by Jay Berkenbilt
Modified: 2007-04-18 16:41 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-26 12:19:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
full X server startup (23.66 KB, text/plain)
2002-03-28 04:30 UTC, Jay Berkenbilt
no flags Details
XF86Config-4 file (3.72 KB, text/plain)
2002-03-28 16:24 UTC, Jay Berkenbilt
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:066 high SHIPPED_LIVE : Updated XFree86 packages provide security and bug fixes 2003-06-25 04:00:00 UTC

Description Jay Berkenbilt 2002-03-28 04:29:02 UTC
Description of Problem:Note: although I am using XFree86 4.2.0 as supplied with
this RedHat
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:

Section "Module"
#        Load  "GLcore"
        Load  "dbe"
        Load  "extmod"
	Load "fbdevhw"
	Load "dri"
#        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"

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):


How Reproducible:


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)

Actual Results:

Display is damaged and locked up if GLX is loaded; functions fine if GLX is not
loaded (though, of course, GLX is not available).

Expected Results:

Should function correctly with or without GLX!

Additional Information:
I have reported this to XFree86 including additional information such as full
server output.

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:

class: VIDEO
bus: PCI
detached: 0
driver: Card:ATI Radeon Mobility M6
desc: "ATI|Radeon Mobility M6 LY"
vendorId: 1002
deviceId: 4c59
subVendorId: 103c
subDeviceId: 001a
pciType: 1

I will attach /var/log/XFree86.0.log

Comment 1 Jay Berkenbilt 2002-03-28 04:30:05 UTC
Created attachment 51065 [details]
full X server startup

Comment 2 Mike A. Harris 2002-03-28 08:01:04 UTC
Can you attach your config file as well please?  Thanks.

Comment 3 Jay Berkenbilt 2002-03-28 16:24:20 UTC
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.

Comment 4 Jay Berkenbilt 2002-03-28 16:24:58 UTC
Created attachment 51191 [details]
XF86Config-4 file

Comment 5 Simon Matter 2002-04-11 08:18:37 UTC
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.

Comment 6 Jay Berkenbilt 2002-04-12 23:43:09 UTC
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.

Comment 7 Eric Doutreleau 2002-05-21 10:24:40 UTC
I have the problem too with redhat 7.3 on a gx240 desktop.

Comment 8 Jay Berkenbilt 2002-06-05 15:03:46 UTC
This problem is still present in RedHat 7.3, so I'm changing the product and

Comment 9 Nick Read 2002-06-18 02:36:02 UTC
This same problem occurs with ATI Rage 128 cards

Comment 10 Ronan Waide 2002-07-03 19:25:21 UTC
Adding to the list of "Me Too"...

Compaq Evo N600, ATI Radeon driver for ATI Mobility M6, details:
class: VIDEO
bus: PCI
detached: 0
driver: Card:ATI Radeon Mobility M6
desc: "ATI|Radeon Mobility M6 LY"
vendorId: 1002
deviceId: 4c59
subVendorId: 0e11
subDeviceId: b111
pciType: 1

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 ?? ()
(gdb) cont

Program received signal SIGINT, Interrupt.
0x40133c44 in ?? ()
(gdb) where
#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 ?? ()

Comment 11 Michael Hipp 2002-07-06 18:45:22 UTC
Mee too. Dell Dimension 4300S ATI Rage 128 Ultra 32M.

Not to complain, but are we going to see any action on this?

Comment 12 Paul Kronenwetter 2002-07-11 18:37:58 UTC
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.

Comment 13 Mike A. Harris 2002-07-26 11:28:52 UTC
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.

Comment 14 Michael Hipp 2002-07-26 11:35:35 UTC
Care to provide us with a bug number for filing Rage 128 reports?

Comment 15 Mike A. Harris 2002-07-26 11:40:53 UTC
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.

Comment 16 Mike A. Harris 2002-07-26 11:41:55 UTC
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.

Comment 17 Mike A. Harris 2002-07-26 11:51:11 UTC
I just stumbled upon a Rage 128 report for this:


Comment 18 Mike A. Harris 2002-07-26 11:58:24 UTC
*** Bug 65330 has been marked as a duplicate of this bug. ***

Comment 19 Mike A. Harris 2002-07-26 12:04:48 UTC
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.

Comment 20 Mike A. Harris 2002-07-26 12:18:04 UTC
*** Bug 65867 has been marked as a duplicate of this bug. ***

Comment 21 Mike A. Harris 2002-07-26 14:25:13 UTC
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
VTswitch lockup:


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

Comment 22 Mike A. Harris 2002-07-26 14:52:29 UTC
Another 5-10 people report this as fixed now.

Comment 23 Mark J. Cox 2003-06-25 15:52:33 UTC
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.


Comment 24 Jay Berkenbilt 2003-09-04 14:50:39 UTC
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.

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