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
