From: "Ira W. Snyder" <iws@ovro•caltech.edu>
To: Felix Radensky <felix@embedded-sol•com>
Cc: "linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>
Subject: Re: [PATCH 0/8] fsldma: lockup fixes
Date: Tue, 1 Mar 2011 08:55:15 -0800 [thread overview]
Message-ID: <20110301165515.GA23403@ovro.caltech.edu> (raw)
In-Reply-To: <4D6C89A7.8010803@embedded-sol.com>
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
next prev parent reply other threads:[~2011-03-01 16:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 18:47 [PATCH 0/8] fsldma: lockup fixes Felix Radensky
2011-02-28 19:53 ` Ira W. Snyder
2011-02-28 20:15 ` Felix Radensky
2011-02-28 21:11 ` Ira W. Snyder
2011-02-28 21:27 ` Felix Radensky
2011-03-01 0:21 ` Ira W. Snyder
2011-03-01 5:46 ` Felix Radensky
2011-03-01 5:52 ` Felix Radensky
2011-03-01 16:55 ` Ira W. Snyder [this message]
2011-03-01 19:52 ` Ira W. Snyder
2011-03-02 5:49 ` Felix Radensky
2011-03-02 16:42 ` Ira W. Snyder
-- strict thread matches above, loose matches on Subject: below --
2011-02-28 11:36 Felix Radensky
2011-02-28 17:16 ` Ira W. Snyder
2011-02-26 0:23 Ira W. Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110301165515.GA23403@ovro.caltech.edu \
--to=iws@ovro$(echo .)caltech.edu \
--cc=felix@embedded-sol$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox