On Fri, May 24, 2002 at 06:35:36PM -0700, Linus Torvalds wrote:
>
>
> 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.
Nod, this should be relatively easy given the nice way it exits.
0: 1 CTX
1: 1000700
2: 0
3: 0
4: 27260000
5: 900000
6: 400
7: 40007012
8: 101
9: 1012
10: 9803
11: 0
12: 201
13: 400
14: 10010003 {B0rked MAT? 17 takes us to c0 in 31: which gives me
15: 3b40c0c1 {a bad command -64
16: 0
17: 0
18: 3f516c07
19: 0
20: 6
21: c0042a00
22: 80000088
23: 603d4
24: 10000
25: 10003
26: 30002
27: 5 cmd packet
28: c0022f00
29: 1
30: 606
31: 466e0c0
... etc
drmRadeonCmdBuffer: -22
--
Michael.
_______________________________________________________________
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
