linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).