[PATCH 0/8] fsldma: lockup fixes

[Ira W. Snyder]

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