Hello,

I really don't know where to start, so feel free to redirect me to the
right mailing list if this one is not the correct one.

[Summary]
I'm trying to help revive 3D hardware acceleration on ia64
architecture. This is a very long story that started in 2006
(http://bugs.freedesktop.org/show_bug.cgi?id=7770).

Currently, DRI can't be activated at all because of a regression
introduced during kernel 2.6.30 development cycle
(http://marc.info/?l=linux-ia64&m=126419878611433&w=2). I've bisected
the regression to commit f1a2a9b6189f9f5c27672d4d32fec9492c6486b2
(drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings). Simply
reverting it from current kernel source enables DRI again on ia64.
I've asked for help several times from the author (David S. Miller
<da...@davemloft.net>) through the linux-ia64 list and by contacting
him directly but got no answer at this time. So I really don't know
what to do with this patch. I bet that asking for its removal from the
kernel source is not an acceptable solution, isn't it?
[End of summary]

Anyway, with DRI enabled, I'm now trying to make it works again. My
ia64 workstation sports an ATI FireGL X1 AGP adapter. I'm using the
r300 open source driver. As soon as an 3D OpenGL application is
started (e.g. glxgears), it eats CPU ressources within seconds.
Switching between XAA/EXA acceleration makes no difference. Reducing
AGP speed from 2x (set by default when no xorg.conf file is present)
to 1x has little impact (the offending application takes 3 sec. rather
than 1-2 sec. to eat CPU ressources). The system isn't locked as it
can be remotely rebooted, but is really unusable once a 3D OpenGL
application has started eating CPU. Killing the offending application
makes the X server eats CPU ressources. This behaviour is consistent
with what I noticed one year ago with older X.org X server
(http://bugs.freedesktop.org/show_bug.cgi?id=7770#c42), so I bet the
problem is still there with current X.org implementation (I'm using
X.org X Server 1.7.4 on a Debian "Squeeze" Testing distribution).

I don't know what information is useful, so I simply straced glxgears
with drm.debug=1 passed to kernel with my current hardware
configuration. Eventually, strace log is flooded with
ioctl(4, 0xc0106451, 0x60000fffffd530f8) = 0
roughly at the time the CPU charge increases. This is consistent with
what is recorded in syslog:
Jan 29 21:16:03 longspeak kernel: [  318.611783] [drm:drm_ioctl],
pid=2426, cmd=0xc0106451, nr=0x51, dev 0xe200, auth=1
Jan 29 21:16:03 longspeak kernel: [  318.611789]
[drm:radeon_cp_getparam], pid=2426
repeated several tens of thousands times where 2426 is glxgears PID.
Is this 0xc0106451 command a valuable information?

I don't know if it's informative either, but enabling the side-bar in
GNOME Shell eats CPU ressources too and syslog is flooded with:
Jan 30 12:38:26 longspeak kernel: [  325.146380] [drm:radeon_do_cp_idle],
Jan 30 12:38:26 longspeak kernel: [  325.332672]
[drm:radeon_do_wait_for_idle], wait idle failed status : 0x84110140
0x9C000800
Jan 30 12:38:26 longspeak kernel: [  325.332676]
[drm:radeon_do_release], radeon_do_cp_idle -16
Does this failed status provides a useful starting point?

Thanks for reading and any advice/suggestion welcome.

Émeric

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to