On Sun, 21 Dec 2003 08:35:14 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote: > > I recompiled a static Xserver so that could get a backtrace inside the > > driver. This is the result: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xbffff724, pm=-1, > > rop=0xbffff728) at savage_accel.c:758 > > 758 pm &= infoRec->FullPlanemask; > > (gdb) bt > > #0 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xbffff724, pm=-1, > > rop=0xbffff728) at savage_accel.c:758 > > #1 0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, color=0, rop=0, > > planemask=4294967295) at savage_dri.c:1956 > > #2 0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, prgn=0x87e1350, > > index=0) at savage_dri.c:1676 > > #3 0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, prgn=0x87e1350, > > bsreg=0x0) at dri.c:1569 > > #4 0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at miwindow.c:468 > > #5 0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at window.c:2841 > > #6 0x08126641 in ProcMapWindow (client=0x87588b8) at dispatch.c:688 > > #7 0x08125e9c in Dispatch () at dispatch.c:450 > > #8 0x0813d3d4 in main (argc=11, argv=0xbffffd84, envp=0xbffffdb4) > > at main.c:435 > > > > Apperently the DRI code in the savage driver uses accel functions even > > if acceleration is disabled. Maybe you can try disabling individual XAA > > acceleration functions. See the XF86Config-4 manual page for details. > > There are lots of options like XaaNoCPUToScreenColorExpandFill. > > This probably won't work as the type of operations above aren't going through > XAA to reach the accel functions, but instead calling them directly. The idea is that the driver thinks accel is enabled so it'll initialize the XAA and we don't get a segfault (hopefully). Still XAA won't use the accelerated functions if they are disabled by Xaa... options. I havn't looked into the details, so I may be missing something. Anyway, the hope is that the accelerated functions are responsible for the corruption Maximo is observing. To find that out is the whole purpose of these experiments. ;-) > > There are two cases that spring to mind where this happens: > > - New window creation > - A solid fill blit is used to initialize the back and depth buffers. > I've > never really been convinced that it was the job of the X server to do this > initialization, but in any case it (or the 3D driver) could just as easily > issue a 'clear' ioctl to the drm. There is no clear ioctl in the savage driver ATM. In fact there are no driver-specific ioctls at all (only for mapping PCI DMA buffers if AGP is not available). All hardware access is done in user space. :-/ > > - Window moves > - Copy blits are used to move the contents of the back and depth > buffers to > their new locations. > > > Both of these operations can be disabled at the expense of some corruption at > the times of these events. Look in the _dri.c file in the 2d driver for where > these are being called. It's always good to have several options. Maximo, you can try this too if you still get segfaults when disabling individual acceleration functions. > > Keith ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
