Re: NFS hangs (again)

[christos%zoulas.com@localhost (Christos Zoulas)]

On Aug 25,  1:18pm, marcotte%panix.com@localhost (Brian Marcotte) wrote:
-- Subject: Re: NFS hangs (again)

| >Wow, you are having a lot of problems with NFS! Is that a single processor
| >or a multiprocessor box? I forget if in 5.0 socket page loaning is enabled
| >or disabled. In current it is disabled. Can you make sure that
| >sock_loan_thresh is -1, in uipc_socket.c?
| 
| The particular problem in the message you replied to is unique, so I'm
| not worrying about that one. Still, it should have been able to recover
| without a reboot.

Yes, I understand. I just happened to reply to that one.

| For the hardware box, it is a Pentium 4 with hyperthreading. I had to
| turn off ACPI in the kernel config to make it work properly, so I don't
| know if the second "processor" is being used.
| 
| For the Xen boxes, they are all multi-core, but NetBSD/xen doesn't support
| multiprocessor.
| 
| In uipc_socket.c there is this:
| 
|     #if defined(SOSEND_NO_LOAN) || defined(MULTIPROCESSOR)
|     int sock_loan_thresh = -1;
|     #else
|     int sock_loan_thresh = 4096;
|     #endif
| 
| gdb is telling me that for my hardware kernels it is set to -1 and for
| the Xen kernels it is 4096.
| 
| I have NFS problems on both types.

And the same kinds of problems? Getting EWOULDBLOCK/EAGAIN on them?
Strange because in uipc_socket.c there is one obvious place where sosend
can return EWOULDBLOCK, but that is for non blocking I/O. Can you instrument
sosend() and find where it returns EWOULDBLOCK?

christos