On Wed, 2005-01-19 at 14:01, linux-os wrote: > On Wed, 19 Jan 2005, Andrew Morton wrote: > > > Badari Pulavarty <[EMAIL PROTECTED]> wrote: > >> > >> I was playing with kexec+kdump and ran into this on 2.6.10-mm1. > >> I have seen similar behaviour on 2.6.10. > >> > >> I am using a 4-way P-III machine. I have a module which tries > >> gets same spinlock twice. When I try to "insmod" this module, > >> my system hangs. All my windows froze, no more new logins, > >> console froze, doesn't respond to sysrq. I wasn't expecting > >> a system hang. Why ? Ideas ? > >> > > > > Maybe all the other CPUs are stuck trying to send an IPI to this one? An > > NMI watchdog trace would tell. > > > >> #include <linux/init.h> > >> #include <asm/uaccess.h> > >> #include <linux/spinlock.h> > >> spinlock_t mylock = SPIN_LOCK_UNLOCKED; > >> static int __init panic_init(void) > >> { > >> spin_lock_irq(&mylock); > >> spin_lock_irq(&mylock); > >> return 1; > >> } > > - > > What would you expect this to do? After the first lock is > obtained, the second MUST fail forever or else the spin-lock > doesn't work. The code, above, just proves that spin-locks > work! >
I was expecting that one CPU will spin for the lock, while 3 other CPUs do real useful work (on 4-proc machine). Instead my machine is hung - all my windows froze up, no more "ssh", doesn't respond to sysrq to get traces. Only thing it does is, respond to "ping". Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/