Messages in this thread | | | Date | Tue, 19 Dec 2000 11:58:10 +0100 (CET) | From | Urban Widmark <> | Subject | Re: 2.2.18: Thread problem with smbfs |
| |
On Tue, 19 Dec 2000, Hans-Joachim Baader wrote:
> and so on, endlessly. So, AFAIK, smbfs thinks it has lost connection and > tells smbmount to re-establish it, which succeeds (at least smbmount > thinks so). This happens several times per second.
-512 means that the recv was interrupted by a signal, or rather, the current process has a signal maybe the recv was interrupted, maybe there is a problem with the connection, better reconnect.
Still, it's better than pre-2.2.18 where smbmount wouldn't stay alive ...
I don't really know how signal delivery works within the kernel, but smb_trans2_request tries to disable some signals. That does not work (completely?) so either it needs fixing or the -512 errno needs to be handled.
Why so bad in gdb? perhaps it causes more signals. Why does one thread end up in D state? don't know.
> Kernel 2.2.18, smbfs as a module. I can provide more info if necessary.
A small testprogram that causes this would be nice. The -512 is easy to reproduce but I haven't seen the 'D' before.
If someone is interested the relevant code is fs/smbfs/sock.c (smb_trans2_request, ..., _recvfrom)
/Urban
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |