lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Nov 2008 16:01:32 +0100 From: Heiko Carstens <heiko.carstens@...ibm.com> To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> Cc: Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Kernel Testers List <kernel-testers@...r.kernel.org>, Rusty Russell <rusty@...tcorp.com.au>, Vegard Nossum <vegard.nossum@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Oleg Nesterov <oleg@...hat.com>, Dmitry Adamushko <dmitry.adamushko@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Steven Rostedt <srostedt@...hat.com> Subject: Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop_machine On Tue, Nov 11, 2008 at 06:35:05AM -0800, Paul E. McKenney wrote: > > > A process that would do nothing but onlining/offlining cpus would get > > > stuck after a while: > > > > > > 0 schedule+842 [0x342522] > > > 1 schedule_timeout+200 [0x342ec4] > > > 2 wait_for_common+362 [0x341fd6] > > > 3 wait_for_completion+54 [0x342146] > > > 4 __synchronize_sched+80 [0x81670] > > > 5 cpu_down+172 [0x33c030] > > > 6 store_online+96 [0x33c488] > > > 7 sysdev_store+52 [0x1bda84] > > > 8 sysfs_write_file+242 [0x1350ba] > > > 9 vfs_write+176 [0xd2028] > > > 10 sys_write+82 [0xd21ea] > > > 11 sysc_noemu+16 [0x269d8] > > > > > > All cpus are in cpu_idle and no other task in state TASK_INTERRUPTIBLE > > > or TASK_UNINTERRUPTIBLE. However it would continue to work as soon as > > > I login into the system or generate a console interrupt. > > > I'm going to look into the dump and see if I can figure out what is > > > broken here. > > > Dunno if it is the same bug or something else. > > > > [Cc:-ed Steven and Paul, since this backtrace seems to be RCU specific] > > > > Steven, Paul, any idea what could cause the hang? I think I would > > get lost in the RCU code... > > Hello, Heiko, > > Could you please apply the following debug patch (due to Jiangshan and > myself)? Then you should be able to build with CONFIG_RCU_TRACE, > then mount debugfs after boot, for example, on /debug. This will > create a /debug/rcu directory with three files, "rcucb", "rcu_data", > and "rcu_bh_data". Since you are still able to log in, could you > please send the contents of these three files? Hi Paul, could you attach the patch please? :) Does the patch also make sense if the system continues to work? That is the machine isn't stalled anymore as soon as I log in. On the other hand I do have a dump of the system and can look in whatever data structures you want. If that helps. Thanks, Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists