Bug 186238 - DRI doesn't work on R250 with X7.1/FC6
Summary: DRI doesn't work on R250 with X7.1/FC6
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-22 14:27 UTC by Luke Hutchison
Modified: 2015-01-04 22:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-24 05:11:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of dmesg (18.23 KB, text/plain)
2006-03-25 06:31 UTC, Luke Hutchison
no flags Details
output of lspci -n (591 bytes, text/plain)
2006-03-25 06:33 UTC, Luke Hutchison
no flags Details
output of lspci (without the -n option) (1.62 KB, text/plain)
2006-03-25 06:35 UTC, Luke Hutchison
no flags Details

Description Luke Hutchison 2006-03-22 14:27:30 UTC
Description of problem:
DRM/DRI doesn't seem to work on my Radeon AIW9000 (R250) under FC5.  It stopped
working late in the FC5-development series of kernels.

# dmesg | grep drm

[drm] Initialized drm 1.0.1 20051102
[drm] Initialized radeon 1.22.0 20051229 on minor 0
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:drm_unlock] *ERROR* Process 2081 using kernel context 0
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:drm_unlock] *ERROR* Process 2794 using kernel context 0
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:drm_unlock] *ERROR* Process 3211 using kernel context 0

# dmesg | grep agp

Linux agpgart interface v0.101 (c) Dave Jones

# grep "Direct rendering" /var/log/Xorg.0.log

(WW) RADEON(0): Direct rendering disabled

# grep agp /var/log/Xorg.0.log

