On Tue, Nov 11, 2008 at 05:14:01PM +0100, Heiko Carstens wrote: > > > 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? > > > > > > Thanx, Paul > > > > This time with the patch actually attached... Thanks to Peter Z. > > for alerting me to my omission. > > Well, your patch doesn't apply on git head. However I used preemptible > RCU instead and had tracing enabled. Were you using preemptible RCU earlier as well? Raphael was using classic RCU. Don't get me wrong, all problems need fixing, just trying to make sure I understand where the problems are occurring. > This is the output of the three files after it stalled (and continued, > because I caused an interrupt by sending a network packet) twice: > > [root@h0545001 rcu]# cat rcuctrs > CPU last cur F M > 1 0 0 1 1 > 3 0 0 1 1 > 4 0 0 0 0 > 5 0 0 0 1 > 6 0 0 0 0 > ggp = 1640, state = waitack > > [root@h0545001 rcu]# cat rcugp > oldggp=1652 newggp=1655 > > [root@h0545001 rcu]# cat rcustats > na=33948 nl=3 wa=33945 wl=0 da=33945 dl=0 dr=33945 di=0 > 1=0 e1=0 i1=1674 ie1=4 g1=1670 a1=1920 ae1=251 a2=1669 > z1=1669 ze1=0 z2=1669 m1=4411 me1=2742 m2=1669 This hang also involved synchronize_sched()? Or synchronize_rcu()? The reason I ask is that the above stats are for the synchronize_rcu() rather than synchronize_sched(). Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
