Bug 64670 – Rage128 2D Accel locks up X

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 64670 - Rage128 2D Accel locks up X

Summary:	Rage128 2D Accel locks up X

Status:	CLOSED WORKSFORME

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	XFree86 (Show other bugs)
Sub Component:
Version:	7.3
Hardware:	i386 Linux

Priority	medium Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Mike A. Harris
QA Contact:	David Lawrence
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2002-05-09 08:26 EDT by Joe Krahn
Modified:	2007-04-18 12:42 EDT (History)
CC List:	4 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2002-08-11 22:24:23 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Scrollbar artifact seen at time of hang. (Occasionally happens w/o hang) (1.24 KB, image/png) 2002-05-09 08:29 EDT, Joe Krahn	no flags	Details
Log with lockup occuring on Athlon/Rage128 system (29.01 KB, text/plain) 2002-05-14 08:36 EDT, Joe Krahn	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Joe Krahn 2002-05-09 08:26:18 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

Comment 1 Joe Krahn 2002-05-09 08:29:42 EDT

Created attachment 56805 [details]
Scrollbar artifact seen at time of hang. (Occasionally happens w/o hang)

Comment 2 Joe Krahn 2002-05-09 17:50:32 EDT

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.

Comment 3 Mike A. Harris 2002-05-13 14:40:32 EDT

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?

Comment 4 Joe Krahn 2002-05-14 08:33:58 EDT

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.

Comment 5 Joe Krahn 2002-05-14 08:36:24 EDT

Created attachment 57246 [details]
Log with lockup occuring on Athlon/Rage128 system

Comment 6 Joe Krahn 2002-05-15 11:44:19 EDT

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.

Comment 7 Mike A. Harris 2002-08-11 22:24:19 EDT

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.

Comment 8 Mike A. Harris 2002-09-05 16:14:13 EDT

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.

Comment 9 Owen Stampflee 2003-02-10 15:47:32 EST

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.

Comment 10 Need Real Name 2003-02-12 12:08:07 EST

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

Comment 11 Mike A. Harris 2003-02-12 14:18:52 EST

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.

Comment 12 Owen Stampflee 2003-02-12 15:12:49 EST

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.

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