(WW) RADEON(0): [agp] AGP not available
(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
(II) RADEON(0): [agp] You may want to make sure the agpgart kernel module

# grep drm /var/log/Xorg.0.log

(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/lib/xorg/modules/linux/libdrm.so
(II) Module drm: vendor="X.Org Foundation"
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: drmOpenMinor returns 6
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf8a49000
(II) RADEON(0): [drm] mapped SAREA 0xf8a49000 to 0xb7fe5000
(II) RADEON(0): [drm] framebuffer handle = 0xe4000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf8a49000 at 0xb7fe5000

I checked the .config file in kernel-devel and it appears that AGP is compiled
directly into the kernel (not as a module).

Is there any other info I can provide that would help diagnose the problem?

Comment 1 Dave Jones 2006-03-24 23:15:06 UTC
ok, this probably broke as a result of the patch to deliberatly cripple the
radeon driver on chips that were known to be broken.   From the sounds of things
this driver was working for you until this change, so maybe we chopped a bit too
much.

Can you attach the output of lspci -n please, and also a full dmesg.


Comment 2 Luke Hutchison 2006-03-25 06:31:28 UTC
Created attachment 126700 [details]
output of dmesg

Comment 3 Luke Hutchison 2006-03-25 06:33:53 UTC
Created attachment 126701 [details]
output of lspci -n

Comment 4 Luke Hutchison 2006-03-25 06:35:08 UTC
Created attachment 126702 [details]
output of lspci (without the -n option)

Comment 5 Luke Hutchison 2006-03-25 06:39:05 UTC
I haven't really done a lot with 3D on my computer until just recently, so I
can't confirm that DRM was enabled before, but I didn't get the error messages
above until recently, and DRM is definitely disabled now.

It is my understanding that the R250 is a heavily modded R200, but that it is
pretty well understood?


Comment 6 Luke Hutchison 2006-07-11 05:30:05 UTC
Is there some way to manually override the disabling of DRI?  I would really
like to test this so I can provide feedback as to whether or not this is
actually broken on the R250 or not.


Comment 7 Mike A. Harris 2006-07-11 17:16:08 UTC
(In reply to comment #6)
> Is there some way to manually override the disabling of DRI?  I would really
> like to test this so I can provide feedback as to whether or not this is
> actually broken on the R250 or not.

For hardware which is supported by the DRI, it is automatically enabled
by default on all supported hardware.  In X.Org 7.0, DRI support for
R300 and newer hardware is not marked "stable" and so it is not built
by default upstream, nor in Fedora Core.  To be clear, this is refering
specifically to the R300 DRI 3D driver that ships with Mesa, which is
loaded by libGL.  Our kernel had the PCI IDs of the R300 hardware patched
out at compile time, so the driver does not recognize the R300 and newer
chips.  Therefore, there is no way at runtime to tell the kernel to enable
the R300 and newer PCI IDs.  The only way, is to recompile the kernel with
the R300 and newer IDs re-enabled.

Your hardware is R250 however, which is not affected by R300 support
on the X/Mesa side of things at all.

Dave suggested above that it was possible perhaps that too many PCI IDs
were trimmed fromt he kernel module.  If that is the case, then the only
way to fix it is to recompile the kernel with the IDs added back.

Having said that, we'll soon be shipping Xorg 7.1 as an update to FC5,
and R300 DRI support will be enabled I believe.  The kernel will need to
be updated again to re-enable the R300 drm module support.



Comment 8 Luke Hutchison 2006-07-11 17:44:08 UTC
Thanks for the informative reply, Mike.  I infer from your reply that when R300
support is added back in, the chopped PCI ids (including R250) will likely be
re-enabled?

Currently I get an error message like the following if I run a GLX program:

$ ./main
freeglut (./main): Unable to create direct context rendering for window 'main'
This may hurt performance.

Would you please be able to verify whether the PCI id has in fact been removed,
in order to eliminate the possibility of some other problem?:

$ lspci -v
01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000]
(Secondary) (rev 01)
        Subsystem: ATI Technologies Inc Unknown device 4f73
        Flags: stepping, 66MHz, medium devsel
        Memory at e8000000 (32-bit, prefetchable) [disabled] [size=64M]
        Memory at ec020000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: <access denied>

$ lspci -v -n
01:00.1 0380: 1002:496e (rev 01)
        Subsystem: 1002:4f73
        Flags: stepping, 66MHz, medium devsel
        Memory at e8000000 (32-bit, prefetchable) [disabled] [size=64M]
        Memory at ec020000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: <access denied>

Thanks!

Comment 9 Luke Hutchison 2006-08-25 04:29:38 UTC
I just tried with kernel and X11r7.1 RPMs from the FC6-development repository,
including the following, and the problem still exists:

kernel-2.6.17-1.2583.fc6
libX11-1.0.3-2.fc6
xorg-x11-drv-ati-6.6.1-10.fc6



Comment 10 Luke Hutchison 2006-08-25 04:31:49 UTC
Updating another field, sorry for the Bugzilla spam

Comment 11 Luke Hutchison 2006-09-07 19:33:30 UTC
I volunteer to test out RV250 support for inclusion in FC6, if someone can point
me in the right direction so that I can re-enable the PCI ID.  (I don't know
where to begin looking in the kernel and/or Xorg.)  I am fine with re-compiling
the kernel etc.

Comment 12 Steve 2006-09-21 03:47:24 UTC
works for me .. i have custom config and compiled my own kernel though

[Steve@steve ~]$ dmesg | grep drm
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized radeon 1.25.0 20060524 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading R300 Microcode
[drm] writeback test succeeded in 1 usecs

[Steve@steve ~]$ grep "Direct rendering" /var/log/Xorg.0.log
        *** Direct rendering support is highly experimental for Radeon 9500
(II) RADEON(0): Direct rendering enabled

.. but needs some improvement or something, .. 3d slow / unresponsive on unreal.
I'll see what FC6 final does.

for some reason FC5 kernels don't load DRI for me, thats fine, i compile my own
kernels anyway for more efficiency and customized for my computer
but DRI should load in fedora kernel because it is supposed to be compiled as a
module

Comment 13 Luke Hutchison 2006-09-21 04:55:34 UTC
Actually you have an R300 and I have an R250.  It is unlikely that they are
treated identically by most of the code in X and the kernel.

I will try FC6test3 soonish on here to see if anything is different in X7.1.


Comment 14 Luke Hutchison 2006-09-24 05:09:54 UTC
Great, I installed FC6test3 and I can confirm this is indeed fixed in that release.

# dmesg | grep drm
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized radeon 1.25.0 20060524 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading R200 Microcode
[drm] writeback test succeeded in 1 usecs

Thanks to all the engineers for their great work, FC6 is looking really great.




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