NFS client large rsize/wsize (tcp?) problems

[Erik Slagter <erik@slagter.name>]

Hello All,

I am almost complete NOOB on this matter, so please be gentle ;-) I do 
believe there is some sort of problem inside the NFS code though.

Background: I have:
  - linux server x86_64, vanilla kernel 3.6.7 sharing a few exports
  - several set-top-boxes running linux, arch is mipsel32, they're 
almost vanilla, but they have prioprietary closed source drivers for the 
DVB frontends:
    * MaxDigital XP1000, kernel 3.5.1
    * DMM DM8000, kernel 3.2.0
    * VU+ Ultimo, kernel 3.1.1

These all suffer from the same problem. When they have a share mounted 
with default parameters, using tcp, they crash sooner or later, notably 
after heavy share access. The dm8000 has it's gui killed by the 
OOM-killer whilst the xp1000 and the ultimo simply lock up.

The OOM-killer reports it needs blocks of 128k (probably for NFS, but it 
doesn't say it), but can't find them. For the other stb'es it's not 
clear as they lock up.

I've "discovered" a few interesting things:
  - adding swap to the dm8000 makes the problem almost go away, although 
without NFS it definitely doesn't need swap, ever.
  - when I ran my laptop (x86_64!) with a slightly older kernel (2.6.35 
iirc) from a rescue cd, at a certain point I also got nasty dmesg 
reports and the "dd" proces got stuck in D state, this was reproducable 
over reboots.
  - all clients work flawlessly (over extended perdiods of time) if 
mounted using udp and smaller rsize/wsize values (max 32k). Tcp seems to 
work as well, as long as the size values are kept under 32k.
  - the x86_64 laptop also worked fine when mounted this way
  - so apparently it's not a stb/mipsel32/proprietary driver issue.
  - stb's running older kernels (notably 2.6.18) don't suffer from this 
problem

Can please anyone enlighten me? I can't find similar reports other than 
from fellow stb users.

Thanks!