On Thu, Feb 19, 2009 at 8:14 AM, Peter Teoh wrote:
> On Thu, Feb 19, 2009 at 3:19 AM, Sukanto Ghosh
> wrote:
>>
>> Hi,
>>
>> I am running into a peculiar problem here.
>>
>> I am getting stack-traces from two sources, i) spin_lock BUG_ON "cpu
>> recursion", and ii) remote gdb running on my host a
On Thu, Feb 19, 2009 at 3:19 AM, Sukanto Ghosh
wrote:
> Hi,
>
> I am running into a peculiar problem here.
>
> I am getting stack-traces from two sources, i) spin_lock BUG_ON "cpu
> recursion", and ii) remote gdb running on my host and connected to the
> guest kernel (the one I am debugging).
>
>
Hi,
I am running into a peculiar problem here.
I am getting stack-traces from two sources, i) spin_lock BUG_ON "cpu
recursion", and ii) remote gdb running on my host and connected to the
guest kernel (the one I am debugging).
spin_lock BUG_ON stack-trace says:
BUG: spinlock recursion on CPU#0, q
>> But now I am getting a "BUG: spinlock recursion on CPU#0" error. What
>> does this error mean ?
>
> yes, it actually means that the previous lock is still not released yet, and
> now u are calling a function to acquire the spinlock again..and somehow,
> before actually acquiring the spinloc
On Wed, Feb 18, 2009 at 3:58 AM, Sukanto Ghosh
wrote:
> Hi Peter,
>
> Accidentally I came upon this article:
> http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html
>
> With the help of it I could get a stacktrace when the kernel hung.
>
> The problem was a stupid one: I was hol
Hi Peter,
Accidentally I came upon this article:
http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html
With the help of it I could get a stacktrace when the kernel hung.
The problem was a stupid one: I was holding a spin_lock and then I
called some function that again tries to
Would u like to share WHERE u made the change? WHAT u do could be part of
academic exercise, so perhaps u want to keep confidential, but WHERE would
be helpful.
I am suspecting (very usual for changes to MM codes) that u have done
something illegal while holding a open spinlock. So knowing whe
Hi Mulyadi,
On Mon, Feb 16, 2009 at 7:32 PM, Mulyadi Santosa
wrote:
> Hm, not an expert, but if you're a Qemu user, probably I can give you
> clue. When it hangs, go to Qemu monitor and type "print $pc" (if I
> recall correctly). It will print current executed instruction. And
> since your kernel
Hi
On Sun, Feb 15, 2009 at 1:26 AM, Sukanto Ghosh
wrote:
> On Sat, Feb 14, 2009 at 11:42 PM, Sukanto Ghosh
> wrote:
>>> And enabling earlyprintk through the serial port, and keep it when the
>>> console is
>>> set, this way you will see the printk messages through the virtual serial
>>> line.
On Sat, Feb 14, 2009 at 11:42 PM, Sukanto Ghosh
wrote:
>> And enabling earlyprintk through the serial port, and keep it when the
>> console is
>> set, this way you will see the printk messages through the virtual serial
>> line.
>>
>> As a parameter: earlyprintk=serial,ttyS0,115200,keep
>>
>
> T
On Sat, Feb 14, 2009 at 7:42 PM, Frederic Weisbecker wrote:
>
> What I would suggest first is to enable the nmi watchdog to detect the
> hardlockups,
> see Documentation/nmi_watchdog.txt
>
Seemed just the thing I was looking for.
I tried it with kernel parameter nmi_watchdog=1 as well as
nmi_wat
On Sat, Feb 14, 2009 at 05:22:06PM +0530, Sukanto Ghosh wrote:
> Hi,
>
> I have made some changes to the memory management part of the kernel
> as an experiment. Now when I boot into that kernel and start some
> heavy processes (which cause paging), the kernel hangs. I can't even
> type anything.
Hi,
I have made some changes to the memory management part of the kernel
as an experiment. Now when I boot into that kernel and start some
heavy processes (which cause paging), the kernel hangs. I can't even
type anything.
I have gone through the 'paper on debugging kernel oops or hang'
(http://m
13 matches
Mail list logo
