spin locks are not defined in UP. They come into picture only in SMP (if
CONFIG_SMP is defined)
On UP you can call spin_lock as many times, it does not cause any problem.
There is some thing else which is causing problem in your code.
-RamaRao
----- Original Message -----
From: "Bahadir Balban" <bahadir.balban@xxxxxxxxx>
To: <kernelnewbies@xxxxxxxxxxxx>
Sent: Tuesday, January 10, 2006 7:16 PM
Subject: Spinlock debugging
Hi,
I have a uniprocessor system that deadlocks upon loading of a module.
This module uses some spinlocks at various points. Unfortunately my
arch does not support non-maskable interrupts.
I have enabled spinlock debugging in the kernel, but the system
deadlocks before I see any spinlock related printks.
My approach is to spot and fix the problem reading the code, rather
than searching for clues at run-time. Do you have any suggestions to
what to look for in the code this way?
I replaced spin_lock() functions with irq disabling versions to cover
for potential races from irqs. But the problem is still there. I will
also check whether a lock is acquired twice. If I replaced all
spinlocks with spin_trylocks would that help to at least spot
recursive locks? What else should I look for?
Thanks,
Bahadir
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
"SASKEN RATED Among THE Top 3 BEST COMPANIES TO WORK FOR IN INDIA - SURVEY 2005 conducted by the BUSINESS TODAY - Mercer - TNS India"
SASKEN BUSINESS DISCLAIMER
This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
