Re: [Crash-utility] timer: invalid list entry: 1 [ ARM ]
----- Original Message -----
as far as crashdump is concerned, this is how we take it.
basically, we just dump whole ram (flat physical RAM), and then I
have modified crash utlilty to convert ramdump (just plain ramdump)
into arm elf32 format.
and so it could get recognized by any debugger as crash utility.
and it has been working great.
I have loaded so many ramdumps, and timer and any other command is
working perfectly fine.
but only this scenario it has given such thing. where I suspected
timer list corruption/crash utility problem.
Do all cpus in the kernel continue to run while your "ramdump" is
taking place? That's a likely explanation for the "timer" output to
be out of sync.
wfi (is wait for interrupt), in the sense we let the cpu go ino idle/dormant when he has
nothing to do.
and the thread who has been scheduled earliest, the timer would have set accordingly and
then wake the cpu up.
here we are missing both timer interrupt on both cpu. that means that timer counter has
much gone ahead, and it will never
match programmed compare values. so its system freeze, as interrupts are not happening.
I don't understand. Why is the system not receiving timer interrupts
while the cpus are in their idle state?
in that freeze, we have special keryboard interrupt to take task dump
and other dumps.
on that ramdump which I have crash utility would show
crash> bt -a
PID: 0 TASK: c097b8b0 CPU: 0 COMMAND: "swapper/0"
bt: WARNING: cannot get stackframe for task
PID: 0 TASK: dc84ca40 CPU: 1 COMMAND: "swapper/1"
bt: WARNING: cannot get stackframe for task
Yeah, it appears that the ARM backtrace code presumes that the dumpfile
was taken with the kernel's kdump facility, because it gets the backtrace
starting points from the register values save in the kdump "crash_notes".
So you might try entering "bt -t" or "bt -T". But if the cpus were
sitting in the idle state, there's probably not much to see.
One thing I do *not* like about the ARM "bt" display is that it
does not show the stack address of each frame. But I think the
ARM maintainers did it that way to simulate the kernel's log
output.
Dave