On 07/27/11 18:32, Manuel Bouyer wrote:
Hello,
I'm testing a current amd64 kernel:
NetBSD borneo 5.99.55 NetBSD 5.99.55 (GENERIC) #0: Tue Jul 26 23:38:21 UTC
2011
bui...@b7.netbsd.org:/home/builds/ab/HEAD/amd64/201107262140Z-obj/home/builds/ab/HEAD/src/sys/arch/amd64/compile/GENERIC
On Wed, Jul 27, 2011 at 06:32:33PM +0200, Manuel Bouyer wrote:
Hello,
I'm testing a current amd64 kernel:
NetBSD borneo 5.99.55 NetBSD 5.99.55 (GENERIC) #0: Tue Jul 26 23:38:21 UTC
2011
Hello,
I'm testing a current amd64 kernel:
NetBSD borneo 5.99.55 NetBSD 5.99.55 (GENERIC) #0: Tue Jul 26 23:38:21 UTC 2011
bui...@b7.netbsd.org:/home/builds/ab/HEAD/amd64/201107262140Z-obj/home/builds/ab/HEAD/src/sys/arch/amd64/compile/GENERIC
amd64
with a 5.0_STABLE userland, and I noticed a
On Wed, 27 Jul 2011, Manuel Bouyer wrote:
Some investigations makes me suspect that select(2) is not working
properly, especially it doesn't wake up when there's data ready in the
socket buffer: when the rsync process is idle it's waiting on select,
when it's idle netstat shows that the receive
So select blocks (maybe because there's effectively nothing to read
at this time), but instead of waking up when there's data ready it
wakes up when the timeout expires.
This seems rather similar to something I was looking at back in
January. [...]
I had a similar symptom once, which turned