lkml.org 
[lkml]   [2000]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.2.14 Sparc-32 SS-10 SMP spin_lock hang...

> The meantime between crashes with 2.2.13 on the SS-10 configured as above
> running Apache 1.3.3p3 was about four hours, with 2.2.14 it's about a day and a
> half. Here is the crash data for the 2.2.14 crash, on the console we get:
>
> spin_lock_irqsave(f808e66c) CPU #2 stuck at f00372c, owner PC(f003672c):CPU(2)
> spin_lock(f014b9ac) CPU #0 stuck at f003bde0, owner PC(f0036538):CPU(2)
> spin_lock(f014b9ac) CPU #1 stuck at f003bde0, owner PC(f0036538):CPU(2)
> spin_lock(f014b9ac) CPU #3 stuck at f003bde0, owner PC(f0036538):CPU(2)

CPU #0, #1 and #3 are stuck because CPU #2 grabbed the kernel_flag in
do_exit so we can ignore them.

The interesting line is:

spin_lock_irqsave(f808e66c) CPU #2 stuck at f00372c, owner PC(f003672c):CPU(2)

(I assume f00372c should be f003672c and is just written down incorrectly).

From a quick guess, f808e66c points to a sigmask_lock and CPU #2 is stuck
in __exit_sighand (called from do_exit):

static inline void __exit_sighand(struct task_struct *tsk)
{
struct signal_struct * sig = tsk->sig;
unsigned long flags;

spin_lock_irqsave(&tsk->sigmask_lock, flags);
if (sig) {
tsk->sig = NULL;
if (atomic_dec_and_test(&sig->count))
kfree(sig);
}

flush_signals(tsk);
spin_unlock_irqrestore(&tsk->sigmask_lock, flags);
}

The debug line says that CPU #2 has already obtained the sigmask_lock and is
trying to again and in the same spot! Sounds suspicious, I'll give the
sparc spinlock code a once over.

Anton

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.046 / U:1.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site