Thanks Amit for the quick reply.
> Excellent Analysis!
>
> 1. KGDB can't do this 5 seconds lockup verification
> you've suggested since it
> belongs to kernel. The kernel already has this in
> place and it calls die_nmi
> appropriately.
>
> 2. DIE_NMI is sent even before the lockup
> verific
Excellent Analysis!
1. KGDB can't do this 5 seconds lockup verification you've suggested since it
belongs to kernel. The kernel already has this in place and it calls die_nmi
appropriately.
2. DIE_NMI is sent even before the lockup verification. It occurs too
frequently. We should ignore it.
Hi Amit,
> To investigate this further, you may find printks
> useful. You need to use them
> carefully as they may cause races/spinlook deadlocks
> to go away.
printk() does not work either :-) as the system was
completely in the control of kgdb.
I used my own global variables to know the f
Hi George, Amit,
Below are the details after the debugging:
1) At this moment, I am tending to say, on
2.6.20 kernel (I could not experiment on earlier
version of kernels) on x86_64 arch, this problem
is quickly seen in the booting process
(specifically
in init process itself) regard
I agree with George.
To investigate this further, you may find printks useful. You need to use them
carefully as they may cause races/spinlook deadlocks to go away.
-Amit
On Thursday 22 February 2007 21:12, George Anzinger wrote:
> Rajesham Gajjela wrote:
> > We root caused the problem. This pro
Rajesham Gajjela wrote:
> We root caused the problem. This problem is easily
> reproducable on x86_64 arch with linux-2.6.20 and
> latest kgdb patches.
>
>
> Root cause: nmi_watchdog_tick() calls
> notify_die(DIE_NMI, ) and this causes the
> control transfer to kgdb. Hence, it appears that
>
We root caused the problem. This problem is easily
reproducable on x86_64 arch with linux-2.6.20 and
latest kgdb patches.
Root cause: nmi_watchdog_tick() calls
notify_die(DIE_NMI, ) and this causes the
control transfer to kgdb. Hence, it appears that
the system is hung, but in reality the sy
Hi,
I have patched my 2.6.20 kernel (x86_64 arch)
with 2.6.15 kgdb patches. I have been experiencing
problem in booting my kernel. Booting stucks
immediately after initrd.
I have two serial ports on my machine:
Feb 14 01:23:22 raj kernel: ttyS0 at I/O 0x3f8 (irq =
4) is a 16550A
Feb 14 01:23:22
