Hide Forgot
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: Always 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 #
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?
Also, please attach the output of: uname -a
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
Created attachment 58249 [details] XF86Config-4
Created attachment 58250 [details] XFree86.0.log
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.
I'm using the redhat supplied kernel - obtained from updates from a mirror.
Created attachment 58884 [details] /var/log/messages
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.
[balay@dreamcast balay]$ rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' |grep kernel kernel-2.4.18-4.i386 [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
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) ;o)
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?
If you have an athlon, the installer will have chosen the athlon kernel.
I've installed the athlon version of the kernel and now DRI works
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 persists. 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/