On 2002.03.01 18:30 Leif Delgass wrote: > On Fri, 1 Mar 2002, José Fonseca wrote: > > > I've overcome this, but sursprisingly there is no further segfault. I > see > > all the debuging statements scrolling in my terminal without stoping. > > > > This either means that the problem is at the locking mechanism or in > the > > card programming in _tris.c. > > > > I'm really suspicious about the locking because when I first disabled > the > > MMIO (since the driver doesn't really do PIO) and forget about > disabling > > the locking the my computer also hanged. How can this be? Since when > the > > locking is overriden the computer doesn't hang this means that the > problem > > must when locking. > > Hmm, I'm not sure. I know that we never resolved all the issues with > locking with the DDX driver, which is why XAA is disabled. The card > locking up could just mean it's been programmed with bad data or state, > not necessarily a lock conflict, I think. > > > Any ideas? > > Here's my experience so far: > > 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. > > I'll let you know if I make any progress here. > > Ok. José Fonseca
mach64-debug-2.patch
Description: Binary data
