From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
Simon Horman <horms@verge.net.au>
Cc: netdev@vger.kernel.org, linux-sh@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH] sh_eth: r8a7790: Handle the RFE (Receive FIFO overflow Error) interrupt
Date: Thu, 12 Sep 2013 19:45:05 +0000 [thread overview]
Message-ID: <523219C1.1020300@cogentembedded.com> (raw)
In-Reply-To: <4760883.hI1JN8gopV@avalon>
Hello.
On 07/30/2013 06:20 PM, Laurent Pinchart wrote:
>>> The RFE interrupt is enabled for the r8a7790 but isn't handled,
>>> resulting in the interrupts core noticing unhandled interrupts, and
>>> eventually disabling the ethernet IRQ.
>>> Fix it by adding RFE to the bitmask of error interrupts to be handled
>>> for r8a7790.
>> So, Simon hasn't synced his patch to my late bug fix in 3.10... Did this
>> patch help you with your NFS boot issue, Laurent?
> Yes, it fixes the "disabling interrupt, nobody cared" problem. I still have
> intermittent NFS issues, but at least I can now boot.
Looks like the reason for them is the same I had to fix up for the BOCK-W:
the bouncing LINK signal. The PHY used is the same as on BOCK-W, however, its
LED seems to be configured differently: for LINK and ACTIVE LEDs, this is
non-default PHY configuration which AFAIK gets reset to default when the PHY
gets reset. What I saw when I added orintk() for the interrupt enable/mask
tracing was the LINK signal behaving normally at first but after some time ECI
(M-Port in the manuals) interrupts started to behave the way well known from
BOCK-W, i.e. bouncing on and off after each packet; I was also getting endless
RFE (Rx FIFO overflow) interrupts and NFS was unable to mount at all in this
traced mode. The fix was the same as for BOCK-W: to set 'no_ether_link' field
of the platfrom data to 1. After that I've no more seen NFS timeouts and RFE
interrupts. I'm going to continue testing but thought I let everybody know of
my currct findings and the remedy for the NFS issue.
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
Simon Horman <horms@verge.net.au>
Cc: netdev@vger.kernel.org, linux-sh@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH] sh_eth: r8a7790: Handle the RFE (Receive FIFO overflow Error) interrupt
Date: Thu, 12 Sep 2013 23:45:05 +0400 [thread overview]
Message-ID: <523219C1.1020300@cogentembedded.com> (raw)
In-Reply-To: <4760883.hI1JN8gopV@avalon>
Hello.
On 07/30/2013 06:20 PM, Laurent Pinchart wrote:
>>> The RFE interrupt is enabled for the r8a7790 but isn't handled,
>>> resulting in the interrupts core noticing unhandled interrupts, and
>>> eventually disabling the ethernet IRQ.
>>> Fix it by adding RFE to the bitmask of error interrupts to be handled
>>> for r8a7790.
>> So, Simon hasn't synced his patch to my late bug fix in 3.10... Did this
>> patch help you with your NFS boot issue, Laurent?
> Yes, it fixes the "disabling interrupt, nobody cared" problem. I still have
> intermittent NFS issues, but at least I can now boot.
Looks like the reason for them is the same I had to fix up for the BOCK-W:
the bouncing LINK signal. The PHY used is the same as on BOCK-W, however, its
LED seems to be configured differently: for LINK and ACTIVE LEDs, this is
non-default PHY configuration which AFAIK gets reset to default when the PHY
gets reset. What I saw when I added orintk() for the interrupt enable/mask
tracing was the LINK signal behaving normally at first but after some time ECI
(M-Port in the manuals) interrupts started to behave the way well known from
BOCK-W, i.e. bouncing on and off after each packet; I was also getting endless
RFE (Rx FIFO overflow) interrupts and NFS was unable to mount at all in this
traced mode. The fix was the same as for BOCK-W: to set 'no_ether_link' field
of the platfrom data to 1. After that I've no more seen NFS timeouts and RFE
interrupts. I'm going to continue testing but thought I let everybody know of
my currct findings and the remedy for the NFS issue.
WBR, Sergei
next prev parent reply other threads:[~2013-09-12 19:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 0:08 [PATCH] sh_eth: r8a7790: Handle the RFE (Receive FIFO overflow Error) interrupt Laurent Pinchart
2013-07-30 0:08 ` Laurent Pinchart
2013-07-30 2:10 ` Simon Horman
2013-07-30 2:10 ` Simon Horman
2013-07-30 14:17 ` Sergei Shtylyov
2013-07-30 14:17 ` Sergei Shtylyov
2013-07-30 14:20 ` Laurent Pinchart
2013-07-30 14:20 ` Laurent Pinchart
2013-07-30 14:47 ` Sergei Shtylyov
2013-07-30 14:47 ` Sergei Shtylyov
2013-09-12 19:45 ` Sergei Shtylyov [this message]
2013-09-12 19:45 ` Sergei Shtylyov
2013-07-31 0:32 ` Simon Horman
2013-07-31 0:32 ` Simon Horman
2013-07-30 20:41 ` Sergei Shtylyov
2013-07-30 20:41 ` Sergei Shtylyov
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=523219C1.1020300@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=horms@verge.net.au \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.