On Friday 24 May 2002 11:31 am, Keith Whitwell scribed numinously:" +> > What's going to happen to the card if drmDMA() returns EAGAIN rather > > than EBUSY, which is what it does in the case where radeon_freelist_get > > returns NULL? Should the drm kernel module return EBUSY in that > > circumstance? None of the userspace parts seem to check for EAGAIN, but > > all the drm modules seem to return it when freelist_get falls off the > > bottom. > > drmDMA can legitimately fail in this way - if the card is busy and/or > there are other active clients holding buffers. > > In that case, the client is expected to retry. The problem is that if > the card has locked, you end up in the same place, and get people trying > to fix this code, which is just the effect, not the cause of the problem.
OK, I was expecting EAGAIN to mean "please retry" and I guess I got a little confused that it retried 16 times for EAGAIN and 2 million for EBUSY. I've introduced a tiny usleep into the loop in radeon_accel.c to give syslog a chance and my loghost now produces a couple of thousand lines of the form moomintroll kernel: [drm:radeon_freelist_get] skipping buf=23 age=48355 done=48319 moomintroll kernel: [drm:radeon_freelist_get] skipping buf=24 age=48356 done=48319 Covering about 30 seconds prior to me hitting reset, so the card certainly seems to be getting rather stuck, because 'done=N' doesn't increment over that 30 seconds. The lines immediately prior to this storm read: May 24 18:16:36 moomintroll kernel: [drm:radeon_freelist_get] ret buf=14 last=14 age=47687 done=47733 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_texture] tex: ofs=0xe240 p=32 f=7 x=0 y=310 w=512 h=202 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_texture] tex=2048x512 blit=2048 May 24 18:16:36 moomintroll kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0x0 e=0xf820 This isn't consistent though. Later I get a similar lockup and the logs are entirely different. Logs from a couple of tries are at http://www.electronghost.co.uk/radlock1.txt.gz Any ideas about where I should look? -- Tim Smith ([EMAIL PROTECTED]) Interfere? Of course we should interfere! Always do what you're best at, that's what I say. -- Doctor Who _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
