Re: wait_on_irq, CPU1

Andi Kleen (ak@suse.de)
Wed, 29 Dec 1999 12:50:45 +0100

On Wed, Dec 29, 1999 at 10:23:43AM +0100, Manfred Spraul wrote:
> Andi Kleen wrote:
> >
> > On Tue, Dec 28, 1999 at 11:59:12PM +0100, Andrea Arcangeli wrote:
> > > > I though about a tiny patch which calls
> > > >smp_call_function() in wait_on_irq(): the IPI would call a stripped down
> > > >version of show_registers().
> > >
> > > FYI: Andi just wrote the code to do that for the wait_on_bh case for other
> > > needs, extending original's Andi's patch for wait_on_irq as well should be
> > > trivial.
> >
> > It is part of the kbacktrace patch. It should give full backtrace for
> > wait_on_bh and wait_on_irq. kbacktrace generally is intended as a replacement
> > for the traditional *((int*)0)=0;
> >
>
> There are 2 buglets in the code:
>
> * the kernel stack size is THREAD_SIZE (ie 8192), your patch assumes
> that the stack size is 4096.

Oops :-) Good point.

> > +#define for_all_cpus(i) for((i)=0;(i)<smp_num_cpus;(i)++)
>
> you must use "cpu_logical_map()", eg get_irq_list() in
> linux/arch/i386/kernel/irq.c does that.

I have never seen a motherboard where they are not continuous.
But I'll fix it.

>
> >
> > + if (smp_call_function(getstack, sps, 1, 1) < 0)
> > + printk("smp_call_function failed\n");
> > + else {
>
> I should really fix smp_call_function(): have you checked the actual
> implementation:
> it uses a semaphore, ie panic() waits for a semaphore before stopping
> the kernel...

That is why it is careful to dump the local CPU first, so even when
smp_call_function fails it gets at least the same information as before.
Also panic normally does not call kbacktrace anyways.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/