On Sat, 25 May 2002, Michael wrote:
>
> As you surmise, it takes hours, more so now, because I'm pouring through
> DEBUG_VERBOSE output. (I've noticed a couple of places where the packet
> type isn't 6 because there's no cmd[0].i = 0, I don't think they cause
> problems because the drm module would ignore the bogus values, that had
> me confused for a bit)
I got interested enough to try out tuxracer myself. It seems to work fine
for me, but whenever I try to move the window (or occlude it by moving
another window on top - sounds to me like the problem is in some
double-buffer logic) I get a
drmRadeonCmdBuffer: -22
and the kernel logs show
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type -51 at 082d93b8
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type -51 at 082d93b8
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type -90 at 082d93b8
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type -51 at 082d93b8
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type -42 at 082d93b8
which certainly seems to imply that there are bogus command packets being
sent to the kernel by tuxracer.
Don't ask me why.
Linus
_______________________________________________________________
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