(2013/11/10 21:29), ISHIKAWA,chiaki wrote:
(2013/11/10 21:04), Jeff Layton wrote:
On Sun, 10 Nov 2013 13:40:01 +0900
"ISHIKAWA,chiaki" <ishikawa@xxxxxxxxxxxx> wrote:
(2013/11/09 20:58), Jeff Layton wrote:
On Sat, 09 Nov 2013 02:41:41 +0900
"ISHIKAWA,chiaki" <ishikawa@xxxxxxxxxxxx> wrote:
cifsd is a kernel thread, which means that it acts like a process but
always runs in kernel mode. It'll have a name like "[cifsd]" in ps. You
can get its stack in exactly the same way as any other process
(/proc/<pid>/stack).
Thank you.
I found it in my ps output.
I will investigate more.
My previous post was before I read you latest info.
Thank again for your tips.
Here is the stack trace of cifs and cifsiod.
It looks that the reading seems to gets stuck.
root@vm-debian-amd64:/tmp# LC_ALL=C
root@vm-debian-amd64:/tmp# LANG=C
root@vm-debian-amd64:/tmp# ps -aef | grep cifs
root 11607 11427 0 21:35 pts/8 00:00:00 grep cifs
root 16853 2 0 Nov08 ? 00:00:00 [cifsiod]
root 16901 2 0 Nov08 ? 00:00:31 [cifsd]
root@vm-debian-amd64:/tmp# cat /proc/16901
cat: /proc/16901: Is a directory
root@vm-debian-amd64:/tmp# cat /proc/16901/stack
[<ffffffff81047920>] process_timeout+0x0/0x5
[<ffffffff812b72d4>] sk_wait_data+0x7b/0xbb
[<ffffffff81057c7d>] autoremove_wake_function+0x0/0x2a
[<ffffffff812f9bab>] tcp_recvmsg+0x466/0x999
[<ffffffff813163f1>] inet_recvmsg+0x5a/0x6e
[<ffffffff812b482b>] sock_recvmsg+0x5a/0x79
[<ffffffff8105eaff>] mmdrop+0xd/0x1c
[<ffffffff81059b0e>] lock_hrtimer_base.isra.16+0x1b/0x3c
[<ffffffff812b499b>] kernel_recvmsg+0x30/0x3a
[<ffffffffa04d9f87>] cifs_readv_from_socket+0x14a/0x1ed [cifs]
[<ffffffff810c2ad0>] mempool_alloc+0x5c/0x128
[<ffffffffa04da048>] cifs_read_from_socket+0x1e/0x23 [cifs]
[<ffffffffa04da7fc>] cifs_demultiplex_thread+0x775/0x79a [cifs]
[<ffffffffa04da087>] cifs_demultiplex_thread+0x0/0x79a [cifs]
[<ffffffff81057325>] kthread+0x7d/0x85
[<ffffffff81040900>] do_exit+0x901/0x918
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffff8138b47c>] ret_from_fork+0x7c/0xb0
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffffffffffff>] 0xffffffffffffffff
root@vm-debian-amd64:/tmp# cat /proc/16853/stack
[<ffffffff81052dd4>] rescuer_thread+0x23f/0x265
[<ffffffff81052b95>] rescuer_thread+0x0/0x265
[<ffffffff81057325>] kthread+0x7d/0x85
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffff8138b47c>] ret_from_fork+0x7c/0xb0
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffffffffffff>] 0xffffffffffffffff
root@vm-debian-amd64:/tmp#
What kernel version is this too, btw?
uname -r
3.10-3-amd64
It is 3.10.3 64bit.
Thanks. It might be worth testing something v3.12-ish, but I sort of
doubt it'll make much difference.
I will try to gather as much data as possible from my hung CIFS state so
that we can have a better idea of where the problems may lie
before I try upgrading my kernel and test similar operations.
(Also, I am not sure if I can replace the kernel as easily as we could
do before. It seems some userland daemeon may be tied to kernel versions
rather in complicated manner these days.)
Thank you again for your attention.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
