On Tue, Mar 01, 2011 at 07:52:39AM +0200, Felix Radensky wrote: > Hi Ira, > > On 03/01/2011 02:21 AM, Ira W. Snyder wrote: > > On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote: > >> Hi Ira, > >> > >> On 02/28/2011 11:11 PM, Ira W. Snyder wrote: > >>> On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote: > >>>> Hi Ira, > >>>> > >>>>> Thank you very much Felix. The dmesg output shows that the controller > >>>>> never got an interrupt for the second transaction. The patch below has > >>>>> extra debugging information that may help determine why this happens. > >>>>> Please apply it and re-run the test. > >>>>> > >>>>> The last section of dmesg (after "Freeing unused kernel memory") is all > >>>>> I need. > >>>>> > >>>> Attached relevant dmesg portion. > >>>> > >>> Ok, try this patch on top of the last one. > >>> > >>> It looks like you used the dmatest module in multi-channel mode last > >>> time. One channel makes it easier to debug: > >>> > >>> modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1 > >>> > >>> Thanks for your help in debugging this. Hopefully this is the last > >>> patch to test. :) > >>> > >>> Ira > >>> > >> Looks like this was not the last one. The test still fails, see below > >> > > From this log, it looks like the DMA controller is not generating an > > interrupt after the second chain is started. The first chain is finished > > before the second thread runs and starts its chain. > > > > The end-of-segments interrupt is completely missing. The part is not > > behaving as the datasheet explains it should. Are you sure you applied > > the patch and rebuilt the kernel? (Just checking to be sure. I'm very > > appreciative of the amount of help you've given me debugging this!) > > > > Can you run this for me: > > > > modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4 > > > > Thanks again, > > Ira > > Without your patches applied the output of the test above looks > like this: >
Thanks, this is exactly what I was going to ask for next. :) I really don't understand why the P2020 DMA controller isn't behaving nicely after my patches. Can you run a git bisect to figure out which patch in the series causes the problems. It should take three or four build + test cycles to narrow down which patch breaks the driver. When it is finished, send me the output of git bisect. Like this (assuming you have two branches: master and fsldma, where fsldma is master + my patches): # setup the bisect git bisect start git bisect bad fsldma git bisect good master # build and test the kernel using the same test as before: modprobe dmatest max_channels=1 threads_per_chan=1 iterations=4 # if the test passes: git bisect good # if the test fails: git bisect bad # now build + test again, then mark that good or bad. Repeat until # finished. I really appreciate your help in testing this. You've been great at providing everything I've asked for. Thanks, Ira _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
