From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756863AbYEQSQx (ORCPT ); Sat, 17 May 2008 14:16:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753133AbYEQSQr (ORCPT ); Sat, 17 May 2008 14:16:47 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:41687 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbYEQSQq (ORCPT ); Sat, 17 May 2008 14:16:46 -0400 Date: Sat, 17 May 2008 11:16:39 -0700 From: Arjan van de Ven To: "koos vriezen" Cc: linux-kernel@vger.kernel.org Subject: Re: mplayer v4l hangs in 2.6.25.2/4 Message-ID: <20080517111639.21a3e177@infradead.org> In-Reply-To: References: Organization: Intel X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 17 May 2008 18:54:06 +0200 "koos vriezen" wrote: > Hi, > > I'm using mplayer for tv watch quite some kernels but 2.6.25 makes > mplayer unkillable. Last working kernel is 2.24.5 that I have tried. > > This gets printed on the console > > INFO: task mplayer:3465 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. mplayer D 0000000000000000 0 3465 3464 > ffff810074333c68 0000000000200086 0000000000000000 00000000ffffffff > ffff81007a3889c0 ffff810074333c18 ffff810074333c98 ffffffff8064a800 > ffffffff8064a800 ffffffff80646eb0 ffffffff8064a800 ffff8100757c1900 > Call Trace: > [] __mutex_lock_slowpath+0x68/0xa0 > [] enqueue_task_fair+0x72/0x9b > [] mutex_lock+0x1a/0x1e > [] enqueue_task+0x13/0x1e > [] :videobuf_core:videobuf_mmap_setup+0x1c/0x45 > [] :bttv:vidiocgmbuf+0x2c/0x99 > [] :videodev:__video_do_ioctl+0xa1/0x2ad9 > [] set_next_entity+0x18/0x36 > [] thread_return+0x3a/0xa4 > [] :videodev:video_ioctl2+0x17c/0x210 > [] ptrace_stop+0xfc/0x140 > [] ptrace_notify+0x83/0xa6 > [] vfs_ioctl+0x55/0x6b > [] do_vfs_ioctl+0x253/0x264 > [] sys_ioctl+0x51/0x71 > [] int_very_careful+0x35/0x3e > [] tracesys+0xdc/0xe1 > > I've attached what might be usable wrt to this. > Hi, this smells like a deadlock (probably in v4l). Thankfully the kernel has a lot of diagnostics for detecting deadlocks (you just found that the least invasive one caught the deadlock, but unfortunately it's also the method that yields the least information). Is it possible for you to enable lockdep (CONFIG_PROVE_LOCKING)? With that on, the kernel will print nicely which locks are being waited on, and if there's a deadlock, it'll print that too. Speaking of that, since this looks like a mutex related issue, it's worth enabling CONFIG_DEBUG_MUTEXES as well.... more debug checks in this area. If you also enable CONFIG_FRAME_POINTER then the backtrace will get better too (but it's not totally required, just easier for diagnostics)