On Sun, Dec 30, 2012 at 01:53:18PM +0100, Erik Slagter wrote: > Hello All, > > I am almost complete NOOB on this matter, so please be gentle ;-) Hah! Hah! Hah! > 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. Details? (Could you show us the log messages?) Anything else interesting in the logs before then? (E.g. any "order-n allocation failed" messages?) > 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. Why do you believe that's the same problem? > - 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 OK, thanks for the reports, let us know i you're able to narrow it down farther. It's not familiar off the top of my head. --b. > > 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 -- 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
