Bug 19698 - No DRI. "Could not set DRM device bus ID." VIA mobo chipset/ATI r200 adapter
Summary: No DRI. "Could not set DRM device bus ID." VIA mobo chipset/ATI r200 adapter
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg 6.7.0
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-23 01:04 UTC by Chris Collins
Modified: 2010-12-02 19:48 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg w/ "drm debug=1" (59.32 KB, text/plain)
2009-01-23 01:04 UTC, Chris Collins
no flags Details
Xorg.0.log (50.28 KB, text/plain)
2009-01-23 01:05 UTC, Chris Collins
no flags Details
dmesg after apply the modules from the git pull (52.37 KB, text/plain)
2009-01-23 15:21 UTC, Chris Collins
no flags Details
Xorg.0.log after installng modules from the git pull (50.65 KB, text/plain)
2009-01-23 15:24 UTC, Chris Collins
no flags Details

Description Chris Collins 2009-01-23 01:04:49 UTC
Created attachment 22169 [details]
dmesg w/ "drm debug=1"

In X my video adapter will not use DRI. When doing "startx" DRI fails as reported in the Xorg.0.log.

To reproduce: simply startx.

Actual results: X starts, KDE runs, but without DRI. Error is reported in my Xorg.0.log

Expected results: Both the server, and the hardware ostensibly support DRI. I expect acceleration.

Build date:
X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Slackware 12.1 Slackware Linux Project
Current Operating System: Linux ira 2.6.27.7 #1 Mon Jan 19 09:57:43 PST 2009 i586
Build Date: 30 June 2008  11:35:29PM

Additional: This behavior existed on the previous server supplied with my distro too. (Though I didn't report it until now.)

I have set my drm module to "drm debug=1".

I am attaching my dmesg, and my Xorg.0.log
Comment 1 Chris Collins 2009-01-23 01:05:59 UTC
Created attachment 22170 [details]
Xorg.0.log
Comment 2 Alex Deucher 2009-01-23 10:36:01 UTC
Can you try the drm in git master?
first backup your old drm modules (usually in /lib/modules/`uname -r`/kernel/drivers/char/drm/) , then:

git clone git://anongit.freedesktop.org/mesa/drm
cd drm/linux-core
make

(as root)
cp *.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/
modprobe -r radeon
depmod -a

Then start X.
Comment 3 Chris Collins 2009-01-23 15:21:54 UTC
Created attachment 22188 [details]
dmesg after apply the modules from the git pull
Comment 4 Chris Collins 2009-01-23 15:24:03 UTC
Created attachment 22189 [details]
Xorg.0.log after installng modules from the git pull
Comment 5 Chris Collins 2009-01-23 15:25:10 UTC
> first backup your old drm modules (usually in /lib/modules/`uname
> -r`/kernel/drivers/char/drm/) , then:

Mine were in:
/lib/modules/2.4.27/kernel/driver/gpu/drm/drm.ko
and
/lib/modules/2.4.27/kernel/driver/gpu/drm/radeon/radeon.ko

> cp *.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/
> modprobe -r radeon
> depmod -a
>
> Then start X.

I ran:
modprobe -r drm
modprobe -r radeon
depmod -a

after running X I have the dmesg and Xorg.0.log, attached.
Comment 6 Chris Collins 2009-01-23 16:12:48 UTC
(In reply to comment #5)

> Mine were in:
> /lib/modules/2.4.27/kernel/driver/gpu/drm/drm.ko
> and
> /lib/modules/2.4.27/kernel/driver/gpu/drm/radeon/radeon.ko

Make that:

/lib/modules/2.6.27.7/kernel/drivers/gpu/drm

etc. 
Comment 7 Dave Airlie 2009-02-03 17:05:56 UTC
I can't see why the hell this is failing, the only think I can think of is a bug in libdrm somehow,

you could try making libdrm and using it instead of the system one


The other option is to add some debugging to the setversion ioctl in the drm_ioctl.c in the kernel and see why it is failing.

It really should be returning a valid value in GetBusID and you shouldn't see the repeated opening.

I just know of course the answer will be one of the DOH! type things.
Comment 8 Matt Turner 2010-12-02 19:48:31 UTC
Closing due to inactivity. Please reopen if this is still a problem.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.