From: David Miller <davem@davemloft.net>
To: hong.pham@windriver.com
Cc: netdev@vger.kernel.org, matheos.worku@sun.com
Subject: Re: [PATCH 0/1] NIU: fix spurious interrupts
Date: Fri, 22 May 2009 01:08:49 -0700 (PDT) [thread overview]
Message-ID: <20090522.010849.89655675.davem@davemloft.net> (raw)
In-Reply-To: <4A15F466.70708@windriver.com>
From: "Hong H. Pham" <hong.pham@windriver.com>
Date: Thu, 21 May 2009 20:40:06 -0400
> Posted below is a log with the fix.
Thank you.
> What's interesting (baffling?) is that interrupts are being received
> with the LD interrupt mask set or cleared. The mask also changes
> in between interrupts. The mask always changes from 3 to 0, and never
> from 0 to 3.
The "3 --> 0" transition is made by niu_poll_core() as we are
about to napi_complete() and rearm the LDG.
But yes this log doesn't make any sense. Neither the masks
nor the ARM bit appear to be working.
I wonder if the spurious interrupts trigger exactly at the
nw64(LD_IM0(LDN_RXDMA(rp->rx_channel)), 0);
in niu_poll_core().
Can you run one more test? Supplement the debugging output
with:
"%pS", get_irq_regs()->tpc
so we can see where the program counter is at the time of
the spurious interrupt?
Meanwhile, even if we go with your patch to fix this, we can't
use it as-is. Let me explain.
Suppose that we get this spurious interrupt right after we unmask the
interrupt and right before napi_complete(). Your change will make us
re-mask the interrupts, but without scheduling NAPI.
So once the napi_complete() happens, if no further interrupts trigger
in that LDG, we'll never process those interrupt events cleared by
your new code. See what I mean?
I don't know how to fix this, it's full of races. I suppose we could
recheck if events are pending in the LDG after we do the
napi_complete() and reschedule NAPI again if so. But that might be
expensive (several register reads, just to check something that's not
going to happen most of the time).
I'm also wondering why we see this on Niagara-2 and not on PCI-E
cards. If the interrupts that go into the NCU unit of Niagara-2 are
levelled interrupts, and somehow the ARM bit is not implemented
correctly in the NIU logic when hooked up to NCU instead of PCI-E
logic, that could explain things.
I bet that our Linux driver is the only one that bangs on the LDG
mask registers like this.
next prev parent reply other threads:[~2009-05-22 8:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 19:00 [PATCH 0/1] NIU: fix spurious interrupts Hong H. Pham
2009-05-11 19:00 ` [PATCH 1/1] " Hong H. Pham
2009-05-19 5:09 ` [PATCH 0/1] " David Miller
2009-05-19 21:52 ` Hong H. Pham
2009-05-19 22:01 ` David Miller
2009-05-20 15:57 ` Hong H. Pham
2009-05-21 0:37 ` David Miller
2009-05-21 22:18 ` David Miller
2009-05-22 0:40 ` Hong H. Pham
2009-05-22 8:08 ` David Miller [this message]
2009-05-22 16:42 ` Hong H. Pham
2009-05-26 6:16 ` David Miller
2009-05-27 16:29 ` Hong H. Pham
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=20090522.010849.89655675.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=hong.pham@windriver.com \
--cc=matheos.worku@sun.com \
--cc=netdev@vger.kernel.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).