From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: rcu_sched self-detect stall when disable vif device Date: Tue, 27 Jan 2015 16:56:17 +0000 Message-ID: <54C7C331.3050709@citrix.com> References: <54C7B6E8.9080106@linaro.org> <20150127164539.GJ24026@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150127164539.GJ24026@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 27/01/15 16:45, Wei Liu wrote: > On Tue, Jan 27, 2015 at 04:03:52PM +0000, Julien Grall wrote: >> Hi, >> >> While I'm working on support for 64K page in netfront, I got >> an rcu_sced self-detect message. It happens when netback is >> disabling the vif device due to an error. >> >> I'm using Linux 3.19-rc5 on seattle (ARM64). Any idea why >> the processor is stucked in xenvif_rx_queue_purge? >> > > When you try to release a SKB, core network driver need to enter some > RCU cirital region to clean up. dst_release for one, calls call_rcu. This is RCU detecting a soft-lockup. You're either spinning on the spinlock or the guest rx queue is corrupt and cannot be drained. David >> Here the log: >> >> vif vif-20-0 vif20.0: txreq.offset: 3410, size: 342, end: 1382 >> vif vif-20-0 vif20.0: fatal error; disabling device >> INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=37266 c=37265 q=2649) >> Task dump for CPU 1: >> vif20.0-q0-gues R running task 0 12617 2 0x00000002 >> Call trace: >> [] dump_backtrace+0x0/0x124 >> [] show_stack+0x10/0x1c >> [] sched_show_task+0x98/0xf8 >> [] dump_cpu_task+0x3c/0x4c >> [] rcu_dump_cpu_stacks+0xa4/0xf8 >> [] rcu_check_callbacks+0x478/0x748 >> [] update_process_times+0x38/0x6c >> [] tick_sched_timer+0x64/0x1b4 >> [] __run_hrtimer+0x88/0x234 >> [] hrtimer_interrupt+0x108/0x2b0 >> [] arch_timer_handler_virt+0x28/0x38 >> [] handle_percpu_devid_irq+0x88/0x11c >> [] generic_handle_irq+0x30/0x4c >> [] __handle_domain_irq+0x5c/0xac >> [] gic_handle_irq+0x30/0x80 >> Exception stack(0xffff800013a07c20 to 0xffff800013a07d40) >> 7c20: 058ed000 ffff0000 058ed9d8 ffff0000 13a07d60 ffff8000 0053c418 ffff8000 >> 7c40: 00000000 00000000 0000ecf2 00000000 058ed9ec ffff0000 00000000 00000000 >> 7c60: 00000001 00000000 00000000 00000000 00001800 00000000 feacbe9d 0000060d >> 7c80: 1ce5d6e0 ffff8000 13a07a90 ffff8000 00000400 00000000 ffffffff ffffffff >> 7ca0: 0013d000 00000000 00000090 00000000 00000040 00000000 9a272028 0000ffff >> 7cc0: 00099e64 ffff8000 00411010 00000000 df8fbb70 0000ffff 058ed000 ffff0000 >> 7ce0: 058ed9d8 ffff0000 058ed000 ffff0000 058ed988 ffff0000 00956000 ffff8000 >> 7d00: 19204840 ffff8000 000c75f8 ffff8000 13a04000 ffff8000 008a0598 ffff8000 >> 7d20: 00000000 00000000 13a07d60 ffff8000 0053c3bc ffff8000 13a07d60 ffff8000 >> [] el1_irq+0x64/0xc0 >> [] xenvif_rx_queue_purge+0x1c/0x30 >> [] xenvif_kthread_guest_rx+0x210/0x29c >> [] kthread+0xd8/0xf0 >> >> >> Regards, >> >> -- >> Julien Grall > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >