From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xen pci passthrough hung task instead of terminate Date: Mon, 26 Jul 2010 11:53:12 -0400 Message-ID: <20100726155312.GC5273@phenom.dumpdata.com> References: <128795343.20100725173507@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <128795343.20100725173507@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sander Eikelenboom Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sun, Jul 25, 2010 at 05:35:07PM +0200, Sander Eikelenboom wrote: > Hi Konrad, > > I have tried both your trees, together with some experimental usb3 stuff. How many CPUs do you have assigned to your guest? I presume this problem does not appear under baremetal? Thought looking at the stack I would think it would too - it does not look Xen specific - just that a mutex is deadlocked. > It seems to work apart from some usb3 problems after several hours of videograbbing, in the end it crashes the program, but instead of terminating it keeps hanging. > Since xen_evtchn is on the trace stack i'm wondering if any xen parts are causing it to hang instead of terminate. Here is what the mutex_lock says: 71 /*** 72 * mutex_lock - acquire the mutex 73 * @lock: the mutex to be acquired 74 * 75 * Lock the mutex exclusively for this task. If the mutex is not 76 * available right now, it will sleep until it can get it. 77 * 78 * The mutex must later on be released by the same task that 79 * acquired it. Recursive locking is not allowed. The task 80 * may not exit without first unlocking the mutex. Also, kernel 81 * memory where the mutex resides mutex must not be freed with 82 * the mutex still locked. The mutex must first be initialized 83 * (or statically defined) before it can be locked. memset()-ing 84 * the mutex to 0 is not allowed. 85 * 86 * ( The CONFIG_DEBUG_MUTEXES .config option turns on debugging 87 * checks that will enforce the restrictions and will also do 88 * deadlock debugging. ) 89 * 90 * This function is similar to (but not equivalent to) down() So I think the next step is to try CONFIG_DEBUG_MUTEXES, and see what it tells you. > > -- > Sander > > > > Jul 25 16:54:26 security kernel: [26400.136170] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Jul 25 16:54:26 security kernel: [26400.136191] motion D ffffffff810049f9 0 1556 1 0x00000000 > Jul 25 16:54:26 security kernel: [26400.136220] ffff88001fce6800 0000000000000286 0000000000000001 0000000000014580 > Jul 25 16:54:26 security kernel: [26400.136254] ffff88001e251fd8 ffff88001e251fd8 ffff88001e088100 0000000000014580 > Jul 25 16:54:26 security kernel: [26400.136285] 0000000000014580 0000000000014580 ffff88001e088100 0000000000000001 > Jul 25 16:54:26 security kernel: [26400.136316] Call Trace: > Jul 25 16:54:26 security kernel: [26400.136346] [] ? __mutex_lock_slowpath+0xda/0x125 > Jul 25 16:54:26 security kernel: [26400.136374] [] ? mutex_lock+0x12/0x28 > Jul 25 16:54:26 security kernel: [26400.136399] [] ? videobuf_streamoff+0x13/0x34 [videobuf_core] > Jul 25 16:54:26 security kernel: [26400.136424] [] ? xen_force_evtchn_callback+0x9/0xa > Jul 25 16:54:26 security kernel: [26400.136449] [] ? vidioc_streamoff+0x7e/0xb5 [em28xx] > Jul 25 16:54:26 security kernel: [26400.136473] [] ? __video_do_ioctl+0x181f/0x3cc7 [videodev] > Jul 25 16:54:26 security kernel: [26400.136496] [] ? xen_restore_fl_direct_end+0x0/0x1 > Jul 25 16:54:26 security kernel: [26400.136517] [] ? _raw_spin_unlock_irqrestore+0xc/0xd > Jul 25 16:54:26 security kernel: [26400.136539] [] ? sock_def_readable+0x3b/0x5d > Jul 25 16:54:26 security kernel: [26400.136561] [] ? unix_dgram_sendmsg+0x428/0x4b2 > Jul 25 16:54:26 security kernel: [26400.136580] [] ? xen_set_pte_at+0x196/0x1b6 > Jul 25 16:54:26 security kernel: [26400.136600] [] ? __raw_callee_save_xen_make_pte+0x11/0x1e > Jul 25 16:54:26 security kernel: [26400.136620] [] ? sock_sendmsg+0xd1/0xec > Jul 25 16:54:26 security kernel: [26400.136641] [] ? __do_fault+0x3eb/0x426 > Jul 25 16:54:26 security kernel: [26400.136662] [] ? video_ioctl2+0x292/0x32e [videodev] > Jul 25 16:54:26 security kernel: [26400.136684] [] ? sys_sendto+0x10d/0x127 > Jul 25 16:54:26 security kernel: [26400.136702] [] ? check_events+0x12/0x20 > Jul 25 16:54:26 security kernel: [26400.136722] [] ? v4l2_ioctl+0x38/0x3a [videodev] > Jul 25 16:54:26 security kernel: [26400.136742] [] ? vfs_ioctl+0x69/0x92 > Jul 25 16:54:26 security kernel: [26400.136760] [] ? do_vfs_ioctl+0x411/0x43c > Jul 25 16:54:26 security kernel: [26400.136779] [] ? vfs_write+0x134/0x169 > Jul 25 16:54:26 security kernel: [26400.136797] [] ? sys_ioctl+0x51/0x70 > Jul 25 16:54:26 security kernel: [26400.136815] [] ? system_call_fastpath+0x16/0x1b > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel