On Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote: > Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in > own words: > > "Most of the first cut of the DMA code. It's got most of the > dispatch > architecture in place (Lacks actual DMA submission (The easy part, > really...)) > so it's not done yet, but I promised people that done or not, I'd do a > check-in > of this..."
Yeah, if you'll remember, I said that I'd complete the code/test it barring fate handing me another full plate. Well, I probably shouldn't have made that comment, because I didn't get much of any coding done last week. I won't bore you w/the details, suffice it to say that I had to scramble to try to fix my financial situation due to my so-called employer's not paying me consistently. > The part which is missing is more or less what we have in the > mach64-0-0-4-branch, except that the state update is still being made with > MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we > bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor > of the later, since it will avoid redundant work of merging back and > forward, and will also enable the PowerPC architecture to participate in > testing. I'm for it, I was going to actually consider doing that very thing but the fun on my end of things just kept me distracted enough that I couldn't sit down and just code the whole thing. For the record, NEVER stay around at a company if they don't do a consistent and regular payroll run at the appointed times per their policies- any inconsistencies show in that situation, you should leave it right then and there. > So before we starting the merge, it's needed to include the state update > in the buffers. Although I still have some concerns about security, the > fact is that the only security problem we've seen so far is that a > malicious client can lock the card (by setting a 0 texture address offset) > and is not clear that we can recover from that too. I was able to make it recover from the "locked" state with DMA, etc. with the XAA FIFO size change by using the reset code in the mach64-0-0-3-dma-branch. Something to check would be to see if a 0 texture address offset would hang things with the interrupt (another reason for having it...) handler checking to see if we're locked up solid. I couldn't get the X server to do it's usual lockup behavior (if you ran X after doing the DMA test with the little testbed driver, it'd lock up tight...) when I inserted a forced reset like the one in my submitted code- and the DMA code worked just fine after startup (Of course, it reset the FIFO size...). -- Frank Earl _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
