Hello, back in the discussion after being traveling.
Interesting, because it shows like being the normal recvfrom() done on the internal socket, expecting to be no load there. I have seen the backtrace you sent in previous email and it is in the same recv function from the system. The process is waiting for packets on the memory socket. I will try to read more about and see if there is anything missing there. Cheers, Daniel On 24/10/14 19:04, Alex Balashov wrote: > I also find this in 'dmesg' about the async workers periodically: > > INFO: task kamailio:4480 blocked for more than 120 seconds. > Not tainted 2.6.32-431.29.2.el6.x86_64 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kamailio D 0000000000000001 0 4480 4458 0x00000080 > ffff880037b1db28 0000000000000082 ffff880037b1dbb8 ffffffff8112f183 > ffff88000001dd80 0000000000000002 ffff880037b1dac8 ffffffff8109b39c > ffff8800a6069058 ffff880037b1dfd8 000000000000fbc8 ffff8800a6069058 > Call Trace: > [<ffffffff8112f183>] ? __alloc_pages_nodemask+0x113/0x8d0 > [<ffffffff8109b39c>] ? remove_wait_queue+0x3c/0x50 > [<ffffffff8152a5be>] __mutex_lock_slowpath+0x13e/0x180 > [<ffffffff8152a45b>] mutex_lock+0x2b/0x50 > [<ffffffff814f668a>] unix_dgram_recvmsg+0x7a/0x4d0 > [<ffffffff8144a923>] sock_recvmsg+0x133/0x160 > [<ffffffff8109afa0>] ? autoremove_wake_function+0x0/0x40 > [<ffffffff8114b00a>] ? handle_mm_fault+0x22a/0x300 > [<ffffffff8104a98c>] ? __do_page_fault+0x1ec/0x480 > [<ffffffff8144aa9e>] sys_recvfrom+0xee/0x180 > [<ffffffff810e1e07>] ? audit_syscall_entry+0x1d7/0x200 > [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b > > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
