Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"

On Tuesday 22 August 2006 06:20, Andrew Morton wrote:
On Mon, 21 Aug 2006 09:47:18 -0700
"Randy.Dunlap" <rdunlap@xxxxxxxxxxxx> wrote:

The 'stuck' unwinder issue at hand already has a fix, though planned to
be merged for 2.6.19 only. The crash after switching to the legacy
stack trace code is bad, though, but has little to do with the unwinder
additions/changes. The way that code reads the stack is just
inappropriate in contexts where things must be expected to be broken.

"merged for 2.6.19" meaning:
- in (before) 2.6.19, or
- after 2.6.19 is released

If "after," then it will likely need to be added to -stable also,
so it might as well go in "before" 2.6.19 is released.

Precisely.

Guys, this unwinder change has been quite problematic. We really cannot
let this badness out into 2.6.18 - it degrades our ability to debug every
subsystem in the entire kernel. Would marking it CONFIG_BROKEN get us back
to 2.6.17 behaviour?

IMHO just some stucks is tolerable for .18 and .18-stable, as long as it doesn't
add new crashes and the fallback always gives an useful backtrace (that is why I
added the fallback -- to make sure no information is lost)

Short term the stucks are a bit ugly but I hope with .19 or .20 longer
term we will have much better backtraces without false positives
(ok assuming people turn it on). The code queued for .19 should
be already pretty good now (ok after I fixed one nasty problem yesterday
that added some new ones compared to .18)


Has anyone even tried to reproduce Bruce's crash?

I looked at it a bit, but it puzzles me. The chaining for the interrupt stacks
on i386 -- which is what seems to be corrupted here -- shouldn't have changed at all
by the unwinder changes.

I suspect it would crash without unwinder too. Bruce, do you get the
same crash when you boot with "call_trace=old" ?

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: a dozen cpus on a chip
    ... It is still possible to write something that will crash, ... memory, or write to memory it doesn't own should be terminated with a ... I think that hardware designers could do a lot to improve matters. ... Having a call-return stack, a parameter stack, return value area, and ...
    (sci.electronics.design)
  • Re: wuauclt.exe has encountered a problem...
    ... That is the full extent of the message and pop-up detail. ... Have you disabled the Error Reporting Tool? ... to extract from it a list of the modules involved in the call stack at the time ... I'm suggesting only that you find the one entry which represents your crash event. ...
    (microsoft.public.windowsupdate)
  • Win32 DLL project randomly crashes after moving to VS2005
    ... the first step was to take care of the compilation ... The problem is that when I run my DLL it crashes in apparently random places ... I had a crash within a dialog's window procedure and another ... image library were generating a "stack overflow" message. ...
    (microsoft.public.vc.ide_general)
  • Re: Bugcheck 101
    ... This is what the stack in the hung processor looks like: ... The bugcheck information should show the hung processor. ... the crash, and all 8 virtual processors are busy at that time. ... waiting for a timer interrupt, and while processor 3 is the timed out ...
    (microsoft.public.development.device.drivers)
  • Win32 DLL project randomly crashes after moving to VS2005
    ... the first step was to take care of the compilation ... The problem is that when I run my DLL it crashes in apparently random places ... I had a crash within a dialog's window procedure and another ... image library were generating a "stack overflow" message. ...
    (microsoft.public.vstudio.general)