Hi Ashish, In Kernel when enable spin_lock debugging, the code path and behavior of spin_lock is changed. when debugging is off, spin_lock() spin in tight loop, but in spin_lock_debug it work as try() lock (). So we can debug the system and find who hold the lock for long time. Below is sequence. do_raw_spin_lock->__spin_lock_debug-> After delay loops_per_jiffy * HZ, if spin lock unable to get. it call spin_dump(). Then meaning of below message is in your system spin_lock is suspected on which CPU and what is process ID. printk(KERN_EMERG "BUG: spinlock %s on CPU#%d, %s/%d\n", msg, raw_smp_processor_id(), current->comm, task_pid_nr(current)); printk(KERN_EMERG " lock: %pS, .magic: %08x, .owner: %s/%d, " ".owner_cpu: %d\n", lock, lock->magic, owner ? owner->comm : "<none>", owner ? task_pid_nr(owner) : -1, lock->owner_cpu); Thanks On Tue, Feb 4, 2014 at 12:51 PM, Ashish Sangwan <ashishsangwan2@gmail.com> wrote:
What could be reasons for the following message:
BUG: spinlock lockup suspected on CPU#0, sh/11786
lock: kmap_lock+0x0/0x40, .magic: dead4ead, .owner: sh/11787, .owner_cpu: 1
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies