From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754635AbbKQTPt (ORCPT ); Tue, 17 Nov 2015 14:15:49 -0500 Received: from www.linutronix.de ([62.245.132.108]:51339 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754548AbbKQTPs (ORCPT ); Tue, 17 Nov 2015 14:15:48 -0500 Date: Tue, 17 Nov 2015 20:15:06 +0100 (CET) From: Thomas Gleixner To: Stefan Priebe - Profihost AG cc: linux-netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Asterisk deadlocks since Kernel 4.1 In-Reply-To: <564B3D35.50004@profihost.ag> Message-ID: References: <564B3D35.50004@profihost.ag> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Nov 2015, Stefan Priebe - Profihost AG wrote: > since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it > deadlocks every few hours (kill -9 is the only thing working). Booting > with 3.18 again let it run smooth again. > > An strace shows asterisk is looping like this: > > [pid 6068] timerfd_gettime(8, , {it_interval={0, 20000000}, > it_value={0, 140592906050976}}) = 0 > [pid 6068] read(8, "\1\0\0\0\0\0\0\0", 8) = 8 > [pid 6068] poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}], > 2, 1000) = 1 ([{fd=8, revents=POLLIN}]) > [pid 6068] timerfd_gettime(8, , {it_interval={0, 20000000}, > it_value={0, 140592906050976}}) = 0 > [pid 6068] read(8, "\1\0\0\0\0\0\0\0", 8) = 8 > > fd 8 is: > > lrwx------ 1 root root 64 Nov 17 15:27 /proc/6025/fd/8 -> > anon_inode:[timerfd] > > > # cat /proc/6025/stack > [] poll_schedule_timeout+0x49/0x70 > [] do_sys_poll+0x3d7/0x590 > [] do_restart_poll+0x3c/0x70 > [] sys_restart_syscall+0x1f/0x30 > [] system_call_fastpath+0x12/0x71 > [] 0xffffffffffffffff > > Any ideas how to debug this? fd 8 is probably not really interesting. That looks like a interval timer firing periodically. So it probably waits for fd 9 ... Thanks, tglx