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
