On Fri, 1 Mar 2002, Jos� Fonseca wrote: ...
> > With locking disabled, I got a segfault in mach64CopyBuffer at line 139, > > where box (mmesa->pClipRects) was null. Then I re-enabled locking (still > > This segfault is fixed with the attached patch that allows to enter into > mach64GetLock to setup the clipRects. > > > > > with debugging output on). Then I get a see a bunch of messages, the > > last > > ones which are still visible are: > > > > FLUSH_BATCH in mach64WriteMonoRGBAPixels_RGB565 > > > > followed by a lockup in mach64CopyBuffer once again. This appears to > > happpen right before swapping buffers via the DRM. The lockup isn't > > fatal, so I can ssh in, kill X and restart X from another box. > > ok, disregard this part, I think this was while still running without the locking on. So a couple of things: I disabled the color mask code in mach64_state.c (and checked it in), because I'm not sure that part is correct. Also, I tried setting HAVE_TEX0_VERTICES and HAVE_TEX1_VERTICES in _vb.c. I ran glxgears with locking and register writes enabled, but printf's for the register writes. The screen gets all messed up, but it's trying to draw. The last thing I saw in the terminal before a _hard_ lockup (reboot required) were reg. writes to the first vertex registers in the setup engine, and it was beginning on the second vertex (it's hard to tell exactly where it stopped because of buffering of the printf output). So I think we need to look at the vertex formats in the template code and the register programming in _tris.c and make sure we're giving the hardware the right data in the right format. -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
