Bug 65373 - r128 doesn't do direct rendering on ATI Rage Fury
Summary: r128 doesn't do direct rendering on ATI Rage Fury
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-22 20:20 UTC by Satish Balay
Modified: 2008-08-01 16:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config-4 (3.69 KB, text/plain)
2002-05-22 22:05 UTC, Satish Balay
no flags Details
XFree86.0.log (50.13 KB, text/plain)
2002-05-22 22:06 UTC, Satish Balay
no flags Details
/var/log/messages (14.83 KB, text/plain)
2002-05-29 20:38 UTC, Satish Balay
no flags Details

Description Satish Balay 2002-05-22 20:20:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
It appears that there is an error when loading the r128 driver for ATI Rage fury
card - this causes direct rendering to be disabled.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install redhat 7.3 on a desktop with ATI Rage Fury 32MB (with TV out) AGP card.

Additional info:

# glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: No

From XFree86.0.log 
(==) R128(0): Write-combining range (0xe0000000,0x2000000)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
[drm] failed to load kernel module "r128"
(II) R128(0): [drm] drmOpen failed
(EE) R128(0): [dri] DRIScreenInit failed.  Disabling DRI.
(II) R128(0): Memory manager initialized to (0,0) (1280,8191)
(II) R128(0): Reserved area from (0,1024) to (1280,1026)
(II) R128(0): Largest offscreen area available: 1280 x 7165
(==) R128(0): Backing store disabled
(==) R128(0): Silken mouse enabled
(II) R128(0): Using XFree86 Acceleration Architecture (XAA)
        Screen to screen bit blits
        Solid filled rectangles
        8x8 mono pattern filled rectangles
        Indirect CPU to Screen color expansion
        Solid Lines
        Dashed Lines
        Scanline Image Writes
        Offscreen Pixmaps
        Setting up tile and stipple cache:
                32 128x128 slots
                32 256x256 slots
                16 512x512 slots
(II) R128(0): Acceleration enabled
(II) R128(0): Using hardware cursor (scanline 2052)
(II) R128(0): Largest offscreen area available: 1280 x 7163
(**) Option "dpms"
(**) R128(0): DPMS enabled
(II) R128(0): Direct rendering disabled

# ls /dev/dri/
card1  card2  card3

Comment 1 Mike A. Harris 2002-05-22 21:53:29 UTC
Please attach your full log file and config file to the report using the
link below.

Is this Rage Fury, or is it Rage Fury Maxx?

Comment 2 Mike A. Harris 2002-05-22 21:54:58 UTC
Also, please attach the output of: uname -a

Comment 3 Satish Balay 2002-05-22 22:01:38 UTC
The video card is Rage Fury  - not Rage Fury Maxx

uname -a:
Linux dreamcast 2.4.18-4 #1 Thu May 2 18:10:25 EDT 2002 i686 unknown

Machine info: AMD-K7(tm) Processor 700MHz

Comment 4 Satish Balay 2002-05-22 22:05:22 UTC
Created attachment 58249 [details]

Comment 5 Satish Balay 2002-05-22 22:06:06 UTC
Created attachment 58250 [details]

Comment 6 Mike A. Harris 2002-05-27 16:28:58 UTC
Are you using the supplied Red Hat kernel, or a custom built one?  The DRM
kernel modules are not loading for some reason.  Please attach your
/var/log/messages file for further troubleshooting.

Comment 7 Satish Balay 2002-05-29 20:37:22 UTC
I'm using the redhat supplied kernel - obtained from updates from a mirror.

Comment 8 Satish Balay 2002-05-29 20:38:02 UTC
Created attachment 58884 [details]

Comment 9 Mike A. Harris 2002-06-05 05:07:16 UTC
What does the following command report:

rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' |grep kernel

This is very weird.  Your DRM modules aren't loading, which makes
me wonder if they're actually there or not.

Comment 10 Satish Balay 2002-06-05 16:34:58 UTC
[balay@dreamcast balay]$ rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n'
|grep kernel
[balay@dreamcast balay]$ uname -a
Linux dreamcast.mcs.anl.gov 2.4.18-4 #1 Thu May 2 18:10:25 EDT 2002 i686 unknown

Comment 11 Mike A. Harris 2002-06-05 23:12:03 UTC
Ok, I know what the problem is now.  Just as I feared...

A reasonable amount of time prior to our release, I discovered this
problem on my own K6 machine.  I discovered that our i386 kernels do
not contain DRM modules.  I do not remember the specifics, but I do
recall that DRM uses instructions that are only present on i586 and
higher CPU's.

I believe that we could have shipped DRM on i386 kernels, but it would
only work on i586 or higher CPU's, and the kernel would detect at runtime
safely if the machine was capable of running cmpxchg8 or whatever and
act accordingly.  I could be a bit off, but that is close.

As such, in order to ensure that users running Intel Pentium, AMD K5,
K6, K6-2, K6-3, and some Cyrix processors can use DRI, I wanted all of
our kernels to have DRM in it, or that anaconda, by default, as well
as up2date, would default to installing DRM enabled kernels on all systems
that can reasonably run DRM, and for which users would expect working DRM
out of the box.  I knew if it did not work, that I would be the one
receiving "DRI doesn't work" bug reports, and I wanted to both ensure
users got what they expected, and at the same time minimize needless
incoming bug reports that DRI doesn't work.

Out of all of the solutions proposed, I personally favoured adding
a uniprocessor i586 kernel for these systems (and I still feel that
this is the most technically correct and acceptable solution with the
least amount of potential for problems).  We currently only ship
an SMP kernel for i586.

I was under the understanding we would add the i586 UP kernel, or
rig anaconda to choose the best kernel, and one that supports DRM
so that this would work out of the box.  It appears that neither
solution happened, and now all users not using Athlon or Pentium II
or higher machines end up with no DRI, as do people who select
the i386 kernel manually.

Since this isn't an XFree86 problem, I'm reassigning the bug to the
kernel for now since IMHO the problem is a kernel problem.  I'd like
to see our errata kernel come with an i586 UP kernel, and our future
products ship with one as well.  There may be some other solution
possible also, but it isn't something that I can resolve in XFree86
short of including a kernel in XFree86 packaging.  ;o)

I don't know how this will be fixed, but IMHO if we don't fix it, then
our users are the ones who get burned, and I am the one who will get
their bug reports.  I suppose I could add to XFree86:

Conflicts: kernel = %arch(i386)


Comment 12 Satish Balay 2002-06-06 03:36:37 UTC
I noticed that RH-7.3 have i686 & 'athlon' versions of kernels. My machine is
Athlon 700. Couldn't the installer have chosen one of these?

Comment 13 Arjan van de Ven 2002-06-06 07:38:23 UTC
If you have an athlon, the installer will have chosen the athlon kernel.

Comment 14 Satish Balay 2002-06-06 17:58:14 UTC
I've installed the athlon version of the kernel and now DRI works

Comment 15 Bugzilla owner 2004-09-30 15:39:37 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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