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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
