This is just a guess, but is SO_RCVLOWAT getting set somewhere?  The receive
call will block until it gets the number of bytes set with this option.  I
think it defaults to 1, so it should normally return when any data is
available on the socket.  But if it has been bumped up to a big number, it
might account for the behavior you're seeing.

-Josh

David Ashley wrote:

I've found a very strange bug in linux ppc 2.4.17, I think. I'm pulling
udp packets off the LAN and reading them in a user space program. They come
in sets of about 60k bytes all together, then pause for a while. I only can
read the first 48k successfully, then they get lost.

If I have a setsockopt call on the socket, setting SO_RCVBUF to 65535,
then I don't lose any data. But if I do a getsockopt beforehand on
SO_RCVBUF, it reports 65535. Without the setsockopt I get the packet loss,
with it I don't lose any. It is strange because the value doesn't appear
to be changing.

What can be causing this mysterious behaviour?

-Dave

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/