From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753125AbbALLsf (ORCPT ); Mon, 12 Jan 2015 06:48:35 -0500 Received: from mx-relay13.cloudservice.ag ([81.20.94.219]:44273 "EHLO mx-relay13.cloudservice.ag" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752098AbbALLsc convert rfc822-to-8bit (ORCPT ); Mon, 12 Jan 2015 06:48:32 -0500 From: "Stoidner, Christoph" To: "paulmck@linux.vnet.ibm.com" CC: "linux-kernel@vger.kernel.org" Subject: AW: Question concerning RCU Thread-Topic: Question concerning RCU Thread-Index: AQHQKdgN5pYhqCTrrEydsWtlbI+1KpyzbZSAgAdiVA6AAIVJAIAA8bH3 Date: Mon, 12 Jan 2015 11:48:28 +0000 Message-ID: <249b36ec1afa43a699b281a4192c6afd@EX132MBOX1A.de2.local> References: <94921a144a97457385ae95b838c3c6fa@EX132MBOX1A.de2.local> <20150106194317.GG5280@linux.vnet.ibm.com> <81b94fc89c774b71a967fc93823e9c63@EX132MBOX1A.de2.local>,<20150111202604.GC8063@linux.vnet.ibm.com> In-Reply-To: <20150111202604.GC8063@linux.vnet.ibm.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.91.168.120] x-exclaimer-md-config: 2329e0da-e5c9-454a-b62b-9269baa51382 x-hoag-tnef: done Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-cloud-security-sender: c.stoidner@oujhf.hostedoffice.ag X-cloud-security-recipient: linux-kernel@vger.kernel.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate13 with 957482118001 X-cloud-security-connect: fw1.hostedoffice.ag[81.20.90.82], TLS=, IP=81.20.90.82 X-cloud-security: scantime:.1103 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, > You got stack traces with the stall warnings, correct? If so, please look > at them and at Documentation/RCU/stallwarn.txt and see if the kernel is > looping somewhere inappropriate. Yes and no. I have a stack trace, but it is not generated by a stall warning. More precise: I can never see any stall warning. The reason is that the system freezes when it is about to output such a warning. Instead the stack trace is generated by gdb and JTAG hardware debugging, when freezing has occurred. So I am not sure if there is really a CPU-stall condition or it is just a misrepresented stall detection. However, outputting a stall warning leads to system freeze. The warning is never seen. > I am not familiar with the low-level ARM kernel code, but the stack below > leads me to suspect that your kernel is interrupting itself to death or > is improperly handling interrupts. The stack trace must be read from bottom to top. The repetitive occurrence of "__irq_svc () at arch/arm/kernel/entry-armv.S:202" on bottom of stack trace is caused by the stack frame of the interrupt context. This is completely legal and also the case in normal situations. Instead the problem is on the top of the stack trace, in function rcu_print_task_stall(). The loop rcutree_plugin.h in line 528 never ends: static int rcu_print_task_stall(struct rcu_node *rnp) { ... ... list_for_each_entry_continue(t, &rnp->blkd_tasks, rcu_node_entry) { printk(KERN_CONT " P%d", t->pid); ndetected++; } ... ... } That means list_for_each_entry_continue () never ends since rcu_node_entry.next seems to point to it-self but not to rnp->blkd_tasks. I have no idea how this can happen. One more thing: Just for testing I have now enabled CONFIG_TINY_PREEMPT_RCU. Until now the problem has not occurred anymore. Do you have any idea what makes the differences here? Thanks and regards, Christoph