On Sun, Jan 31, 2010 at 02:28:39PM +0100, Émeric Maschino wrote: > 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
You are hitting GPU lockup which traduce by userspace keep trying the same ioctl over and over again which completely eat all CPU. There is no easy way to debug GPU lockup and no way at all than by staring a GPU command stream or making wild guess and testing things randomly. Cheers, Jerome ------------------------------------------------------------------------------ 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
