[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0803111205250.3781@apollo.tec.linutronix.de>
Date: Tue, 11 Mar 2008 12:09:24 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Jike Song <albcamus@...il.com>
cc: Chr <chunkeey@....de>, Linux Kernel <linux-kernel@...r.kernel.org>,
venkatesh.pallipadi@...el.com, Ingo Molnar <mingo@...e.hu>,
len.brown@...el.com
Subject: Re: endless loop in native_flush_tlb_others in smp_64.c
On Tue, 11 Mar 2008, Jike Song wrote:
> > Most of them happend in X.org so at first I thought it had something to do
> > with the NVIDIA module... BUT, one time it froze "a way before" the module
> > could get loaded (and desynced my raid.......).
> >
> > ---
> > SYSRQ-P revealed that the CPU were looping inside:
> >
> > smp_64.c native_flush_tlb_others:
> > assembler code:
> > < 1ee: f3 90 pause
> > < 1f0: f6 45 00 03 testb $0x3,0x0(%rbp)
> > < 1f4: 75 f8 jne 1ee <native_flush_tlb_others+0x5f>
> >
> > also known as: (in C)
> >
> > while (!cpus_empty(f->flush_cpumask))
> > cpu_relax();
> >
> > So... has anyone a good idea what's happening here exactly? Or is there
> > already another topic or even a patch available?
Any chance that you can capture SYSRQ-T output via serial or
netconsole, so we can see the stacktrace and what the other CPUs are
doing, if they are doing anything.
Thanks,
tglx
--
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