In the meantime, I managed to find out what happens with StarOffice.
(Alex, could you please forward this to your hardly acquired StarOffice
contact person? :)
It seems that since 2.2-pre8, the select() system call, among being more
scalable to large fd sets, is more pedantic in checking its arguments.
In particular, it doesn't allow the first argument being larger than
about 5000; but for some reason, StarOffice likes to call select() with
a first argument being trash, usually as high as a few millions.
The sanity check since 2.2-pre8 (and in all 2.2.x kernels) makes this
return with -EINVAL, which seems to cause SO to retry the operation, not
checking for progress on its file handles, thus sucking up CPU time, and
essentially "freezing" network operations.
There isn't anything I could do by patching the kernel, it's clearly a
bug in user space; although it might be caused by glibc, independent of
StarOffice, tracking that should be a job for the guys at StarDivision.
Hint: it may be in glibc-linuxthreads [by looking at it, it seems to use
poll() however, not select()], it could be even in glibc's poll()
emulation [Chris, that's when it might be the same as your problem], or
it could be simply in SO's code itself [possibly an uninitialized
maxfd-like variable]; in which case, only Star Division can do anything
about it.
[I'm open if they need to discuss this problem with me, and I also do
speak... ehrm, write/read German if needed.]
Janos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/