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] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d2jvfr1m.fsf@natisbad.org>
Date:	Mon, 13 Jan 2014 23:36:05 +0100
From:	arno@...isbad.org (Arnaud Ebalard)
To:	Willy Tarreau <w@....eu>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH 0/5] Assorted mvneta fixes

Hi,

Willy Tarreau <w@....eu> writes:

>> Funny enough, I spent some time this week-end trying to find the root
>> cause of some kernel freezes and panics appearing randomly after some GB
>> read on a ReadyNAS 102 configured as a NFS server. 
>> 
>> I tested your fixes and performance series together on top of current
>> 3.13.0-rc7 and I am now unable to reproduce the freeze and panics after
>> having read more than the 300GB of traffic from the NAS: following
>> bandwith with a bwm-ng shows the rate is also far more stable than w/
>> previous driver logic (55MB/sec). So, FWIW:
>> 
>> Tested-by: Arnaud Ebalard <arno@...isbad.org>
>
> Thanks for this.
>
> BTW, the "performance" series is not supposed to fix anything, 

I was lazy and wanted to give the whole set a try in a single pass.


> and still it seems difficult to me to find what patch might have fixed
> your problem. Maybe the timer used in place of an IRQ has an even
> worse effect than what we could imagine ?

I guess so.


>> Willy, I can extend the test to RN2120 if you think it is useful to also
>> do additional tests on a dual-core armada XP.
>
> It's up to you. These patches have run extensively on my Mirabox (Armada370),
> OpenBlocks AX3 (ArmadaXP dual core) and the XP-GP board (ArmadaXP quad core),
> and fixed the stability issues and performance issues I was facing there. But
> you may be interested in testing them with your workloads (none of my boxes
> is used as an NFS server, NAS or whatever, they mainly see HTTP and very small
> packets used in stress tests).

Well, I spent the evening on my RN104 (Aramda370 w/ 2 GbE ifaces) and my
RN2120 (Dual core ArmadaXP w/ 2GbE ifaces) using one as a router and
serving NFS traffic from the other (and then changing roles). I passed
hundreds of GB of TCP/NFS traffic and did not see any issue.

Additionally, FWIW, testing both using netperf show they easily support
routing traffic w/ line rate perf.

Regarding the patches, the problem they solve impacts all Armada boards
(370 and XP) which are used for network tasks. I think it would be nice
to have those backported to stable. I can commit to do the tests of the
backports both on XP and 370 hardware down to 3.12 or 3.11 kernel if it
can help. 

Cheers,

a+
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