From: "Ira W. Snyder" <iws@ovro.caltech.edu>
To: Tabi Timur-B04825 <B04825@freescale.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
Date: Thu, 16 Feb 2012 11:00:41 -0800 [thread overview]
Message-ID: <20120216190040.GA9262@ovro.caltech.edu> (raw)
In-Reply-To: <CAOZdJXVccE0GqZU2PvAz3RTh+X9ZYZr-9YufxS+mYWJkhSOGEQ@mail.gmail.com>
On Thu, Feb 16, 2012 at 05:50:47PM +0000, Tabi Timur-B04825 wrote:
> On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> > The mpc8349ea has been observed to generate spurious end of segments
> > interrupts despite the fact that they are not enabled by this driver.
> > Check for them and ignore them to avoid a kernel error message.
>
> When this happens, are there any other status bits set? It seems
> weird that there are spurious interrupts from an internal block,
> especially since it's the same block on all 83xx parts.
>
> I wonder if the EOSI bit just happens to be set when the interrupt
> occurs for some other reason.
>
I'm not sure. The fsldma irq handler only prints bits it did not handle.
There are several other bits in the driver which should never be seen,
but they are handled by the irq handler anyway. This is just a remnant
from the original Freescale code.
I have a set of 15 test boards that I can use to figure out which other
bits are set when this happens, if it is important.
I put a variation of this patch (missing the "skip tasklet if not idle"
logic) into my production boards roughly a month ago. I've gotten the
"controller not idle" error message 748 times, as compared to the
"unhandled sr 0x00000002" message 3449 times.
This leads me to believe that this occurs mostly (but not always)
concurrent with the end-of-chain interrupt.
In the last month, the "unhandled sr" error has occurred on 92 out of
120 boards in production use. The statistics are included below. On some
boards, it is much more frequent than on others. All boards have roughly
the same workload.
Another interesting tidbit from my logs: this only occurs on DMA channel
2 (the are numbered starting at 0, it is the 3rd channel). Here is an
example log message:
[3484053.821689] of:fsl-elo-dma e00082a8.dma: chan2: irq: unhandled sr 0x00000002
Thanks,
Ira
15 serial-number-5
1 serial-number-16
8 serial-number-18
16 serial-number-19
3 serial-number-20
21 serial-number-21
1 serial-number-24
1 serial-number-26
3 serial-number-27
2 serial-number-28
16 serial-number-29
4 serial-number-30
1 serial-number-31
4 serial-number-32
5 serial-number-33
1 serial-number-34
6 serial-number-35
18 serial-number-36
1 serial-number-39
1 serial-number-40
2 serial-number-41
10 serial-number-42
11 serial-number-43
32 serial-number-45
6 serial-number-46
4 serial-number-47
1 serial-number-49
6 serial-number-50
2 serial-number-51
4 serial-number-53
1 serial-number-55
1 serial-number-57
15 serial-number-58
1 serial-number-60
1 serial-number-62
1 serial-number-66
8 serial-number-67
2 serial-number-75
1 serial-number-76
11 serial-number-79
4 serial-number-80
8 serial-number-81
1 serial-number-82
11 serial-number-84
2 serial-number-92
20 serial-number-93
30 serial-number-94
19 serial-number-95
32 serial-number-96
73 serial-number-97
18 serial-number-99
57 serial-number-100
41 serial-number-101
28 serial-number-102
8 serial-number-103
132 serial-number-107
60 serial-number-108
55 serial-number-109
97 serial-number-110
18 serial-number-111
45 serial-number-113
6 serial-number-114
123 serial-number-115
27 serial-number-117
29 serial-number-118
12 serial-number-119
47 serial-number-120
74 serial-number-121
8 serial-number-124
128 serial-number-125
326 serial-number-128
84 serial-number-129
36 serial-number-130
2 serial-number-131
75 serial-number-133
64 serial-number-135
686 serial-number-137
97 serial-number-139
28 serial-number-140
82 serial-number-141
36 serial-number-144
31 serial-number-145
47 serial-number-147
60 serial-number-150
22 serial-number-152
36 serial-number-154
57 serial-number-156
68 serial-number-158
54 serial-number-159
37 serial-number-160
46 serial-number-161
14 serial-number-162
next prev parent reply other threads:[~2012-02-16 19:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 20:58 [PATCH 1/1] fsldma: ignore end of segments interrupt Ira W. Snyder
2012-01-31 21:30 ` [PATCH v2] " Ira W. Snyder
2012-02-16 17:50 ` [PATCH 1/1] " Tabi Timur-B04825
2012-02-16 19:00 ` Ira W. Snyder [this message]
2012-02-16 19:34 ` Timur Tabi
2012-02-16 19:46 ` Ira W. Snyder
2012-02-16 19:48 ` Timur Tabi
2012-02-17 0:57 ` 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=20120216190040.GA9262@ovro.caltech.edu \
--to=iws@ovro.caltech.edu \
--cc=B04825@freescale.com \
--cc=dan.j.williams@intel.com \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).