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!
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
