On Tuesday 10 March 2009 09:44:15 pm Tom Rathborne wrote: > Hi Vitaliy, > > On Tue, Mar 10, 2009 at 12:58:48PM +0300, Vitaliy Gusev wrote: > > On Saturday 07 March 2009 12:13:14 am Tom Rathborne wrote: > > > Hi Vitaliy, > > > > > > On Fri, Mar 06, 2009 at 10:04:13PM +0300, Vitaliy Gusev wrote: > > > > Tom wrote: > > > > > Is there anything else I can do to help you debug this? > > > > > > > > Warn message reffers to the shmem_free_blocks(): > > > > > > > > static void shmem_free_blocks(struct inode *inode, long pages) > > > > { > > > > struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb); > > > > if (sbinfo->max_blocks) { > > > > spin_lock(&sbinfo->stat_lock); > > > > ^^^^ > > > > Here is a place where cpu1 is in a loop . > > > > > > > > It seems like someone already held &sbinfo->stat_lock. > > > > > > Ok, that makes sense. > > > > > > > Can you do "sysrq-p" , "sysrq-t", "sysrq-w" in the host ? > > > > > > Done, attached! > > > > > > I have not rebooted the machine yet, in case you need some other > > > kernel debug info. Let me know! > > > > Hmm, i saw only trace for cpu 3, cpu 0 and cpu 1. Where is a trace for > > cpu2 ? > > I re-checked the log. There was no trace for cpu2! > > > Also it will be nice if you compile your kernel with spin lock debug
And with lockdep debug > > and do sysrq-d. > > Ok ... I will have to learn the Debian Way to recompile my kernel! > I will get back to you with a spin lock trace from sysrq-d. > > Thanks, > > Tom -- Thanks, Vitaliy Gusev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org