Bug#404447: [mangoo@wpkg.org: IXP4XX NPE / open source driver problem]
----- Forwarded message from Tomasz Chmielewski <mangoo@wpkg.org> -----
From: Tomasz Chmielewski <mangoo@wpkg.org>
Subject: IXP4XX NPE / open source driver problem
Date: Tue, 21 Nov 2006 13:01:20 +0100
I'm having problems with IXP4XX NPE / open source driver on FSG-3.
When I upload data (via Samba, SCP etc.) after a couple of seconds
(20-30 MBs of a big file transferred), the transfer stalls.
Downloads are fine, and the stalls don't happen.
Initially, I thought it's a Samba problem - see this thread:
http://lists.samba.org/archive/samba/2006-November/127084.html
for I found a workaround for that: putting
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=4096
SO_SNDBUF=4096
into smb.conf (normally, you would put 8192 instead of 2096 there)..
Now I see, the same happens for SCP transfers.
Anyone else seeing this too?
--
Tomasz Chmielewski
http://wpkg.org
----- End forwarded message -----
----- Forwarded message from Patrick Schneider <patrick.schneider1980@yahoo.de> -----
From: Patrick Schneider <patrick.schneider1980@yahoo.de>
Date: Tue, 21 Nov 2006 13:59:13 +0100
Hi,
i had a similar issue with NFS and the open source driver on the NSLU2
(using SlugOS/LE HEAD back in september). I was using the kernel-nfsd
from the SlugOS/LE alpha feeds. The transfer stalled and the syslog showed:
"nfsd: non-standard errno: -14"
After switching to DebianSlug 3.10beta, everything was fine again.
Unfortunately I can't help you further with that issue because I sold my
NSLU2s. Just wanted you to know, that you're not alone ;)
Regards,
Patrick
----- End forwarded message -----
----- Forwarded message from Tomasz Chmielewski <mangoo@wpkg.org> -----
From: Tomasz Chmielewski <mangoo@wpkg.org>
Date: Wed, 22 Nov 2006 10:14:41 +0100
Patrick Schneider wrote:
> Hi,
>
> i had a similar issue with NFS and the open source driver on the NSLU2
> (using SlugOS/LE HEAD back in september). I was using the kernel-nfsd
> from the SlugOS/LE alpha feeds. The transfer stalled and the syslog showed:
> "nfsd: non-standard errno: -14"
Whas it only when your device was sending data, but not receiving it?
> After switching to DebianSlug 3.10beta, everything was fine again.
Do you remember what kernel you used when you had that problem, and what
kernel you used after the problem was gone?
I'm using 2.6.18, with Debian.
> Unfortunately I can't help you further with that issue because I sold my
> NSLU2s. Just wanted you to know, that you're not alone ;)
The issue is very irritating.
When you receive data, it's enough to start a SCP upload - and it'll
break (freeze) all your current transfers.
--
Tomasz Chmielewski
http://wpkg.org
----- End forwarded message -----
----- Forwarded message from Patrick Schneider <patrick.schneider1980@yahoo.de> -----
From: Patrick Schneider <patrick.schneider1980@yahoo.de>
Date: Wed, 22 Nov 2006 22:48:03 +0100
Tomasz Chmielewski schrieb:
> Patrick Schneider wrote:
>> Hi,
>>
>> i had a similar issue with NFS and the open source driver on the NSLU2
>> (using SlugOS/LE HEAD back in september). I was using the kernel-nfsd
>> from the SlugOS/LE alpha feeds. The transfer stalled and the syslog showed:
>> "nfsd: non-standard errno: -14"
>
> Whas it only when your device was sending data, but not receiving it?
It happened while the device was receiving data (streaming an DVB-Stream
to the NSLU2) IIRC.
>
>> After switching to DebianSlug 3.10beta, everything was fine again.
>
> Do you remember what kernel you used when you had that problem, and what
> kernel you used after the problem was gone?
>
> I'm using 2.6.18, with Debian.
I think I was using 2.6.18 too.
(I compiled the FlashImage somewhere around the 27/28th of september.)
>> Unfortunately I can't help you further with that issue because I sold my
>> NSLU2s. Just wanted you to know, that you're not alone ;)
>
> The issue is very irritating.
>
> When you receive data, it's enough to start a SCP upload - and it'll
> break (freeze) all your current transfers.
Regards,
Patrick
----- End forwarded message -----
----- Forwarded message from Tomasz Chmielewski <mangoo@wpkg.org> -----
From: Tomasz Chmielewski <mangoo@wpkg.org>
Date: Thu, 23 Nov 2006 17:19:41 +0100
Patrick Schneider wrote:
> Tomasz Chmielewski schrieb:
>> Patrick Schneider wrote:
>>> Hi,
>>>
>>> i had a similar issue with NFS and the open source driver on the NSLU2
>>> (using SlugOS/LE HEAD back in september). I was using the kernel-nfsd
>>> from the SlugOS/LE alpha feeds. The transfer stalled and the syslog showed:
>>> "nfsd: non-standard errno: -14"
>> Whas it only when your device was sending data, but not receiving it?
>
> It happened while the device was receiving data (streaming an DVB-Stream
> to the NSLU2) IIRC.
I'm posting my finding also to this list (I sent it to linux-arm-kernel
mailing list, too):
------
I think I found a good workaround.
The device on which I use IXP4XX NPE / open source driver is FSG-3, it
has 64 MB RAM, and 266 MHz XScale-IXP42x CPU.
By default, /proc/sys/net/ipv4/tcp_wmem is "4096 16384 65536" [min,
default, max], and /proc/sys/net/ipv4/tcp_window_scaling is set to 1.
According to "man tcp", "These parameters are used by TCP to regulate
send buffer sizes. TCP dynamically adjusts the size of the send buffer
from the default values listed below, in the range of these sysctl
variables, depending on memory available".
I made some tests, where I transfered big "urandom" files via SCP.
When the "max" value from /proc/sys/net/ipv4/tcp_wmem was exceeding
about 28000, network connections just hang sometimes (when sending data).
So I put "net.ipv4.tcp_wmem = 4096 16384 16384" to /etc/sysctl.conf, it
seems a safe value.
Is it a problem with a driver, or with TCP stack?
Perhaps someone with better understanding of TCP could comment on that?
--
Tomasz Chmielewski
http://wpkg.org
----- End forwarded message -----
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: