From: w@1wt.eu (Willy Tarreau)
To: linux-arm-kernel@lists.infradead.org
Subject: Issue found in Armada 370: "No buffer space available" error during continuous ping
Date: Wed, 23 Jul 2014 08:16:59 +0200 [thread overview]
Message-ID: <20140723061659.GE30488@1wt.eu> (raw)
In-Reply-To: <CAB8gEUtmgwfWcuoYZ-wDwHVmzHN0WyOQD9oEOGAZ_gJfbPUm-g@mail.gmail.com>
Hi Maggie,
On Tue, Jul 22, 2014 at 07:24:35PM -0700, Maggie Mae Roxas wrote:
> Hi Willy,
> Good day.
>
> > OK so clearly the issue must be found.
>
> Actually we have 2 products using Armada 370.
> One has only 1 ethernet port, so it is expected to act as Client only.
> The other one has 2 ethernet ports, so it's more router-like.
>
> For the product with one port, we have checked the combination patch
> and it seems like Tx IRQ is increasing so it's OK. We checked this via
> /proc/interrupts and mvneta's value there changed from 500000+ to
> around 900000+ after we perform a 10-iteration iperf to the server.
> The throughput is also OK, we're getting around 850Mbits when we use a
> 1Gbit connection, which is roughly just the same as what we've been
> experiencing when we're still using 3.10.x (even 3.2.x).
OK.
> As for the other product with two ports, we do expect that we might be
> encountering the slow performance you mentioned.
> But we are not focusing on this project yet so once it's active again,
> I'll let you know.
>
> > Just thinking about something, do you have a custom boot loader ?
> > It would be possible that in our case, the Tx IRQ works only because some
> > obscure or undocumented bits are set by the boot loader and that in your
> > case it's not pre-initialized.
>
> We are indeed using a "custom" boot loader.
> We are using Marvell u-boot 2014_T1.1 (latest QA release, I think).
> We applied some patches to memory (since we have 1Gb DDR), some bits
> and pieces for the interfaces we're going to support and not to
> support, and of course our own environment variables.
> As for the DDR memory/register patches, they came directly from our
> Marvell contact.
>
> But with what I mentioned above, I think our Tx interrupt is working...?
Yes, seems so.
> BTW, for both products we've designed from Armada 370 RD, we didn't
> use a switch. So we removed all switch-related codes in the boot
> loader.
> I'm not sure if not having switch affects the behavior?
I have no idea, I remember that this code is deeply burried into the
original neta code. There was also a large code for the network
classifier and something like buffer management in the original
Marvell's driver if my memory serves me correctly, I have no idea
if these ones set up anything special.
> How about you? May I know what boot loader you are using?
Just the original ones. I have a mirabox with its original boot loader :
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
U-Boot Addressing:
Code: 00600000:006AFFF0
BSS: 006F8E40
Stack: 0x5fff70
PageTable: 0x8e0000
Heap address: 0x900000:0xe00000
Board: DB-88F6710-BP
SoC: MV6710 A1
CPU: Marvell PJ4B v7 UP (Rev 1) LE
CPU @ 1200Mhz, L2 @ 600Mhz
DDR @ 600Mhz, TClock @ 200Mhz
DDR 16Bit Width, FastPath Memory Access
PEX 0: Detected No Link.
PEX 1: Root Complex Interface, Detected Link X1
DRAM: 1 GB
CS 0: base 0x00000000 size 512 MB
CS 1: base 0x20000000 size 512 MB
Addresses 14M - 0M are saved for the U-Boot usage.
NAND: 1024 MiB
Bad block table found at page 262016, version 0x01
Bad block table found at page 261888, version 0x01
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Modules/Interfaces Detected:
RGMII0 Phy
RGMII1 Phy
PEX0 (Lane 0)
PEX1 (Lane 1)
phy16= 72
phy16= 72
MMC: MRVL_MMC: 0
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0
> > LTS would probably even interest your customer as it's an LTS version.
> > In this case, always pick the most recent one (3.14.12 today). You may
> > even be interested in 3.15.6 which contains another phy fix supposed to
> > fix cd71e2, but if you're saying that it doesn't change anything for you
> > I guess it will have no effet (might be worth testing for the purpose of
> > helping troubleshooting though).
>
> Thank you for this advise, we'll take note of this.
> We plan to stick on using LTS from now on, as much as possible.
>
> > OK. I still have a hard time imagining how hardware itself could prevent
> > an IRQ from being delivered from a NIC which is located inside the SoC,
> > but there must be an explanation somewhere :-/
> I also would like to know how. :-/
> But maybe it's our difference in boot loader as you speculated.
I think we could try to dump all of our respective mvneta registers and
compare them, though I have very little time for this today. And if it
comes from extra SoC functions like buffer management or network classifier,
I have no idea how they work nor what to dump :-/
Regards,
Willy
next prev parent reply other threads:[~2014-07-23 6:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 2:20 Issue found in Armada 370: "No buffer space available" error during continuous ping Maggie Mae Roxas
2014-07-08 2:27 ` Maggie Mae Roxas
2014-07-08 8:21 ` Thomas Petazzoni
2014-07-09 6:35 ` Maggie Mae Roxas
2014-07-14 3:55 ` Maggie Mae Roxas
2014-07-15 12:24 ` Thomas Petazzoni
2014-07-15 12:43 ` Willy Tarreau
2014-07-17 5:37 ` Maggie Mae Roxas
2014-07-17 8:15 ` Willy Tarreau
2014-07-21 1:57 ` Maggie Mae Roxas
2014-07-21 2:45 ` Maggie Mae Roxas
2014-07-21 5:44 ` Willy Tarreau
2014-07-21 6:33 ` Maggie Mae Roxas
2014-07-21 7:03 ` Willy Tarreau
2014-07-23 2:24 ` Maggie Mae Roxas
2014-07-23 6:16 ` Willy Tarreau [this message]
2014-07-24 7:24 ` Maggie Mae Roxas
2014-12-01 6:35 ` Maggie Mae Roxas
[not found] ` <CAB8gEUtgo-8nets3tRtqiZ8qRx+SyCq2d8v05scavWNwE5TNXg@mail.gmail.com>
2014-12-01 7:28 ` Willy Tarreau
2014-12-01 8:27 ` Maggie Mae Roxas
2014-12-01 9:28 ` Willy Tarreau
2014-12-01 9:32 ` Thomas Petazzoni
2014-12-01 9:58 ` Willy Tarreau
2014-12-01 10:15 ` Maggie Mae Roxas
2014-12-02 4:09 ` Maggie Mae Roxas
2014-12-02 6:56 ` Willy Tarreau
2014-12-02 7:04 ` Maggie Mae Roxas
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=20140723061659.GE30488@1wt.eu \
--to=w@1wt.eu \
--cc=linux-arm-kernel@lists.infradead.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).