Connect a serial cable between the host and another client. You need to
set the "console" parameters in grub.conf for the host and start minicom
in the client. This way you will be able to see the error dumped just
before the crash in the minicom client. See
Documentation/serial-console.txt for more details...
Sanjay
Bahadir Balban wrote:
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/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
