Red Hat Bugzilla – Bug 64670
Rage128 2D Accel locks up X
Last modified: 2007-04-18 12:42:29 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-3 i686) Description of problem: R128 hangs intermittanly. X goes to max CPU usage, and requires -9 to kill. Typically happens when moving a long scrollbar, and includes some visual artifacts. The "Noaccel" option prevents the probem. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: Any program with a scrollbar can crash, but Napshare seems good at it: 1. Run Napshare 2. Search for a common word (like "the") 3. While the search results are filling, move the scrollbar. Any program with a scrollbar can crash, but so far have found Napshare best at reproducing, maybe just because the size of the scroll area is updating while scrolling. Actual Results: X locks up, goes to max CPU usage. Mouse still works, keyboard does not. Additional info: On annoyance of this type of bug is that console video modes are lost, and RedHat no longer includes sgvalib to help restore them. I think it would be a good idea for Linux VT's to be more knowledgeable about video modes and be able to restore modes without depending on X to put things back to text mode. The bug is partially fixed in the XFree86 CVS. I no longer see lockups, but still sometimes get the visual artifacts at scrollbars. Here's a bt at the time of hanging:(gdb) bt #0 0x420e1164 in ioctl () from /lib/i686/libc.so.6 #1 0x00000007 in ?? () #2 0x0838c6c0 in ?? () #3 0x084aec5f in ?? () #4 0x085537c8 in ?? () #5 0x08178aec in miSpriteInitialize () #6 0x080d33db in doImageText () #7 0x080d34f1 in ImageText () #8 0x080b6efe in ProcImageText8 () #9 0x080b31e4 in Dispatch () #10 0x080c432b in main () #11 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
Created attachment 56805 [details] Scrollbar artifact seen at time of hang. (Occasionally happens w/o hang)
Tried RedHat 7.3 on my system at work, and got similar lockups within 1 day of use. System is Intel with Radeon VE. Same backtrace, pointing to miSpriteInitialize. Kill -9 required to kill X. Restarting X gave errors about Radeon engine timeout/reset, with a backtrace leading to AddScreen: [0x084af44 address repeats, growing over time] #62 0x084af44c in ?? () #63 0x084af44c in ?? () #64 0x084b2106 in ?? () #65 0x084b699b in ?? () #66 0x080c4ab3 in AddScreen () #67 0x0806d15d in InitOutput () #68 0x080c4072 in main () Adding "Noaccel" option allows X to start successfully, but slow. I saved lspci -xxx -vvv in case a look at the register state helps. As with the Rage128, I have used a recent CVS from XFree86 on the Radeon system and had no lock-ups.
The kernel does have support for controlling the state of the video card and managing VT switching, saving and restoring. fbcon. To use it You need to read the Framebuffer-HOWTO and follow the instructions in there to set it up. Then use the X config file option "UseFBDev" as described in the XF86Config manpage. Can you attach your XFree86 log and config file from each problem case, and also the /var/log/messages file from the time of problem. Also, if you disable DRI does the problem persist?
I guess attaching the X log should have been an obvious thing to do. I'll do that now, from my Athlon/KT133/Rage128 system at home. In switching from my CVS XFree back to XFree 4.2, I forgot to switch the kernel module back, and found that 4.2 runs without crashing while using a newer r128.o module. And, of course, disabling DRI mkes it stable, too.
Created attachment 57246 [details] Log with lockup occuring on Athlon/Rage128 system
On person posting to Xpert suggested 24 bit modes are more stable, but I didn't find that to be true. Another user emailed me this info, which might help in reproducing the problem: Nah, I've been using 24-bit depth. X doesn't crash for the same things that you were talking about though. An example for how it crashes for me is if I have Evolution loaded, check my Inbox, and open the actions menu up top. Crashes half way through loading that menu, just about every time. Other weird things are when I logout of X, my current background gets set as like a texture for the gdm window. I can move the gdm window around and it acts like an eraser... Its kinda hard to explain.
Is this card an AGP card, or a PCI card? It appears to be AGP, but agpgart is not loading. If agpgart isn't loading it is possible your AGP chipset is not supported. In this case it is falling back to PCI DRI code, which is broken and not supported. Try booting with agp_unsupported=1 and checking to ensure agpgart loads. If the problem persists, disable DRI entirely, as PCI DRI code is unstable.
Closing bug due to lack of response, and being unable to reproduce the problem with currently supplied info. If the problem is still an issue for you that you would like fixed, please supply the additional information that has been requested and reopen the bug report. Thanks.
I am also experiencing this bug with an AGP Rage XPER 2000 with 32mb RAM. I not only experience it with scrolling but also resizing windows, and even typing a message in GAIM. bzflag reports its using AGP 1x.
I installed RH8.0, and my problem disappeared. Card: ATI AGP Rage XPERT 2000 with 32MB RAM Driver: Selected ATI Rage 128 at graphical installation. Regards Svein
I've had other people claim that Red Hat Linux 8.0 works for them as well that experienced acceleration lockups on 7.3. There will be an update of XFree86 for Red Hat Linux 7.3 at some point, which will be the same codebase as that of Red Hat Linux 8.0, but there is no timeline for that. Since the issue is reported fixed in 8.0, and it works fine for me as above, I think we can consider this one fixed now. Thanks for the feedback guys.
Rather odd as I experienced the problem in RH8 (only version of redhat I've used). I upgraded X to 4.2.99 from Phoebe and it hasn't locked since.