lkml.org 
[lkml]   [2008]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.25-mm1: not looking good
On Fri, Apr 18, 2008 at 3:02 PM, Jason Wessel
<jason.wessel@windriver.com> wrote:
> Vegard Nossum wrote:
> > On Fri, Apr 18, 2008 at 2:34 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> >> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> >>
> >> > With the patch below, it seems 100% reproducible to me (7 out of 7
> >> > bootups hung).
> >> >
> >> > The number of loops it could do before hanging were, in order: 697,
> >> > 898, 237, 55, 45, 92, 59
> >>
> >> cool! Jason: i think that particular self-test should be repeated 1000
> >> times before reporting success ;-)
> >>
> >
> > BTW, I just tested a 32-bit config and it hung after 55 iterations as well.
> >
> > Vegard
> >
> >
> >
> I assume this was SMP?

Yes. But now that I realize this, I tried running same kernel with
qemu, using -smp 16, and it seems to be stuck here:

[ 16.562659] kgdb: Registered I/O driver kgdbts.
[ 16.565875] kgdbts:RUN plant and detach test

and the code is at kgdb_handle_exception():

/*
* Wait for the other CPUs to be notified and be waiting for us:
*/
for_each_online_cpu(i) {
while (!atomic_read(&cpu_in_kgdb[i]))
cpu_relax();
}


>
> While I had not tried it yet, my guess would have been this did not
> happen on a UP kernel. If it does occur on a UP kernel it means the
> problem is squarely between the task scheduling after the exception is
> handled and the kgdb state logic for re-entering the debug state after a
> single step exception occurs.
>
> It seems reasonable to go for 1000 iterations of this particular test to
> declare success as pointed out by Ingo. Previous versions of kgdb
> handled some of the irq + single step + cpu sync slightly differently
> and it is entirely possible there is a regression there.
>
> Jason.


Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036


\
 
 \ /
  Last update: 2008-04-18 15:27    [W:0.058 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site