netdev - Re: [PATCH v5 0/3] ARM: shmobile: lager: enable Ether

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1585887.1Wse2jq6qr@avalon>
Date:	Fri, 26 Jul 2013 17:33:55 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:	Simon Horman <horms@...ge.net.au>, netdev@...r.kernel.org,
	linux-sh@...r.kernel.org, Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH v5 0/3] ARM: shmobile: lager: enable Ether

Hi Sergei,

On Friday 26 July 2013 18:33:49 Sergei Shtylyov wrote:
> Hello.
> 
> On 26-07-2013 4:55, Simon Horman wrote:
> >>> this short series enables the on-board ethernet
> >>> of the r8a7790 SoC for on lager board.
> >>> 
> >>> It has a run-time dependency on
> >>> "sh_eth: add support for r8a7790 SoC"
> >>> 
> >>> It has been built on top of renesas-next-20130724v2.
> >>> 
> >>> Simon Horman (3):
> >>>    ARM: shmobile: r8a7790: clocks for Ether support
> >>>    ARM: shmobile: lager: enable Ether
> >>>    ARM: shmobile: lager: enable nfsroot in DTS
> >>>   
> >>>   arch/arm/boot/dts/r8a7790-lager.dts    |  2 +-
> >>>   arch/arm/mach-shmobile/board-lager.c   | 30 ++++++++++++++++++++++++++ 
> >>>   arch/arm/mach-shmobile/clock-r8a7790.c |  4 ++++
> >>>   3 files changed, 35 insertions(+), 1 deletion(-)
> >> 
> >> With this series and "[PATCH 0/2 v4 net-next repost] sh_eth: Add support
> >> for r8a7790 SoC" applied on top of renesas-devel-20130725, booting the
> >> Lager board usually (about 90% of the time) results in receive FIFO
> >> overflows and disabling of the sh-eth IRQ:
>
> Looking at the trace, disabling of IRQ is probably caused by something other
> than RX FIFO overflow (when it caused disabling IRQ, there were no error
> messages printed because RFE interrupt went completely unhandled). Probably
> there's more interrupt mask issues lurking in the driver...

I think we're having two issues here. The first one is that receive FIFO 
overflows happen, and the second one is that the driver doesn't recover 
properly, resulting in an interrupt storm. Both should be fixed.

At least one of the issues might be related to interrupt latency. As the 
interrupt storm occurs when the mmc0 got probed, I've tried to disable the MMC 
subsystem, and the situation improved. I still get NFS errors:

[   25.692576] nfs: server 192.168.1.47 not responding, still trying
[   25.698824] nfs: server 192.168.1.47 not responding, still trying
[   25.705055] nfs: server 192.168.1.47 not responding, still trying
[   26.196158] nfs: server 192.168.1.47 not responding, still trying
[   26.203230] nfs: server 192.168.1.47 OK
[   26.207248] nfs: server 192.168.1.47 OK
[   26.211261] nfs: server 192.168.1.47 OK
[   26.215278] nfs: server 192.168.1.47 OK

But the system boots properly.

> > Thanks.
> > 
> > Unfortunately I am having trouble with using NFS root at all in my test
> > environment. I'll work with Magnus to resolve this issue.
> > 
> > Sergei do you have any idea what might be causing this?
> 
> No idea. I still don't have access to Lager and on BOCK-W we have no issues
> with NFS. What are your symptoms?

I think the kernel boot log from my original e-mail showed the symptoms pretty 
explicitly :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html