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/
