Bug 103936 - xfree86 4.3 dri not working on radeon 7000
xfree86 4.3 dri not working on radeon 7000
Status: CLOSED DUPLICATE of bug 104338
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: XFree86 (Show other bugs)
3.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-07 20:40 EDT by jahshaka
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:58:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree86.0.log (44.97 KB, text/plain)
2003-09-10 04:01 EDT, jahshaka
no flags Details
XFree86.1.log - redhat kernel (42.34 KB, text/plain)
2003-09-10 04:05 EDT, jahshaka
no flags Details
latest messages logfile (76.23 KB, text/plain)
2003-09-22 13:21 EDT, jahshaka
no flags Details
latest xfree logfile (45.34 KB, text/plain)
2003-09-22 13:21 EDT, jahshaka
no flags Details

  None (edit)
Description jahshaka 2003-09-07 20:40:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ia64; en-US; rv:1.4) Gecko/20030902

Description of problem:
Dri support for the radeon is not working in XFree86 4.3 I have tried everything
and scoured the web for info on setting up DRI. Since i am unable to compile m,y
kernel the only thing i havent tried is doing that...

>>Heres the section of my XFree86.0.log

(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:128:0:0"
(II) RADEON(0): [drm] added 65536 byte SAREA at 0xa00000000049c000
(II) RADEON(0): [drm] mapped SAREA 0xa00000000049c000 to 0x2000000006a00000
(II) RADEON(0): [drm] drmAddMap failed
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(II) RADEON(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) RADEON(0): Acceleration enabled
(==) RADEON(0): Backing store disabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using hardware cursor (scanline 1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7158
(**) Option "dpms"
(**) RADEON(0): DPMS enabled
(II) RADEON(0): Direct rendering disabled
(==) RandR enabled

>>output from dmesg

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 9945M
agpgart: Detected HP ZX1 AGP chipset at 80:1e.0
agpgart: HP ZX1 IOC: IOPDIR shared with sba_iommu
agpgart: AGP aperture is 512M @ 0x60000000
[drm] AGP 0.99 Aperture @ 0x60000000 512MB
[drm] Initialized radeon 1.7.0 20020828 on minor 0


Version-Release number of selected component (if applicable):
XFree86-4.3.0-16.EL

How reproducible:
Always

Steps to Reproduce:
1. Start x
2. check log file
3.
    

Actual Results:  everything works ok but there is no DRI support and so x is
real slow and there is no opengl acceleration

Additional info:
Comment 1 jahshaka 2003-09-09 02:53:38 EDT
Apparently the main problem is here
(XFree86 log file)

drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
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 result is -1, (No such device)
drmOpenDevice: Open failed
[drm] failed to load kernel module "radeon"
(II) RADEON(0): [drm] drmOpen failed
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
Comment 2 jahshaka 2003-09-09 02:55:16 EDT
as a note, i have rebuilt my kernel from the source rpm and built xfree86 4.3
and tried their driver  and i cant seem to get around the dri issue here...

Comment 3 Mike A. Harris 2003-09-09 03:42:21 EDT
Please reproduce this with the Red Hat kernel binaries, and attach your
X server log, config file and /var/log/messages booted into the Red Hat
built kernel using Red Hat built XFree86.  We do not support user recompiled
binaries.

If the problem can be reproduced using our binaries, I can investigate
this problem deeper with you.

Thanks in advance.
Comment 4 jahshaka 2003-09-09 05:08:05 EDT
i have the exact same problem with the stock install - exactly the same. i 
still had it after installing all the latest up2date patches (including going 
through 3 different kernel rpm's). 

thats why i tried doing a custom build and tried to install x... i will attach 
the log files for you to examine but need to reinstall the kernel first 
(however, the results will be the same as originally mentioned)
Comment 5 jahshaka 2003-09-10 04:01:28 EDT
Created attachment 94365 [details]
XFree86.0.log
Comment 6 jahshaka 2003-09-10 04:04:35 EDT
note that this kernel was rebuilt from srpm and was not a custom build... i am
attaching the previous log file as well
Comment 7 jahshaka 2003-09-10 04:05:17 EDT
Created attachment 94367 [details]
XFree86.1.log - redhat kernel
Comment 8 Mike A. Harris 2003-09-11 03:12:53 EDT
>note that this kernel was rebuilt from srpm and was not a custom build... i am
>attaching the previous log file as well

Those two statements are contradictory.  A kernel not compiled by Red
Hat on a Red Hat build machine, and supplied to a customer via ftp or RHN
is by definition a "custom" kernel by our definition.  We only support
kernels that we build.  We do not support user compiled kernels wether they
are compiled from kernel.org sources, or our sources modified or unmodified.


[From - Additional Comment #3 From Mike A. Harris on 2003-09-09 03:42]
>Please reproduce this with the Red Hat kernel binaries, and attach your
>X server log, config file and /var/log/messages booted into the Red Hat
>built kernel using Red Hat built XFree86.  We do not support user recompiled
>binaries.

Awaiting X server config file, /var/log/messages, and an X log.  The kernel
log and the X log need to be from the same X server invocation.  These are
crucial pieces of information for debugging these types of problems.

Comment 9 jahshaka 2003-09-22 13:21:10 EDT
Created attachment 94632 [details]
latest messages logfile
Comment 10 jahshaka 2003-09-22 13:21:57 EDT
Created attachment 94633 [details]
latest xfree logfile
Comment 11 jahshaka 2003-09-22 13:22:30 EDT
I just upgraded to the latest kernel, the 2.4.21-3.EL and am still having this
problem. I am attaching the X log and the messages log - these are using the
standard installs. Note that i also upgraded to the latest XFree86 update as
well XFree86-4.3.0-32.EL

Are there also issues with this being -32 and not -64 (the xfree build) ?

Comment 12 John Dennis 2003-09-22 14:25:40 EDT
To the best of my knowlege nothing has changed with respect to DRI support on
ia64 so I would not expect this to have started to work. The agpgart kernel
driver is known to have problems. We are still in the process of investigating
possible solutions. The initial release of RHEL 3.0 will likely ship without
support, however we may be able to provide a driver update without having to
wait for RHEL 3.0 Update. I will update this bugzilla as soon as I have further
information.
Comment 13 John Dennis 2003-09-22 15:02:28 EDT

*** This bug has been marked as a duplicate of 104338 ***
Comment 14 jahshaka 2003-09-24 00:44:28 EDT
Sounds great, i ran out and bought a geforce card to see if i could get 
nvidias driver to install but now realize its not the drivers... 

Although while you are working on this the latest nvidia ia64 drivers wont 
even compile, they give a highmem error and crap out. I noticed that the 
latest release of these driver by nvidia was devember 2002 close to a year 
ago. I know that redhat doesnt support binary only drivers but maybe you can 
push them to get a newer release out the door in time for the agpgart fix?

How can i test the patch that bjorn put up for agpgart, its for the last 
kernel before the EL-3 release which i am now running... and i dont want to 
break anything in my current kernel which seems to be running perfectly!
Comment 15 jahshaka 2003-09-24 01:21:18 EDT
Anyone trying to get nvidia drivers running on taroon ia64 may want to follow 
this post

http://www.nvnews.net/vbulletin/showthread.php?s=&postid=201323#post201323

Comment 16 Mike A. Harris 2003-09-24 02:10:34 EDT
Red Hat doesn't support Nvidia's binary drivers at all on any platform.
We do not approach vendors and ask them to speed up their proprietary driver
release process for drivers we don't support either.

People who use their drivers however are of course free to ask them for
updated drivers, support, etc. if they wish, however Red Hat is not involved
in that process.

Nvidia uses their own proprietary agpgart, and does not use the agpgart
which we ship, so any fixes to agpgart that we provide won't affect users
using Nvidia proprietary drivers at all.

The problem described in the email you point out above, is because the Red
Hat kernel contains various enhancements over a stock 2.4.x kernel, which
have either been developed at Red Hat directly, or back ported from 2.5.x,
which change many kernel internals.  The kernel does not have a stable
advertised ABI, and so proprietary kernel modules will break and require
their vendors to fix them to work with new kernels. Nvidia will have to
update their drivers to work with the Red Hat Enterprise Linux 3 kernel.

Please contact Nvidia directly for any support issues/requests pertaining
to their drivers.

Thanks.
Comment 17 Red Hat Bugzilla 2006-02-21 13:58:29 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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