Hide Forgot
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 xfree86.org. 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" EndSection 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): 4.2.0 How Reproducible: 100% 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
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] XF86Config-4 file
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 version.
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: 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 Continuing. 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 ?? ()
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 everywhere. 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: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65136
*** 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 VTswitch lockup: ftp://people.redhat.com/mharris/test-drivers/radeon-4.2.0-vtswitch-hang/radeon_drv.o 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. http://rhn.redhat.com/errata/RHSA-2003-066.html
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.